發文數：16
發表時間：2008-07-11 18:59:00
發表時間：2008-07-11 18:59:00
不知大家在操作時會不會覺得卡卡的。
經常（而且是很經常）畫面就卡住不動，尤其是在開新程式或切換程式時，怎麼滑也沒反應。
過幾秒才有反應。
經常（而且是很經常）畫面就卡住不動，尤其是在開新程式或切換程式時，怎麼滑也沒反應。
過幾秒才有反應。
Sean Lin 於 2016-05-28 16:19:58 修改文章內容
商業贊助
發文數：1發表時間:2024-04-30 21:49:40
發文數：205
發表時間：2008-07-11 23:17:00
發表時間：2008-07-11 23:17:00
有夠卡的....空有外表= =...
拜託iphone 3G快在台灣上吧................
拜託iphone 3G快在台灣上吧................
easter 於 2008-07-11 23:17:00 修改文章內容
發文數：14
發表時間：2008-07-12 06:59:00
發表時間：2008-07-12 06:59:00
鑽石機是架構在微軟的 Windows Mobile 平台, 而 微軟的 Windows API 及內部很多程式是用 C/C＋＋ 語言去設計, 執行效率本來就不高!
看電腦的 WindowsXP, Windos Vista, 每一代作業系統都曾經是吃 CPU 及顯示卡資源的怪獸～
而 HTC 在設計鑽石機的觸控螢幕的應用程式, 大都還是建構在 C/C＋＋ 的平台下去設計, 換言之, 本身 Windows Mobile 已經有一大半是用 C/C＋＋ 語言去寫出來的, 而在作業系統上層的使用者程式, 又是用 C/C＋＋ 語言去寫出來... 疊了好幾層, 當然執行效率就會不好!
而 iPhone 的設計, 是 Apple 自家的 OS 去改良成適合 Mobile 系統的版本, Apple 的 OS 原自於 Linux/UNIX 精神, Apple 因為是自家的 OS, OS的底層到上層他們自己擁有完整的程式碼,
所以 Apple 當然可以特地為了 iPhone 手機, 撰寫一個特殊的 OS, 對於像 Touch Panel 以及與硬體底層溝通部份, 更是以組合語言直接編寫, 作業系統核心, 更可用更多精巧高效率的組合語言去取代, 當然不是指 iPhone 的作業系統完全都用組合語言寫成, 而是他們自己的作業系統, 可以針對某些關鍵效能部份, 用組合語言去最佳化～
所以使用者會覺得 iPhone 的 Touch Panel 跟 HTC, ASUS, TOSHIBA, 黑苺機比起來靈敏很多, 反應也很快!
Apple 這家公司, 軟體及系統整合能力是他們的專才, 旗下擁有世界全十大名校的電子電機跟計算機領域的碩士博士人才通盤操盤整個設計, 是家令人可敬的對手!
大家還是要給 HTC 加油! 畢竟鑽石機能帶給 Apple , SAMSUNG, LG, Nokia , SonyErisson 這樣可敬對手如此的震撼, 也真的是替台灣爭光!
看電腦的 WindowsXP, Windos Vista, 每一代作業系統都曾經是吃 CPU 及顯示卡資源的怪獸～
而 HTC 在設計鑽石機的觸控螢幕的應用程式, 大都還是建構在 C/C＋＋ 的平台下去設計, 換言之, 本身 Windows Mobile 已經有一大半是用 C/C＋＋ 語言去寫出來的, 而在作業系統上層的使用者程式, 又是用 C/C＋＋ 語言去寫出來... 疊了好幾層, 當然執行效率就會不好!
而 iPhone 的設計, 是 Apple 自家的 OS 去改良成適合 Mobile 系統的版本, Apple 的 OS 原自於 Linux/UNIX 精神, Apple 因為是自家的 OS, OS的底層到上層他們自己擁有完整的程式碼,
所以 Apple 當然可以特地為了 iPhone 手機, 撰寫一個特殊的 OS, 對於像 Touch Panel 以及與硬體底層溝通部份, 更是以組合語言直接編寫, 作業系統核心, 更可用更多精巧高效率的組合語言去取代, 當然不是指 iPhone 的作業系統完全都用組合語言寫成, 而是他們自己的作業系統, 可以針對某些關鍵效能部份, 用組合語言去最佳化～
所以使用者會覺得 iPhone 的 Touch Panel 跟 HTC, ASUS, TOSHIBA, 黑苺機比起來靈敏很多, 反應也很快!
Apple 這家公司, 軟體及系統整合能力是他們的專才, 旗下擁有世界全十大名校的電子電機跟計算機領域的碩士博士人才通盤操盤整個設計, 是家令人可敬的對手!
大家還是要給 HTC 加油! 畢竟鑽石機能帶給 Apple , SAMSUNG, LG, Nokia , SonyErisson 這樣可敬對手如此的震撼, 也真的是替台灣爭光!
光明天使 於 2008-07-12 06:59:00 修改文章內容
發文數：205
發表時間：2008-07-12 08:25:00
發表時間：2008-07-12 08:25:00
感謝大大～～好專業的解說!!
相信HTC一定也是很努力的去研發! 不過這次表現出來的效能的確還是讓我們失望了...
真的是需要再加油了!!
相信HTC一定也是很努力的去研發! 不過這次表現出來的效能的確還是讓我們失望了...
真的是需要再加油了!!
easter 於 2008-07-12 08:25:00 修改文章內容
發文數：2
發表時間：2008-07-14 19:35:00
發表時間：2008-07-14 19:35:00
我覺得是使用上的不習慣造成有些人使用上覺得卡卡的。
畢竟這操作介面是別家所從來沒有的。
我買了後第二個禮拜就很熟了，感覺很順很好用，朋友都跟我借去把玩.....
我實在忍不住為宏達叫好.....替台灣爭光.....
畢竟這操作介面是別家所從來沒有的。
我買了後第二個禮拜就很熟了，感覺很順很好用，朋友都跟我借去把玩.....
我實在忍不住為宏達叫好.....替台灣爭光.....
阿中 於 2008-07-14 19:35:00 修改文章內容
發文數：640
發表時間：2008-07-14 19:47:00
發表時間：2008-07-14 19:47:00
引用『光明天使』所述：鑽石機是架構在微軟的 Windows Mobile 平台, 而 微軟的 Windows API 及內部很多程式是用 C/C＋＋ 語言去設計, 執行效率本來就不高!看電腦的 WindowsXP, Win..........恕刪
真不知道在說什麼耶
API一定不可能用assembly寫，不知道怎麼讓C/C＋＋及assembly來比效率
Windows的核心原本也都是assembly寫的，是後來才慢慢用C/C＋＋替換掉
倒是Linux/UNIX從一開始開發就是以C＋＋開發聞名的，執行效率之高也一直被尊崇的
哈
C/C＋＋會被嫌執行效率不好，還是第一次聽說，不知道該說是顛倒講，還是黑白講
bluesqure 於 2008/7/14 上午 11:48:08 修改文章內容
Blue 於 2008-07-14 19:47:00 修改文章內容
發文數：580
發表時間：2008-07-14 22:25:00
發表時間：2008-07-14 22:25:00
我有玩過,讀取較慢是真的,其他的就不知道了...
小肥 於 2008-07-14 22:25:00 修改文章內容
發文數：550
發表時間：2008-07-15 09:43:00
發表時間：2008-07-15 09:43:00
引用『Blue』所述：
真不知道在說什麼耶API一定不可能用assembly寫，不知道怎麼讓C/C＋＋及assembly來比效率Windows的核心原本也都是assembly寫的，是後來才慢慢用C/C＋＋替換掉倒是Linux..........恕刪
有所同感，還有OSX到了Leopard是full ＊uix唷。真不知道在說什麼耶API一定不可能用assembly寫，不知道怎麼讓C/C＋＋及assembly來比效率Windows的核心原本也都是assembly寫的，是後來才慢慢用C/C＋＋替換掉倒是Linux..........恕刪
另外我覺得很疑惑，微軟的研發實力應該不亞於蘋果吧！
但為何Windows效能會比較差呢？
是為了相容性做出的犧牲嗎？
不知道有沒有熟OS的大大可以提出高見說明一下？
勇者米豆 於 2008-07-15 09:43:00 修改文章內容
發文數：206
發表時間：2008-07-17 10:23:00
發表時間：2008-07-17 10:23:00
別太早失望
等HTC開放新靭；體下載吧.
我把我的Diamond 從1.34版升級到1.37, 速度真的快很多!
（1.93官方版已經流出, 但我覺得沒有玩家自己改良的1.37版快）
不過目前還沒有中文介面（雖然可以下載中文字型跟輸入法）
這裡有所有關於靭；體的討論:
http://forum.xda-developers.com/forumdisplay.php?f=430
這裡有一些Diamond的tweaks:
http://forum.xda-developers.com/showthread.php?t=398265
等HTC開放新靭；體下載吧.
我把我的Diamond 從1.34版升級到1.37, 速度真的快很多!
（1.93官方版已經流出, 但我覺得沒有玩家自己改良的1.37版快）
不過目前還沒有中文介面（雖然可以下載中文字型跟輸入法）
這裡有所有關於靭；體的討論:
http://forum.xda-developers.com/forumdisplay.php?f=430
這裡有一些Diamond的tweaks:
http://forum.xda-developers.com/showthread.php?t=398265
morgan 於 2008-07-17 10:23:00 修改文章內容
發文數：5
發表時間：2008-07-27 19:23:00
發表時間：2008-07-27 19:23:00
光看這個用C/C＋＋寫出來的API效率不高的論點就知道是外行。雖然是外行，也可以說著振振有辭也
是不簡單
軟體一定是一層一層的疊出來的，不可能一整包iPhone的軟體放在一個Project裡面，這是不可能的!
另外，Linux的OS是用C語言寫出來的，不是C＋＋。Windows的OS裡面一定也有針對效能用組語最佳化的部份，這不是Apple的專利。有資歷的工程師都知道!!!
至於Window為什麼會比較慢，你有想過在不同的機器上，OS要做哪些事情嗎?
1. 要相容這麼多的資料，從Windows一出來到現在都要盡量的相容。
2.要為所有的手機的driver做好完善的保護措施，因為廠商寫的driver可能導致OS死掉。
3.非常有彈性的GUI設計，包含完善的開發環境，讓Windows GUI開發變得非常快速。
這些事情只是冰山一角。為的就是保有過去windows擁有的客戶群。
是不簡單
軟體一定是一層一層的疊出來的，不可能一整包iPhone的軟體放在一個Project裡面，這是不可能的!
另外，Linux的OS是用C語言寫出來的，不是C＋＋。Windows的OS裡面一定也有針對效能用組語最佳化的部份，這不是Apple的專利。有資歷的工程師都知道!!!
至於Window為什麼會比較慢，你有想過在不同的機器上，OS要做哪些事情嗎?
1. 要相容這麼多的資料，從Windows一出來到現在都要盡量的相容。
2.要為所有的手機的driver做好完善的保護措施，因為廠商寫的driver可能導致OS死掉。
3.非常有彈性的GUI設計，包含完善的開發環境，讓Windows GUI開發變得非常快速。
這些事情只是冰山一角。為的就是保有過去windows擁有的客戶群。
hawkeye 於 2008-07-27 19:23:00 修改文章內容
發文數：550
發表時間：2008-08-12 14:30:00
發表時間：2008-08-12 14:30:00
引用『hawkeye』所述：至於Window為什麼會比較慢，你有想過在不同的機器上，OS要做哪些事情嗎?1. 要相容這麼多的資料，從Windows一出來到現在都要盡量的相容。2.要為所有的手機的driver做好完善的保護措施，因為廠商寫的driver可能導致OS死掉。3.非常有彈性的GUI設計，包含完善的開發環境，讓Windows GUI開發變得非常快速。這些事情只是冰山一角。為的就是保有過去windows擁有的客戶群。..........恕刪
果然為了相容性有犧牲一定的效能...
感謝大大專業的解說︿_︿
midosogi 於 2008/8/12 上午 06:31:50 修改文章內容
勇者米豆 於 2008-08-12 14:30:00 修改文章內容
發文數：554
發表時間：2008-08-12 21:45:00
發表時間：2008-08-12 21:45:00
引用『勇者米豆』所述：
引用『hawkeye』所述：至於Window為什麼會比較慢，你有想過在不同的機器上，OS要做哪些事情嗎?1. 要相容這麼多的資料，從Windows一出來到現在都要盡量的相容。2.要為所有的手機的dri..........恕刪
謝謝各位網友提供個人看法和專業資訊分享，主流和非主流的存在皆有其必要性。
引用『hawkeye』所述：至於Window為什麼會比較慢，你有想過在不同的機器上，OS要做哪些事情嗎?1. 要相容這麼多的資料，從Windows一出來到現在都要盡量的相容。2.要為所有的手機的dri..........恕刪
☆水☆ 於 2008-08-12 21:45:00 修改文章內容
發文數：1
發表時間：2008-08-14 22:29:00
發表時間：2008-08-14 22:29:00
我覺得用C / C＋＋程式, 看過其反組譯的人都知道, 程式的最佳化都取決於Compiler本身設計之優劣.
而最佳化有時往往都是要看一段程式後, 才能決定最佳化的方式,
而C / C＋＋其中一個好處是subroutine裡local variables,
平庸的Compiler, 不但一句一句編輯, 若一句裡存取local variables的話, 即使離開subroutine時local variables已不存在（需經過二次compile流程以上才會得知）, 它還是從Stack （Memory） 讀出來, 經過運算, 再存回從Stack （Memory）. 這樣不但指令多且佔用CPU執行資源
而具有最佳化的Compiler, 大都會將local variables, 套用CPU的Registers（暫存器）, 這樣效率會好一點, 但針對C語言的程式碼之編譯, 仍比不上目前工程師的頭腦. 尤其是一段稍微複雜的C程式.
而組合語言的好處, 工程師對於local variables大多會使用Registers, 而且會針對一段C程式做整體的最佳化, 但這取決於工程師的Coding能功
但C/C＋＋最大好處就是相容性高, 移植性也高
而最佳化有時往往都是要看一段程式後, 才能決定最佳化的方式,
而C / C＋＋其中一個好處是subroutine裡local variables,
平庸的Compiler, 不但一句一句編輯, 若一句裡存取local variables的話, 即使離開subroutine時local variables已不存在（需經過二次compile流程以上才會得知）, 它還是從Stack （Memory） 讀出來, 經過運算, 再存回從Stack （Memory）. 這樣不但指令多且佔用CPU執行資源
而具有最佳化的Compiler, 大都會將local variables, 套用CPU的Registers（暫存器）, 這樣效率會好一點, 但針對C語言的程式碼之編譯, 仍比不上目前工程師的頭腦. 尤其是一段稍微複雜的C程式.
而組合語言的好處, 工程師對於local variables大多會使用Registers, 而且會針對一段C程式做整體的最佳化, 但這取決於工程師的Coding能功
但C/C＋＋最大好處就是相容性高, 移植性也高
杰克 於 2008-08-14 22:29:00 修改文章內容