(1) HERO操作的順暢程度直逼iPhone 3G，除了JNI寫得夠最佳化，是否更應歸功於Byte code與JNI的互動執行效能比傳統Java VM的高很多，也就是Android的Java code與JNI之間的聯繫機制、路徑與過程比傳統Java VM的精簡很多？
Android JNI本身的overhead比較小？
若就未最佳化過的原始碼而言，其實並不明顯，例如jserv大的文章對 String 操作的改進可以看到，Android JNI本身的overhead其實已經有點拖累到JNI method本身所帶來的效能增進。
但為什麼HERO還是可以這麼順暢？
通常程式最佳化必須作詳細的profiling，歸納所有影響程式運作速度的因素，還要持續不斷的測試與改進，這已經不是你我在這裡討論就能得到答案的。
去tune JNI的overhead過高的問題，可能是一個因素，但是也有可能是去最佳化底層window system架構或者是最佳化FrameBuffer的使用方法。
(2) 因為JNI寫得好不好會直接牽涉到使用者操作UI時順不順暢，而Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決，所以才聽說HTC用最多的人員來研發Android手機，全因Android官方太不負責？
通常Android底層native code release出來時，只會有某個特定的architecture，例如arm-v5t，但是如果系統廠只有mips或ppc的板子，當然就只能自己去porting或實作了。
Android source code釋出時，只能叫reference implementation，其他的手機系統廠必須各自努力tune成有商業化產品的水準。Android source code基本上是免費的，而Sun在license CLDC/CDC VM source code時，開出的可是天價。
至於您提到Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決，小弟目前沒有看到過。
(3) Android是全套採用Java VM概念所設計的手機、行動裝置及攜帶型電腦通用的作業系統，主要原因是否如下？
a. VM安全穩定不影響正事，VM內執行的軟體想故意癱瘓整個系統讓手機無法接打電話可說是不可能的任務
b. Java易跨平台，各平台現成的Java程式可以很容易移植過來，同一Android軟體可在不同的硬體平台直接執行
c. Java的速度不是問題，真正需要高效能的地方就交給JNI直接用C/C++實作或硬體晶片解決，何況CPU的摩爾定率也會來幫忙
如同小弟之前就已經提到的，Android的VM是Dalvik VM，不是Java VM。兩者從OS process管理, IPC API支援, bytecode execution, class loader等，都天差地遠。
您說的沒錯，採用VM架構的優勢就是managed runtime environment與跨平台。
另外補充的是，其故意的在Framework API中整進了Apache Harmony 的J2SE API與HttpClient 4.0 API，就是為了拉攏平常都在server side開發的engineer們，讓他們能夠在短時間之內加入Android 程式的開發者行列，把所有的網路服務都放在Android平台上，這與Google一開始研發Android的立意是相呼應的。
(4) 目前Android上的各類遊戲平台模擬器實作出的聲光效果及可玩性如何？ 有聽說大陸的山寨廠要出PSP外型的Android遊戲手機了嗎？ (若想等HTC或SAMSUNG等大廠出智慧型遊戲手機大概還要等很久吧，而NOKIA的N81遊戲手機又做得不乾不脆且後來也沒什麼後續機種來接棒，雖然N97也可算是比N95、N86方便玩遊戲，但應該都不算是N81遊戲手機的接棒機種吧，何況現在N97、N86鏡頭會刮傷問題NOKIA根本擺爛不想回收處理，實在令人搖頭)
Android的模擬器目前我只知道是有SNES版的。
另外，如Qualcomm的Adreno Graphics有釋出一個透過OpenGL ES寫出的小遊戲：ARMADILLO ROLL
我想只要Android手機市佔率越來越高，應該會有更多的遊戲出現才是。
cbmtvb wrote:
而Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決，所以才聽說HTC用最多的人員來研發Android手機，全因Android官方太不負責？...(恕刪)
JNI 是 Java Native Interface 的縮寫, 顧名思意, 它只是一種 Java 端與 native 端的溝通的界面 (橋樑). 在下過去曾有一段時間利用 Java 開發程式. 那是 JDK 1.3.5 左右的年代... 當時的 JNI 對我而言真得是惡夢一場...
程式因為橫躍 Java 與 native 兩端, 而難以除錯不說... 它得效率真的是 %$#@...
如果可以在 Java 端完成的運算, 決不輕易透過 JNI 放到 native 端算... 即使 Java 運算較慢, 也遠快過 JNI 溝通...
數年之後, 當我在 Android 上再次與 JNI 相遇. 說真的... 我大吃一驚, 過去如同南北半球的兩端, 現在的溝通速度竟快如隔壁而以... 以下網址的倒數第二段是 Android 官方提出的程式執行速率...
可以看到, 它的 JNI 呼叫速度, 竟已快過 Java 端其它函式的呼叫速度了...
Designing for Performance
扯太遠了...
我想您所說的 "Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決" 這句話, 是否是對於之前在下在其它篇的說法有所誤解... 如果是, 我想我必需澄清...
我的意思是 Android 在 native 端的許多機制都還沒弄好, 而非 JNI 沒弄好, 畢竟 JNI 只是個橋樑...
雖然 Android 並沒把許多我認為該稿好的事情 (如錄音) 弄好, 造成諸如 HTC 等開發商得耗費大量人力解決...
但因此說 Android 官方不負責, 我覺得太過...
畢竟 Android 是個很新很新的平台, 拿它來跟 WM 的成熟度相比, 並不洽當...
我認為 HTC 等開發商在評估時, 就已經能瞭解這個狀況, 也可以推斷自己得投入大量的人力... 誰叫它要搶頭香...
在我眼裡, HTC 至少已經付出它該有的人力資源來修改 Android 不足之處...
如果有開發商在推出 Android 手機前, 沒先用對應的資源來修正這些問題, 只想把 Android 直接灌上手機了事...
我會認為它該被譴責, 它並未盡到該有的責任, 它等同於是欺騙消費者...
這樣的開發商, 只有資格去玩 WM 這種成熟平台, 沒資格稿 Android...
PS. 我並未意指現在檯面上的 Android 開發商, 而是汎指現在與未來的 Android 開發商...
addre wrote:
我認為 HTC 等開發商在評估時, 就已經能瞭解這個狀況, 也可以推斷自己得投入大量的人力... 誰叫它要搶頭香...
在我眼裡, HTC 至少已經付出它該有的人力資源來修改 Android 不足之處...
如果有開發商在推出 Android 手機前, 沒先用對應的資源來修正這些問題, 只想把 Android 直接灌上手機了事...
我會認為它該被譴責, 它並未盡到該有的責任, 它等同於是欺騙消費者...
這樣的開發商, 只有資格去玩 WM 這種成熟平台, 沒資格稿 Android...
PS. 我並未意指現在檯面上的 Android 開發商, 而是汎指現在與未來的 Android 開發商...
呵，現在很難有公司跟 HTC 這樣搞了吧。
看起來 HTC 在兩三年前就開始往 Android 佈局，
但是市場炒熱之後，大多公司可能不願意花這麼多時間做基本功。
估計一般可能都規劃九個月到一年完成產品，成熟之後也許更會要求縮短到半年呢。
對很多公司來說，的確是只想把 Android 弄上手機就了事的...
沒有說哪種好哪種不好，我只是很欣賞 HTC 那種願意耕耘的態度罷了。
哪些產品才擁有靈魂，相信消費者也是能看出來的。
addre wrote:請問那會不會現在的Sun Java VM及其他各類byte code語言(如Python,Perl,Ruby)的VM的JNI機制速度其實也都跟Android一樣早就不可同日而語了？
數年之後, 當我在 Android 上再次與 JNI 相遇. 說真的... 我大吃一驚, 過去如同南北半球的兩端, 現在的溝通速度竟快如隔壁而以... 以下網址的倒數第二段是 Android 官方提出的程式執行速率...
可以看到, 它的 JNI 呼叫速度, 竟已快過 Java 端其它函式的呼叫速度了...
Designing for Performance
addre wrote:感謝您指正，不過小弟原本心中的意思就是如您說的「 JNI 在 native 端的許多機制」，只是偷懶加上不知怎講就只寫了 JNI ~~
我想您所說的 "Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決" 這句話, 是否是對於之前在下在其它篇的說法有所誤解... 如果是, 我想我必需澄清...
我的意思是 Android 在 native 端的許多機制都還沒弄好, 而非 JNI 沒弄好, 畢竟 JNI 只是個橋樑...
雖然 Android 並沒把許多我認為該稿好的事情 (如錄音) 弄好, 造成諸如 HTC 等開發商得耗費大量人力解決...
但因此說 Android 官方不負責, 我覺得太過...
畢竟 Android 是個很新很新的平台, 拿它來跟 WM 的成熟度相比, 並不洽當...
而「HTC花最多的人力來開發Android手機，有人抱怨是Android自己很多工作沒做好」則是小弟聽自癮科技網友的回應。
可否再請教大家三個問題：
1. 由於Android每個程式都有自己的VM，那是否常駐的公用程式會較難寫，例如dr.eye譯典通若想出Android版，會不會很難達成在閱讀網頁、PDF、Word及其他文件格式時都能「隨指即查」？
(額外一問：目前Android上已有字典軟體支援「隨指即查」嗎？)
2. 像Android這樣每個程式都有自己VM的OS聽說是不是早在使用COBOL語言的大型主機就已經實現了？ 目前PC可用的OS除了Android外，還有其他OS也是像這樣每個程式都有自己VM的嗎？
3. Python在前台(指一般應用)及後台的應用率應該也不會差Java很多吧，而寫Python比寫Java簡單很多應該也是事實吧，那請問大家會不會比較希望Android是用Python而非目前的Java？
如果樓主不相信,請參考下列資料......:
1.有網站針對各種程式語言的速度競賽,雖然Java跟使用GUN compiler的C/C++相比還是略遜一籌,但是速度的差距不大 (相較Python速度已經差到40x),而且跟其它intepreter的語言比起來,Java是最快的....
The Computer Language Benchmarks Game
2.用Java語言實作的Quake2,在某些測試環境下,比C實作的版還要更快:
Jake2
3. Wiki有說出Java在速度上表現比C/C++更為優異的地方
Java Performance
3. C/C++是透過compiler轉成native code,同樣的Java是透過Just-in-time compilation將byte code轉成native code,所以C/C++和Java是同一個層級,只要Just-in-time compiler設計的好,能夠達到同樣的效果....
----------------------------------------------------------------------------------------------------------------
還有使用JNI不是因為C/C++比Java快的緣故,如果天真的以為使用C/C++來取代Java作運算,速度能夠突飛猛進,那是浪費時間.....建議使用JNI的條件如下:
1.對特定硬體最佳化,例如使用特定CPU的指令集(例如: SSE, MMX)或是呼叫內建的晶片來硬解H.264影片等等,通常是用組合語言撰寫的...
2.呼叫特定作業系統的功能....例如要使用Hook去攔截windows所發生的事件或是呼叫OpenGL/CL指令集
3.現成的Library是用C/C++撰寫的,何必浪費時間在移植到Java上
-----------------------------------------------------------------------------------------------------------------
最後現在電腦速度的瓶頸不是在程式語言,而是在I/O和多媒體處理上面....像是上網是電腦在等網路下載.....,玩3D遊戲是要看GPU的繪圖速度等等??
3. Python在前台(指一般應用)及後台的應用率應該也不會差Java很多吧，而寫Python比寫Java簡單很多應該也是事實吧，那請問大家會不會比較希望Android是用Python而非目前的Java？
如果參考Benchmark的結果,在PC上Java和python的速度是天差地遠.....但是Google重新實作python版本的interpreter會不會快很多說就很難說了....
The Computer Language Benchmarks Game
而且如果參考tiobe的統計資料,Java目前是最多人使用的程式語言,Python相較之下顯得較冷清~
TIOBE
amosho.tw wrote:
如果 Java 應用程式執行效能 "遠" 不如原生機器碼.那就不會有這麼多商業應用採用 Java ...(恕刪)
cbmtvb講的是有一定的道理的,
商業應用採用講求的並不是效能, 商業應用採不代表什麼
你用 java 寫一個 h.264 的解碼程式, 跟用 c++ 寫一個就可以發現
原生機器碼跟直譯式的效能真的是天差地遠,
看所有的轉檔程式都是用什麼寫的就知道了
不要說,可以直接控制硬體, 可以使用 Point(指標) 的操作就可以比 bytecode 快上很多
但如果你只是試試UI的操作速度, 那差異真的不大
效能不是測測UI的更新速度看起來差不多, 就導致二種語言效差不多的結論
" Java 應用程式執行效能 "遠" 不如原生機器碼."這句話依然成立
還到真的吃效能的軟體, 大家一樣都乖乖的用 c/c++ 寫
如果說原生碼有東西是做不到的, bytecode 一樣有有做不到的東西.
例如最低階的硬體控制
"Byte code的重點在於你不需重新編譯，使用者可以把同一套軟體直接安裝再多個不台架構的平台"
這個所謂的優點也是是直譯式語言的缺點所在, 就是因為要相容於所有的硬體, 在上面多一層VM 導致直譯式語言的效能低於原生碼
即使是用JIT complier也比不上C++complier.
不過實際上軟體會不會被Java拖累, 要看這軟體本身的瓶頸在哪?
Java程式碼跑的比較慢不代表軟體會跑的比較慢.
如果某軟體是吃重在GPU效能或受限於記憶體頻寬, 使得CPU常常處於閑置.(滿載率低於50%)
那麼CPU發揮了60%還是90%根本沒差. 這時Java的效能好壞就不可能造成問題.
所以有些人寫軟體的經驗認為Java不會比C++慢
有些人的經驗卻是C++快很多.
因為每個軟體吃重的地方不同. 根本沒有固定的結論.
I/O和多媒體處理過度吃重的軟體就比較不care效能.
反正軟體本身的瓶頸通常不在CPU上,你就算用Basic也不見的比較慢.
而且硬體的效能已經超越過去太多.有的CPU甚至有8核心.
某些軟體根本已經用不到這麼多CPU處理能力.
例如,如果你要移植任天堂的超級瑪莉1到Gphone,其實用多慢的語言都無所謂啦,
人家當初用3.5Mhz 8bit CPU就跑了,就算語言慢一百一千倍, 隨便一隻濫手機也能跑的嚇嚇叫.
用Java語言實作的Quake2,在某些測試環境下,比C實作的版還要更快:
這是另一種特殊情形
其實不是因為Java已經比C有效率,而是因為C的缺點就是沒有辦法對後來硬體最佳化.
一開始就編譯成執行檔了,就算拿最新的CPU也是只能照20年前的指令來跑.
例如以前pentium時代的軟體,compiler出來的東西,
不可能會對未來的MMX,3Dnow,SSE...等SIMD加速指令最佳化.
只會傻傻的用古老最慢的 X87 FPU指令.
Java則是到了硬體上再編成機器碼,它的即時compiler當然知道目前硬體規格.可以做點最佳化.
另一種情形是大型軟體可能會用好幾種語言來寫.例如3D遊戲
某些語言雖然慢了50倍以上可是還繼續使用.例如Lua.
因為有些工作只佔CPU的1%工作量, 用C卻需要幾倍的時間來撰寫和改版.可能佔10%以上的軟體製作時間.
那1%的工作量, 就算用很好寫,但執行效率低10倍的程式語言取代.
對整體效能的影響也不過是0.x %.....根本無所謂.
其他99%真的吃效能的部分, 一樣乖乖用 c/c++.
Android的OS底層應該也是一大堆C++.
只是把應用軟體用 Java來寫.
所以只要Java軟體有用到OS提供的功能,其實多少還是有部分時間受惠於C++的高效率.
內文搜尋