Java的笑能有可能是Android的最大敗筆嗎？

cbmtvb wrote:
Java的笑能有可能是Android的最大敗筆嗎？

Android官方標準的程式開發環境是Java，所以目前的應用軟體應該大部份是用Java寫的吧，而眾所周知Java的執行是直譯式而非如C/C++ /objC是編譯式的，直譯式的優點是較易達成單一程式碼跨軟硬體平台直接執行，但這點Java也好像只有在瀏覽器內執行的Java applet做得較為成功，至少還能跟Flash鼎足而立；而直譯式的超大缺點則是執行效能遠低於編譯式的，以及無法做到跟系統較為相關的應用，再加上優點達成率低或單一程式碼跨平台的需求不高，因此也造成目前Win、Mac、Linux等三大桌機OS上的知名或常用的應用軟體用Java寫的仍寥寥可數。

Android採用Java的優勢似乎看不太到，但Java直譯式的執行效能遠不如編譯式的原生機器碼應該是千古不變的真理吧，所以在此請教大家，Java的笑能有可能是Android的最大敗筆嗎？

chihyi1980 wrote:
剛好相反, 這一篇已經完全說明了Java這個語言在Android平台上的運作方式有多大的差別.

既然google的開發者從底層開始就重新打造一個新的VM, Java變成了一個開發的語言, 而不是一種執行環境.

就不能拿舊有的SUN Java VM的執行速度來看待, 而是要看google如何重新的把用"Java語法"所寫的code.

如何去產生出一個針對新VM所進行優化的byte code.. 如果速度上跟舊的一樣快, 那google幹嘛重寫呢..

larz93 wrote:
再說android免授權費又開源，google又不是佛心來著，無聊燒錢寫一套作業系統送給手機製造商
當然想靠平台優勢大力推廣內建的各項google服務，手機的性能只要能跑瀏覽器就夠了，執行速率變的很次要，我惡意的猜測，這也是dalvik vm遲遲沒有JIT的原因，因為google根本不在意單機的效率，一切皆交給雲端計算

yrulee wrote:
不用猜測，影片是DalvikVM的開發leader解說DalvikVM內部架構
拉到 00:20:00 有講到為什麼不用JIT的原因

而且就我對JIT的了解，在Android手機這種計算資源與記憶體資源皆有限的環境下，用JIT效能反而會更差。

目前開發社群已經出現很多聲音抱怨Dalvik效能太差，要求趕快加入JIT的支援，有人甚至在研究如何將DEX放到CVM上執行

JIT消耗資源的多寡，其實要看演算法，google的說法不一定正確，V8比tracemonkey快了兩到三倍，但資源消耗也是兩到三倍，這類空間與時間的tradeoff不用我多說吧

android手機的資源有限，這是相較於PC的說法，支援multitouch的智慧型手機最起碼的市場定位也是高階，沒道理更低階的java手機能從JIT受益，高階的android反而不行

簡單說吧，JIT只是一項選擇，若目標手機的記憶體真的太少(山寨廠?)，手機廠可以關閉JIT

JNI不是萬靈丹
1.這個機制本身就有一定的overhead
2.要預先編譯為native code，所以只適合系統開發者(手機廠的工程師)；由於android硬體的開放性，應用開發者用了反而會喪失可攜性

我認為google沒有實做JIT的原因
1.android硬體架構為開放性，而JIT這種高度硬體相依的軟體，google認為是手機廠的責任
2.07年就有android的消息，但到08年十月才有第一支android手機上市，可說延遲了不少時間，而JIT又是非常複雜的技術，若要實做、驗證JIT，所花費的時間不利於推廣android的時程

我認為google應該定義JIT的介面，實做與硬體架構無關的前端(parser, optimizer)，然後留下後端的介面給手機廠去實做

rrl wrote:
順便一提
基於Android的掌上遊戲機已經出現
http://www.hardkernel.com/

rheinhard wrote:
我是程式設計的外行人...(恕刪)