最大的問題卡在通常處理這層的RD大部份只熟悉C

作者: iincho (世界的盡頭) 看板: Soft_Job
標題: Re: [請益] java的效能!?
時間: Sat May 21 10:25:02 2011

※ 引述《latw (latw)》之銘言：
: ※ 引述《stosto (樹多)》之銘言：
: : android不是跑得很順嗎?
: 那我就拿被蟲咬過的蘋果打你的臉 :D
: iOS是用obj-c 也是物件導向.順暢度?我還可以大膽的說"到目前為止",還沒有
: 一台android比蘋果順的,不信可以到各大賣場把玩一下,反正試玩不用錢.
: android還是特化的java不是標準的java.
: 再打一次臉...android從2.1->2.3把底層許多java code轉成c++ code,
: 越後面的版本,jni的數量越多...

  Android會慢並不是因為用VM的關係，雖然有一點影響，
  主因還是背景大家可以亂開一堆service同時跑。

  iOS會順也和Objective-C沒有太大關係，主要是因為大部份的情況
  並不允許使用者的程式多工。

: : 以android提供的audioAPI而言
: : 要調用好幾層從java->jni->media framework
: : (jni屬於AP framework層)....
: : media framework也是利用C++寫的，寫的也很物件導向..design patten也用的超好.....
: : 程式碼大歸大不過也算好追，也是跑得很好，而且是在那種有限的resource下
: : 除非是kernel driver那就沒話說了。但是，效能差點是一定的，不過C跟C++不會差太多
: : 不過老闆的話要聽就是了，不然就跟他說:I quit this job!
: 物件導向效能未必會比較差,看compiler.
: 不過大程式還是看演算法, java想贏asm大概也只能用演算法贏了,
: 如果都一樣的演算法,java也只能吃灰塵.

  問題是考慮到維護，用C/C++的成本比asm低多了。
  同樣的程式，同樣的演算法，但是開發時間可能不一樣....

: : 還有一堆老人只會寫C硬幹出來，寫的CODE一堆flag，想改一個功能要動幾千行都有可能
: : 可是這也不能怪他們，因為以前他們真的只寫C，沒想到現在需要寫APP
: : 我真的覺得要體諒他們啦....
: 這是程式設計功力與規劃的問題,linux kernel的code並不會這樣.
: 當你看過繼承再繼承,overwrite又overwrite..不用幾行你就想翻桌了:D
: java強項是跨平台,對於應付網路上充斥不同平台的電腦,這才是他的舞台.
: 拿來當用於規格幾乎一樣的桌機,只會被其他語言打臉而已,我還不知道
: 為什麼google竟然還拿來用在行動裝置這種環境更嚴苛,資源更少的地方.
: 不過最後一點倒是說對了
: 老闆說的都是對的...........(逃)

  喔，主要有兩點，因為用Java VM可以很輕鬆的隔開不同的硬體，手機可不是
  X86這種大家都是跑一樣的CPU，所以之前看WM的程式下載的時候都會標示
  這是哪一個機型可以用的binary。雖然說現在ARM看起來有機會統一世界但是
  這個當初決定還不算太離譜。

  另外就是你提到的，Android Dalvik VM這層做的事其實很少，大部份的事都在
  底下的C++層做完，加上用的硬體通常比較暴力，效能看起來是還OK。

  另外幫Android Middleware這層平反一下，基本上除了Google之前買的那堆
  奇怪程式(OpenCore之類的)，Android Middleware這層的C++用的相當漂亮，
  沒有太多不必要的overhead，而且template用的很漂亮，只可惜一搬系統廠
  的RD通常是看不懂，我自己看到最後才赫然發現這玩意根本就是M$ ATL那一套的
  梗再玩一次而已。中間這層我個人認為比之前embedded linux設計上好非常多。

  不過我認為最大的問題卡在通常處理這層的RD大部份只熟悉C，所以看到那一堆
  看不懂的code就...zzzz。

--
Beware of bugs in the above code;
I have only proved it correct, not tried it.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.166.113.63