yrulee wrote:
小弟之前有研究過CDC VM (藍光播放器中的Java VM)，是SUN的RI (參考實作版)，從interperter, JIT compiler到GC都有看過原始碼, 最近也在看Android的Dalvik VM，以下有一些心得可以跟您分享
說的很好也很完整吶... 幫您家個分。
用大家都懂的例子來說好了，
大家都知道電腦自己去光華商場訪價買零件組裝再自己安裝軟體最省錢效能也最好，
那這樣品牌電腦的優勢在哪邊呢？
我自己覺得優勢在於下面幾點：
1. 用 Java 來開發在某方面來說是很聰明的，現在很多學生第一個學的語言就是 Java，
學校會選擇以 Java 當作入門也不是沒有原因的。
2. 良好的 framework 不但好用，而且能減少開發者的負擔，而且讓系統更穩定。
大家都想在自己的手機上安裝各式各樣的軟體，
但是沒有人會希望安裝了很多軟體之後系統會容易當機或是效能降低...
3. 應用程式-VM-kernel 這樣的三層架構，不覺得很不錯嗎？
能在系統資源有限的手機上做到這樣，實在是很厲害呢。
效能... 等時間到了我去買隻 hero 來玩玩看，就會知道啦～
cbmtvb wrote:
可是這篇沒說Andr...(恕刪)
剛好相反, 這一篇已經完全說明了Java這個語言在Android平台上的運作方式有多大的差別.
既然google的開發者從底層開始就重新打造一個新的VM, Java變成了一個開發的語言, 而不是一種執行環境.
就不能拿舊有的SUN Java VM的執行速度來看待, 而是要看google如何重新的把用"Java語法"所寫的code.
如何去產生出一個針對新VM所進行優化的byte code.. 如果速度上跟舊的一樣快, 那google幹嘛重寫呢..
其實相關的資料去網路上查一下就一堆了.. 你可以試著去查一下..
http://janla.javaeye.com/blog/400442
這一篇在講google針對Android平台上做了那些VM的最佳化..
http://jserv.blogspot.com/2009/08/beagleboard-dalvik-cvm-jit.html
這篇還有速度比較的圖表, 很清楚也很明顯
----
另外, 講一下題外話, 其實就算是在常見的PC平台上, 現在Java 1.6 的速度早已經今非昔比了.
JIT與Hotspot計劃進展了這麼多年, 現在的執行速度已經不比原生性語言差了.
會有Java執行速度比較慢的想法, 大概是當時1.2~1.3版時留下來的印象比較多.
chihyi1980 wrote:第一篇有試圖解釋Android執行的Java為何能比我們過往印象的Java快很多，但可惜未能實測在同一硬體下Android Java、Sun Java、WM C++的效能評比以證明所言不假。
http://janla.javaeye.com/blog/400442
這一篇在講google針對Android平台上做了那些VM的最佳化..
http://jserv.blogspot.com/2009/08/beagleboard-dalvik-cvm-jit.html
這篇還有速度比較的圖表, 很清楚也很明顯
第二篇則是同一硬體下Android Java、Sun Java的效能評比，但整體分數為：Dalvik VM : 1034、CVM + jit : 7526，Android Java根本被Sun Java巴假的，相信比起WM C++會更慘，這種「笑」能怎麼跟大家推崇的效能完全相反？
你看第2張圖並沒有再多Process上做比較你知道Dalivk再多執行序上跑的更好嘛？
我想你可以試著寫一支WinCE上的Program和Android的Program來看看你所謂的效能是否能有感覺？
說真的...我很不以為然你發這類的文章，明顯的你不是技術人員而且你對整個系統居然只在於Native code...對了Windows C++<==我們再Embedded System中稱之為Navice Language ，效能是整體性非單一語言可以決定.....
請你以Windows CE/Mobile/Android/OpenEmbedded整體比較考量才有意義
對了Windows C++<==被組語的笑能巴假的
風之心
跟風一樣
來無影去無蹤
simonchung wrote:Byte code在Server端後台應用大為盛行的主要原因之一應該是為了方便應付Server端多樣的硬體平台吧，尤其很多用的根本不是x86相容指令集的CPU，如果每次硬體升級轉換不同平台就要請專業人員重新編譯、除錯後台軟體，那實在很不符Server後台程式要穩定、不中斷的基本要求吧。
目前 Java 最大的應用並不是 applet 這類的平台，而是 server 級的後台應用。
byte code 如果"笑"能不好，我想 .net framework 沒必要也導入 CLR 這種跨各種 windows 平台的概念。
但是一般桌機、掌機使用者並不太需要他買的軟體在各種平台都能跑，他需要的是熟悉的UI，順暢的操作效能，以及在較低、較基本的軟硬體配備下也能直接安裝、順利執行。而以上這些需求剛好都是Java、.Net這兩大Byte code執行環境較為人詬病的地方，例如XP的Java及.Net執行環境都要另外安裝才有，而.Net版本之多且好像都要分開裝則更讓人頭大，而且還聽說似乎裝了.Net後系統整體效能及穩定度會整個下降不少。所以不少使用者 (包含小弟我) 對於 Java 或 .Net 的應用軟體大都敬謝不敏，除非沒得選擇才會用看看。
而一般桌機、掌機的應用軟體廠商對於Byte code執行環境的接受度為何也比Server端後台應用軟體廠商低很多呢？ 難到前者不希望他的軟體可以很容易在各種平台也都能跑、也都能賣錢嗎？ 個人覺得除了前述因素導致使用者需求不高外，另兩個主要原因其一是Server端後台應用軟體本身並沒有什麼UI需要處理，但一般桌機、掌機的應用軟體在各種OS平台的UI可能會有極大的在地特色差異需要各別處理，即使用Byte code執行環境也需要處理這部份的差異；原因其二是即使用C++一樣不難跨平台，例如採用Qt、wxWidgets等跨平台UI，這樣即可跨平台又可免除前述之使用者對Byte code的疑慮。
以上不太專業的回應有一些是小弟自己合理的推論，有錯尚請指正。
內文搜尋