• 8

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

Byte code的重點在於你不需重新編譯,使用者可以把同一套軟體直接安裝再多個不台架構的平台,另外誰說C++移植容易的?你該不會認為重新編譯就可以得到最佳的"笑"能,就像你對Server的認知,掌機(Embedded System)和Netbook/Notebook難道都一定是x86架構嘛?

另外提到Qt and wxWidgets 一樣都需要重新編譯,所以你會出現 xxxx軟體for mips /arm /x86幾種架構,甚至於你需要細分OS type,你提到你只是一般的使用者,我的觀點直接跟你說一般使用者根本不會care你是用什麼軟體開發,重點是好用和流暢而已,Android 採用Byte code在於我無需為了不同平台出不同的版本。

使用者又為何不需要Run再不同平台,舉Google Calendar為例,請問你都用不到這一套服務嘛?

我再次強調,bytecode不代表"笑"能不好,效能好不好是整個系統架構所造成的,更何況他有你的native code所做不到的事情。

還有請你不要把你對Windows上的認識拿來對應再Embedded System,就像你對Server的分析一樣。這是不同目標不同平台。
風之心 跟風一樣 來無影去無蹤
skulds wrote:

我再次強調,bytecode不代表"笑"能不好,效能好不好是整個系統架構所造成的,更何況他有你的native code所做不到的事情。



舉個例吧,什麼是byte作得到native code做不到的?
byte code跑到最後也是換成native code下去跑啊...XDDDD

不管是不是embedded system上,native code速度絕對比byte code快,看你要不要去tune而已。
這點要凹實在是說不大下去,至於byte code最大好處就是只要出一個apk不用分不同CPU版本。

至於這個命題,虛擬機會不會變成android的瓶頸,目前看起來並不會,大部分的情況速度還算夠快,
短時間內除了Game以外應該都沒什麼大問題。
cbmtvb wrote:
......遠不如編譯式的原生機器碼應該是千古不變的真理.(恕刪)



你講的是講笑話嗎?

所謂的笑點是這句話嗎?

等你使用過 Java. 再來評論會來的比較好.
而不是天馬行空 隨口亂蓋.

如果 Java 應用程式執行效能 "遠" 不如原生機器碼.那就不會有這麼多商業應用採用 Java .

如果 Java 應用程式執行效能 "遠" 不如原生機器碼 那 PHP 這類直譯式語言大概要去撞牆壁了.
someonepoor wrote:
舉個例吧,什麼是by...(恕刪)


你可以試試看把 Intel x386 編譯的 native code 試試看可不可以在 PowerPC 上執行.

這就是 native code 作不到 byte code 做的到的.
執行效率重點在架構好不好,不在程式語言....
不要用coding的角度去看一個系統程式
尤其是像android這種作業系統一樣,這麼龐大的程式,架構才是效能的重點
小程式當然用native code比較快,但是大程式就不一定了

android只是用java語言,骨子裡跟jvm根本不一樣...
而且以android來說,google做了很多功夫,把比較需要運算的部份用native code去實作
而且google也開放ndk讓開發者可以使用native code去開發,所以根本沒有什麼效能問題...

以java來講,到1.6其實效能已經跟c語言相去不遠了
效能好不好..主要是開發者的問題...
amosho.tw wrote:

你可以試試看把 Intel x386 編譯的 native code 試試看可不可以在 PowerPC 上執行.

這就是 native code 作不到 byte code 做的到的.



那QEMU是啥? 喔我忘了x86 code這樣搞就變成bye code...XD
只能拿出這點的話實在沒什麼好講的,啊不就中間隔了一層VM上面隨你搞?

實際上應該是說,目前大部分的應用跑在JavaVM的速度算夠快,所以有人願意拿一些執行速度換
開發速度,事實上PHP和Java都是這個模式,我自己也在寫python,但是關鍵部分我還是會寫成
C++的lib給python呼叫,這種模式的開發時程很短,速度上也還不錯,但是全叫我用python寫
可能就要再研究。

回到主題來,Android這樣搞我覺得挺聰明的,這表示做AP的人完全不需要去理會硬體的部分,
除了一個APK可以吃多個平台以外,最大的用意應該是要改變硬體主導軟體開發的情況,未來
在android上軟體才會是老大,這是完全以軟體開發的角度去設計的架構。



"做AP的人完全不需要去理會硬體的部分"

這句話是重點.... Device 種類這樣多,哪一個搞AP的要為這些不同平台都去重新編譯程式?
更不要說去套不同的Libreary 了..... 程式設計師也是要吃飯睡覺的好不好....
同意啊~Java一樣有JNi架構可以套用C++/C libraries ,但是同樣犧牲掉Bytecode能力, 本來園作者本來就在問Android上使用java開發 ,是否造成瓶頸?系統的角度上答案就是不會。
風之心 跟風一樣 來無影去無蹤

john_chang wrote:
"做AP的人完全不需要去理會硬體的部分"

這句話是重點.... Device 種類這樣多,哪一個搞AP的要為這些不同平台都去重新編譯程式?
更不要說去套不同的Libreary 了..... 程式設計師也是要吃飯睡覺的好不好....




是阿... 三層架構的美妙之處莫過於此。
而且對於開發者而言,既然是 Java,只要架構訂得 OK 稍微修改一下再移植到其他平台也不困難;
況且 Java 有很多良好的特性可以讓開發者專注在「軟體架構」上,很不錯呀。

yrulee wrote:
現在有試用過HERO的人就知道,其順暢程度直逼iPhone 3G,其原因就是其利用Java programming API與JNI的優勢,把常使用的功能切出來,盡量使用JNI直接用C/C++實作,再包裝成Java API,提供AP實作使用,例如Camera, GPS, Telephony, UI等API,因此Android程式一開始的進入點是interpreter執行沒錯,但到後期幾乎都是native code在運作。透過API隔開耗時與較不穩定的功能邏輯,AP實作者與系統廠各自分責,所以Android程式/OS的效能與一般也具有多工背景執行的OS相比,穩定且快速許多。
看了那麼多網友的熱心回應都說目前的效能已相當夠用,所以說高效能的 JNI 機制應該算是目前 Android Java 高笑能的救星囉?

可否再請教幾個小弟自己想像的問題:

(1) HERO操作的順暢程度直逼iPhone 3G,除了JNI寫得夠最佳化,是否更應歸功於Byte code與JNI的互動執行效能比傳統Java VM的高很多,也就是Android的Java code與JNI之間的聯繫機制、路徑與過程比傳統Java VM的精簡很多?

(2) 因為JNI寫得好不好會直接牽涉到使用者操作UI時順不順暢,而Android卻把很多應該由官方完成的JNI全推給硬體廠商自己解決,所以才聽說HTC用最多的人員來研發Android手機,全因Android官方太不負責?

(3) Android是全套採用Java VM概念所設計的手機、行動裝置及攜帶型電腦通用的作業系統,主要原因是否如下?
a. VM安全穩定不影響正事,VM內執行的軟體想故意癱瘓整個系統讓手機無法接打電話可說是不可能的任務
b. Java易跨平台,各平台現成的Java程式可以很容易移植過來,同一Android軟體可在不同的硬體平台直接執行
c. Java的速度不是問題,真正需要高效能的地方就交給JNI直接用C/C++實作或硬體晶片解決,何況CPU的摩爾定率也會來幫忙

(4) 目前Android上的各類遊戲平台模擬器實作出的聲光效果及可玩性如何? 有聽說大陸的山寨廠要出PSP外型的Android遊戲手機了嗎? (若想等HTC或SAMSUNG等大廠出智慧型遊戲手機大概還要等很久吧,而NOKIA的N81遊戲手機又做得不乾不脆且後來也沒什麼後續機種來接棒,雖然N97也可算是比N95、N86方便玩遊戲,但應該都不算是N81遊戲手機的接棒機種吧,何況現在N97、N86鏡頭會刮傷問題NOKIA根本擺爛不想回收處理,實在令人搖頭)
  • 8
內文搜尋
X
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 8)
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?