• 8

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

rheinhard wrote:
我是程式設計的外行人,看到這裡就我的理解,Android的系統架構是
App-VM-Andorid(Linux) 這樣沒錯吧?
我不懂的是為什麼Google要多加一層VM?
直接 App-Android(Linux) 不是更快嗎? 為什麼要多加一層VM來拖慢執行效率?
沒有這一層VM的話,程式就可以用C/C++來開發,這不是一舉兩得嗎?
能不能請懂這原因的網友解譯一下給我這外行人聽
VM好處之二:
程式設計師免費心 for 不同CPU架構要對應不同的執行檔
保證系統絕不會被app拖垮而影響基本的接聽電話功能

rheinhard wrote:
我是程式設計的外行人,看到這裡就我的理解,Android的系統架構是
App-VM-Andorid(Linux) 這樣沒錯吧?
我不懂的是為什麼Google要多加一層VM?
直接 App-Android(Linux) 不是更快嗎? 為什麼要多加一層VM來拖慢執行效率?
沒有這一層VM的話,程式就可以用C/C++來開發,這不是一舉兩得嗎?
能不能請懂這原因的網友解譯一下給我這外行人聽


1. linux執行檔在不同cpu 是沒法互通的, build給x86 linux的ls 拿到arm linux底下是不能跑的.
2. 現在都要求有個safe runtime environment, C/C++有pointer這玩意, 在語言的層次上讓app任意access記憶體是危險的, 換個語言弄個VM才有機會把所有的memory access都攔住.

昨天剛第一次玩android SDK, 直上android 2.0 emulator. 只有一個感覺 It's so fucking slow~~~
changtimwu wrote:
昨天剛第一次玩android SDK, 直上android 2.0 emulator. 只有一個感覺 It's so fucking slow~~~

emulator會快的話那就很神了……
emulator 的確很慢啦 就算你直上2.0也是一樣
而且對於記憶體跟CPU的運用也是大的嚇人(你隨便拉個畫面移動 , 就可以看到CPU被吃掉一半~)
但是上到手機上 又沒那麼嚴重離譜 我想應該是android 的code 是針對ARM的CPU作開發的
所以就算是用PC模擬 效率還是沒ARM的有利

真的 這篇討論串真的超優質!!!
沒有叫囂謾罵 , 只有觀念討論 !!!

其實你去看Android的官網, 他也提供出NDK讓使用者開發JNI的部份了
所以我相信JNI的開發也會越來越蓬勃

不過我也覺得怎麼去對硬體優化或是使用上更快的JNI
Google也真的沒有一定要開發的必要, 畢竟硬體那麼多 google就算怎麼有錢
也很難全都照顧到, 不如就留給硬體廠商去處理,畢竟那是她們自己的產品
怎麼去運用或是優化也是她們最明瞭..

所以我對Google的想法 是還站在贊同的立場!!
Java 之所以會慢, 跟 programer 的寫作技巧有很大個關係

Java 經常被貼上一種標籤 "programer 的初學者學 java 很好, 簡單易懂且開發快速, 又是OO"

這個觀點基本上就已經註定 java 的 performance 的悲劇

1. 初學者 (不用說, 一定在亂寫, 慢是正常的)
2. 簡單易懂 (沒有一個 程式語言是簡單易懂的, 沒有深思熟慮的寫 code, 寫出的東西品質一定很差)
3. 開發快速 (想開發快速的 programer, 會有那個心去 tune 效能嗎?)
4. OO (大部份的 programer 都是在不了解有幾個老爸老媽表哥表弟下硬幹的, 生出一隻滿身贅肉的程式 也是很正常的)


老練的 java programer 可以寫出像愛爾蘭踢踏舞王那樣又輕又快的程式, 只是這種人要多半要在 java 上打滾很久,少之又少, 因為80%喜歡寫 code 的programer 都喜歡碰新玩意 (因為自我感覺良好), 舊 code 就留給別人改, 開發過程的產生的新的想法和經驗便無法延續到下一版自行實現, 要寫的更精舊比較難了


C 的好處剛好相反, 先天的效能優勢可以彌補 一點點亂寫 的衝擊, 而大部份的東西要自己張羅, 所以 programer 本身比較清楚來龍去脈, 寫或改起來反而比較不容易錯, 當然開發會比較久, 但在台灣加班是不給錢的, 所以如果要寫的快又跑的快, 用 C 加班加到死是最安全的做法
實測的Dalvik的效能.....其實比Java還差一點.
因為沒有JIT compiler.

如果程式主要的工作是呼叫OS內建的API來計算,那速度大概OK.
因為那些google程式應該是用C++寫的.效率不錯,
若是自己寫的複雜的運算大概是沒辦法跑的快, 因為全是Dalvik.
完全是直譯.....

Dalvik不用JIT compiler. 優點是可以把記憶體需求壓到最低, 以利於多工穩定性.
所以低規格硬體也可以跑Android,而且可以很穩.
低階128MB RAM的Android機種扣掉OS佔用的,只剩幾十MB可用....卻還可以多工.
(中低階WM6就很難這麼穩,記憶體不足就當機......iphone則是限制單工來控制記憶體需求....)
但是未來的Android高階機種就有點尷尬, 如果有448~1024MB記憶體,
節省記憶體的意義不大, 反倒是效能衝不上去.

程式再怎麼優化也有限度, 有時候演算是卡在幾個重複運算的迴圈.
已經簡單到沒法再最佳化, 效能已是受限在直譯的效能耗費了.
這時只有兩種選擇, 用事先編譯的C++或是JIT compiler.

NDK的JNI似乎只能輔助Dalvik, 沒辦法全用JNI寫軟體.
不過應該還是有點幫助......但c++可能破壞跨硬體(Arm,X86...)的相容性.
畢竟我們希望Android可以跨到筆電和桌機,那是X86的領域.
VM是很好的東西, 能讓一個軟體從低階手機到筆電桌機都能跑,
對軟體開發者是最理想的.
如果想維持Dalvik軟體可以在任何CPU執行的優點, 又不犧牲太多效能,
長遠來看,還是JIT compiler比較符合需求.

個人還是希望未來Android3.0至少實做Arm版JIT compiler.
(這個功能google可以用收費的方式做 , 只有OS是免費, 其他功能另計)
低階機種要省記憶體, 就照原本的直譯VM來做......反正只要基本PDA功能的話, 效能需求不高.
性能需求高的機種,有可能想跑類似Iphone上複雜的3D遊戲,就內建JIT compiler
.......反正高階機種記憶體多的是.
Android 1.6 CyanogenMod-4.2.5

JIT in Dalvik JVM
http://forum.xda-developers.com/showthread.php?t=585609

在 G1 上實測,確實明顯感受到效能提昇 (with 10m ram hack)。
changtimwu wrote:
1. linux執行檔在不同cpu 是沒法互通的, build給x86 linux的ls 拿到arm linux底下是不能跑的.
2. 現在都要求有個safe runtime environment, C/C++有pointer這玩意, 在語言的層次上讓app任意access記憶體是危險的, 換個語言弄個VM才有機會把所有的memory access都攔住.


執行檔在不同CPU架構下不互通我是知道的,
但是,我倒是真的沒想到用Java VM是為了避免App直接存取記憶體,
不過,只要C/C++的程式設計師不要錯用pointer的話,應該也是ok的吧
cava wrote:
C 的好處剛好相反, 先天的效能優勢可以彌補 一點點亂寫 的衝擊, 而大部份的東西要自己張羅, 所以 programer 本身比較清楚來龍去脈, 寫或改起來反而比較不容易錯, 當然開發會比較久, 但在台灣加班是不給錢的, 所以如果要寫的快又跑的快, 用 C 加班加到死是最安全的做法


我因為對程式設計有一點興趣,所以常常在書店翻閱一些相關書籍,
就我所讀到的軟體開發的觀點,撰寫程式最好是使用標準的API,
如此才能兼顧到可攜性及效能,
如果programmer常常用非標準API的技巧來硬幹的話,
輕則失去可攜性,重則危及系統穩定性或安全性,

另外,大部分東西都要自己張羅的話,那programmer開發起來不就很吃力,
其他人若要來維護程式的話,也因為那些硬幹出來的程式碼不易閱讀而導致程式維護困難,
就軟體工程的觀點來看,這樣反而比較不好吧!

另一方面,台灣programmer加班沒有加班費,唉...,也不知道該說甚麼了,
在知識經濟的時代,這大概也是台灣只能做硬體代工而發展不起軟體產業(及其他創意產業)的原因吧!
有看有推!
這篇的討論串真的很有內涵
對於觀念的論述與辯證非常精彩!
  • 8
內文搜尋
X
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 8)
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?