別的不提了,最讓我噁心的是它因為各種各樣的原因自己不知不覺就會啟動好幾個我根本用不著的程式和後台服務,有時候甚至讓人覺得匪夷所思,然後這些進程還就在那獃著了。
android管理記憶體的方法叫做low memory killer,這東西簡單的不能再簡單,就是留比如30M緩衝,你啟動一個新程式可以往這30M裡放,同時它再清出30M;也就是說這個時候去結束它覺得沒用的程式。
這裡頭有一個核心思想,就是我花錢買的記憶體不是用來閒置。保證越多的程式在記憶體裡,那麼切換進這些程式的機率就越高,如果中獎了速度就會更快。
這個道理聽起來再正確不過了,可是一個處理不好,就是android這樣的老牛拉破車的結局:你搞不清楚什麼時候CPU或者記憶體就被別人佔用了,於是間歇性的會明顯感覺到不流暢。可惜Google就是處理不好這個,很容易就在這個緩衝的邊界折騰來折騰去。
仔細觀察一下android下Java程式的架構就知道,有時候你僅僅需要一個簡單的動作,這時候卻牽連出一大堆占記憶體的東西。不知道這到底是賴物件導向的組織方法呢,還是賴Google沒設計好。
另一方面,這種設計就很難約束開發人員;隨便拿一個Process Monitor看一下,仔細一琢磨就知道,很多時候很多軟體的不同模組之間沒必要的牽連太多,功能分布不合理,尤其是這些程式如果是作為Framework的擴充和圍繞常用功能集展開的,比如廠商自訂的東西,就完蛋了。
這就是為什麼Sense介面和原生Android在輕量級使用時空閑記憶體會有那麼大差異的原因(HTC的主設計師應該開掉),以及為什麼Android會不可思議的時快時慢的原因(和其它廠商相比)之一。
讓我們再觀察觀察Settings.apk。這玩意有什麼內容?居然要佔走幾M十幾M的記憶體。為神馬為神馬這是為神馬!能夠快速載入和啟動的程式,或者程式中的某一部分,根本就沒有必要留在記憶體裡。我們可以說,Google這種常駐記憶體的策略,最終全都優惠在那些駐不駐記憶體使用者根本察覺不到的東西上了。
那另一個影響速度的原因是什麼呢?是那些該死的服務:雖然看起來Google想規劃一下這個事情,但是至少目前,這些服務還是會經常性的和使用者當前操作去搶CPU資源。
讓我們看看Linux核心編程是處理這個事情的:接著中斷的常式必須儘可能快速的結束,把大部頭工作交給一個隊列去做。Linux核心程式員全都懂這個事情,但你Google沒權利要求我們像做驅動那樣做應用,更何況整個運行時設計的素質讓開發人員處理這個比在核心裡還難!
(Android的主設計師應該開掉,你知道你設計的是什麼東西嗎?)
不知道競爭到底會走向百花齊放還是就這樣了。如果真的硝煙再起,我要說的是,只要有一家肯真正努力,Android一定完蛋,不管它那時候是3.5還是9.0。因為大規模更改運行時去達成合理化,等於直接把App數降回史前時代。
不過這些也真難說了,從最上到最下,從最大到最小,世道變了,人心也變了。哥們我是不得不關注這些方面尋找機會,有朝一日財務自由了,寧可回去當原始人也絕不忍受這種對付事情的產品。
P.S. 一旦有了真正的競爭而不是幾個寡頭壟斷,戰火燒到PC平台也不是沒有可能。到了那會兒第一個銷售收入下降的就是可憐的Intel,因為大家發現居然有免費的午餐,下載個盜版XYZ就能讓體驗好一倍... (我這篇文章說的是體驗,不涉及真正的執行效率,雖然這方面Google跟競爭者比也是個新手中的菜鳥)