Android卡頓千古謎案全面解析

　　有沒有感覺你用的Android手機(jī)很卡?貌似手機(jī)配置都已經(jīng)挺不錯的了，四核、八核、≥2GB RAM這樣的配置居然還會發(fā)生動畫掉幀、點(diǎn)擊某個按鈕或圖標(biāo)出現(xiàn)停頓一會兒之類的情況?高通、MTK、英偉達(dá)之類的芯片制造商不是整天宣稱什么制程、架構(gòu) 如何先進(jìn)，什么一秒鐘多少萬多少億次浮點(diǎn)運(yùn)算，怎么還整天被iPhone用戶嘲笑很卡很不爽?

　　關(guān)于Android系統(tǒng)存在卡頓和不流暢的問題，似乎是個千古謎案——即便到現(xiàn)在也還有很多Android用戶堅(jiān)持說他們新買的旗艦已如絲般柔滑，卻真正在流暢的細(xì)微處比iOS差了一截。不過從古到今，試圖解釋Android卡頓的觀點(diǎn)就有千百種，據(jù)說即便是采訪Android內(nèi)部開發(fā)工程師，他們也說這是個說不清道不明的問題。這次我們就從相關(guān)Android卡頓的幾個主流說法談起，嘗試從相對淺顯的角度來理解這一問題。

　　都是Dalvik VM虛擬機(jī)惹的禍?

　　按照普通人對虛擬機(jī)的理解，就是平常一直在用Windows操作系統(tǒng)，想裝個Mac OS玩玩又沒錢買蘋果電腦咋辦?——裝個虛擬機(jī)。從這個角度來理解，不管是出于玩機(jī)還是開發(fā)、或考慮兼容性的問題，用過虛擬機(jī)的同學(xué)就知道，這東西的效率 和原生安裝方式不在一個層面，不管是從驅(qū)動、資源利用等各角度來看都是如此。

　　Android的系統(tǒng)框架上，在最底層的Linux內(nèi)核之上就跑了個虛擬機(jī)，在Android 4.4之前，這個虛擬機(jī)叫Dalvik VM。絕大部分Android應(yīng)用就運(yùn)轉(zhuǎn)在Dalvik VM虛擬機(jī)之上——很多人，甚至是程序員認(rèn)為，Android系統(tǒng)之所以不流暢和卡頓，罪魁禍?zhǔn)拙褪谴颂摂M機(jī)，想想我們平常應(yīng)用層面虛擬機(jī)的運(yùn)行效率就知 道了，再牛逼的硬件也抵不住軟件這么坑啊。

　　早年的Android系統(tǒng)能有如此奇葩的框架和執(zhí)行思路并不是因?yàn)锳ndy Rubin真的很二。Android選擇這條路的原因是看中互聯(lián)網(wǎng)上浩瀚的Java資源——Java應(yīng)用可以運(yùn)行在Android這種Linux內(nèi)核的系 統(tǒng)上正是拜虛擬機(jī)所賜，對于一個當(dāng)時的新生系統(tǒng)而言，想要盡早構(gòu)建起應(yīng)用生態(tài)，這是個捷徑——也是Android現(xiàn)在擁有這么多應(yīng)用資源的關(guān)鍵所在(雖然 蘋果就沒這么做)。

　　不過另有一個幫派的程序員表示，這個層面的虛擬機(jī)和我們平常自己在電腦上裝的虛擬機(jī)根本不是一回事，它的執(zhí)行效率并沒有人們想象的不堪，實(shí)際使用中和直接調(diào)用底層基礎(chǔ)函數(shù)也沒差多少。

(NDK的也可是讓Android應(yīng)用不用跑在虛擬機(jī)上)

　　我們從谷歌后來的行動看到，情況好像沒有這么簡單。早在Android 2.3時期，谷歌就意識到Dalvik并非長久之計(jì)，就為Android引入了NDK——這是個真正的開發(fā)包，使用C/C++語言也可以為Android 開發(fā)應(yīng)用，以這種方式開發(fā)的應(yīng)用不會跑在虛擬機(jī)上。彼時的程序員認(rèn)為，這是Android從應(yīng)用層真正開始具備與iOS相抗衡實(shí)力的開始，但這種夢想很快 就被打破，一方面是讓開發(fā)者放棄Java全面轉(zhuǎn)向C/C++并不現(xiàn)實(shí)，而且后兩者開發(fā)難度甚高，涉及內(nèi)存操作甚至與設(shè)備驅(qū)動程序?qū)υ?，對于Android 這種機(jī)器種類繁多的系統(tǒng)而言，開發(fā)者采用NDK很不現(xiàn)實(shí)(類似《極品飛車》這種大型3D游戲運(yùn)行代碼理應(yīng)采用C++，所以這類游戲針對Android手機(jī) 的不同處理器甚至還有不同的版本)。

　　所以在Android 4.4時期，谷歌為之引入了一種新的ART虛擬機(jī)，用以替代Dalvik。ART的特點(diǎn)是相比Dalvik更為高效：Dalvik虛擬機(jī)在每次運(yùn)行應(yīng)用時 會將之編譯為二進(jìn)制機(jī)器代碼，ART的改進(jìn)之一就在于在應(yīng)用安裝的時候就將二進(jìn)制代碼編譯完成(所以每個應(yīng)用安裝所占空間會更大)，這叫預(yù)編譯模式，而不 是等到每次運(yùn)行應(yīng)用才編譯。

　　理論上聽來，ART似乎的確較Dalvik效率更高些，谷歌自己說ART對比Dalvik速度平均提升幅度達(dá)到80%，不過各位已經(jīng)在用 Android 4.4甚至5.0的小伙伴有這種體會嗎?或許今后隨著Android生態(tài)以及系統(tǒng)自身的完善，ART可以表現(xiàn)出更大的優(yōu)勢，起碼現(xiàn)在我們沒怎么看出來它對 系統(tǒng)流暢性體驗(yàn)改善有多大貢獻(xiàn)。

　　另外，在系統(tǒng)框架層面，除了探討虛擬機(jī)可能是拖垮Android流暢性的元兇之一這種說法，還有人也會談到Linux這類宏內(nèi)核在驅(qū)動方面的先天不足，這些或許都是阻礙Android有絲般流暢的要素，但是否還有其他原因呢?

　硬件加速弱爆了

　　顯示系統(tǒng)圖形界面的時候，如果畫圖的工作都交給CPU完成，這效率是可想而知的，猶如你讓一位精通數(shù)學(xué)的同學(xué)畫圖，多少他倒是能畫，只是能不能畫好 很成問題。如果GPU，也就是專門的畫圖工作者能夠協(xié)助這個過程，情況自是大不相同。雖說系統(tǒng)流暢性是個相當(dāng)大的話題，但硬件加速是否做得好就成為其中的 重要因素。

　　完善如上所述的這個過程，幾乎是貫穿Android 2.x早期，到最新的Android 5.1，甚至此后很長一段時間內(nèi)，谷歌需要努力的方向。針對系統(tǒng)圖片、網(wǎng)頁等2D圖形繪制，Android所用的是谷歌早在2005年就收購的 Skia(那時Android都還沒出生，Chrome也采用Skia作為2D圖形引擎)。

　　Skia原始版本的圖形光柵處理完全基于CPU和軟件運(yùn)算，也就是說早期Android的2D圖形繪制對GPU的利用率存在嚴(yán)重不足，相較iOS和Windows Phone這種在硬件加速領(lǐng)域有著很久積累的系統(tǒng)完全不是一個水平。

　　在Android的系統(tǒng)設(shè)置-調(diào)試選項(xiàng)中，有個“強(qiáng)制進(jìn)行GPU渲染”選項(xiàng)，開啟這個選項(xiàng)以后會發(fā)現(xiàn)某些應(yīng)用的運(yùn)行的確更流暢了，但有些則出現(xiàn)了更 糟糕的使用體驗(yàn)。在Android 2.3時代，國外科技博客DorothyBrowse特別強(qiáng)制開啟這種Skia GPU加速，嘗試進(jìn)行Webkit渲染(Chrome的渲染引擎)測試，結(jié)果發(fā)現(xiàn)相較CPU自己畫圖，所謂的GPU加速居然出現(xiàn)了反效果，可知當(dāng)時的 Skia GPU加速在Android平臺有多么不成熟。

　　在Android 3.0之前，這套系統(tǒng)都沒有真正行之有效的圖形加速方案(即便從初版開始，Android就在努力融合硬件加速)，Android 3.0才實(shí)現(xiàn)窗口相對完整的硬件加速繪制。實(shí)際上，即便是到Android 4.1，谷歌大肆宣傳的黃油計(jì)劃，過渡動畫幀率達(dá)到60fps，通過預(yù)判和緩沖來提升效率，其GPU加速支持也并不完整。谷歌自己的官方文檔中就提到，并 不是所有2D圖像操作的API都已經(jīng)支持硬件加速。

　　不過總的說來，Android的GPU加速是朝著逐步完善的方向發(fā)展的，最新版相較過去已經(jīng)有了很大程度的提升，從系統(tǒng)級應(yīng)用和各類操作這些年來流 暢度的明確提升就能感覺得到，即便這種提升在iOS和Windows Phone面前還是顯得有些無力?？墒莵淼降谌綉?yīng)用，這個問題又變得非常復(fù)雜。

　第三方應(yīng)用質(zhì)量很悲劇

　　在宣稱如“絲般順滑”、甚至“趕超iOS”的Android 4.1問世以后，不說和iOS比實(shí)際如何，其系統(tǒng)級應(yīng)用倒真的流暢了很多，可是第三方應(yīng)用死性未改，該怎么卡還是怎么卡。這就是個相當(dāng)復(fù)雜的問題了。

　　其一，在Android一步步向前的步伐中，API Level越高，GPU硬件加速也的確愈加完善，比如Android 5.1所用API Level 22。所謂的API Level，標(biāo)識的是Android平臺框架的API版本。這個API可以理解為Android所跑虛擬機(jī)針對應(yīng)用開發(fā)而支持的功能，隨著版本號的變化， 這些“功能”在發(fā)生著升級或轉(zhuǎn)變。對Android的系統(tǒng)應(yīng)用而言，采用最新的API是理所當(dāng)然的，流暢性也保持在最佳狀態(tài)。

　　但對第三方應(yīng)用來說，采用最新的API，就意味著對舊版本系統(tǒng)的拋棄。比如微信應(yīng)用更新，如果很任性地用上API Level 22，那么最新版的微信將只支持Android 5.1，人類可以忍受嗎?所以微信迄今為止還在采用API Level 9，微博則為API Level 14。這種API的迭代，也是蘋果為何高度追求系統(tǒng)一致性的重要原因。想想Android系統(tǒng)的碎片化問題，第三方應(yīng)用要變得更高效，好像是個根本無法完 成的任務(wù)。

　　這還只是第三方應(yīng)用開發(fā)的一環(huán)。其二，Android應(yīng)用開發(fā)者的“隨性”讓Android應(yīng)用的效率更加悲慘。比如說谷歌在應(yīng)用開發(fā)的指導(dǎo)原則中提到，如果應(yīng)用不夠流暢，應(yīng)該看看是否存在“過度渲染(OverDraw)”的問題，就是布局重疊、重復(fù)繪制。

　　要檢查這個問題，有興趣的同學(xué)可以一起來做這個實(shí)驗(yàn)。在Android系統(tǒng)設(shè)置的開發(fā)者選項(xiàng)中，選擇“顯示GPU過度繪制”，此時整個界面變得花花 綠綠一片。這些色塊所表達(dá)的是，無色透明狀態(tài)為最佳，藍(lán)色表示很好，綠色為不錯，淺紅色表示較差，深紅色為過度繪制問題嚴(yán)重。類似Instagram等應(yīng) 用的情況似乎挺好，而某博和Facebook過度渲染的問題就很嚴(yán)重。這只是Android應(yīng)用開發(fā)中的一個例子，如此這般罔顧開發(fā)原則的狀況那是數(shù)也數(shù) 不清的。在Android相對開放的應(yīng)用世界中，這種情況是不會有警察去抓的，顯然iOS全程把關(guān)App Store就不會這么悲劇。

　　其三，在天朝這樣一個奇特的國度，開放的系統(tǒng)無疑為許多應(yīng)用開發(fā)商提供了大好機(jī)會。很多應(yīng)用當(dāng)安裝到你手機(jī)中，其行為習(xí)慣可能是你完全不知道了，而且可能實(shí)情會更令你震驚，這就是下面一個話題了。

　　內(nèi)存居然還不夠用?裝越多APP手機(jī)越卡

　　相關(guān)Android裝越多應(yīng)用，手機(jī)越卡的解釋非常多樣，甚至包括對于固態(tài)存儲原理的解釋?；蛟S這些都是原因所在，不過更關(guān)鍵的原因是這樣 的：Android系統(tǒng)中有個叫做Receiver(接收器?)的東西，負(fù)責(zé)傳遞系統(tǒng)接收到的變化，就像是神經(jīng)系統(tǒng)。比如說按下Power鍵鎖屏，長按關(guān) 機(jī)，或者長按相機(jī)按鍵啟動相機(jī)應(yīng)用，或者插入耳機(jī)，都是在Receiver接收到以后通知相應(yīng)apk，后由程序給出響應(yīng)。

　　應(yīng)用本身就可以跟系統(tǒng)注冊任何形式的Receiver，其較大的用處之一是通知系統(tǒng)啟動某個程序。比如YouTube的Receiver在開機(jī)時、 系統(tǒng)語言切換后、系統(tǒng)賬戶改變后這三種情況下自動啟動YouTube應(yīng)用本身——這是個比較常見的Receiver。而國內(nèi)的諸多“異士”是如何寫 Receiver的呢?

　　某些著名視頻站APP在下面這些情況下都會啟動，包含開機(jī)時、網(wǎng)絡(luò)狀況改變時(2G、3G與WiFi間切換)、安裝其它App時、卸載其它APP 時、用戶喚醒機(jī)器時.。。對于用戶而言，無論你怎么殺進(jìn)程清內(nèi)存，只要這些操作被觸發(fā)，Receiver就會啟動相應(yīng)程序，話說連個WiFi、下個新應(yīng)用 都要啟動該應(yīng)用，哪有透明度可言，真是獨(dú)有社會主義特色。

　　此類國產(chǎn)APP相當(dāng)多見，常見Receiver動作還有：耳機(jī)拔出或插入時、文件下載完成后、WiFi掃描SSID完成后，都啟動程序，是不是感覺 灰常神奇?它們的宗旨就是永遠(yuǎn)不會被你殺死，什么一鍵殺進(jìn)程，分分鐘給你活過來，除非徹底卸載它們，或禁用相應(yīng)Reciever。在這種情況 下，Android系統(tǒng)對于內(nèi)存容量的要求自然是非一般的。

　　所謂的內(nèi)存回收機(jī)制此刻都已不值一提，何以iPhone 1GB內(nèi)存流暢運(yùn)行至今，而Android現(xiàn)如今已是3GB時代;這也是很多Android優(yōu)化文章告訴用戶，如果某應(yīng)用一周不用就卸載的核心所在，環(huán)境使然。你聽說過iOS優(yōu)化讓用戶卸應(yīng)用的嗎?

碎片化問題讓Android千瘡百孔

　　可以說，除了Android本身的頑疾之外，導(dǎo)致上述絕大部分問題的根源就是Android的碎片化，無論是Android自身開放的態(tài)度讓各種高 配、低配的手機(jī)都在使用，還是手機(jī)制造商對Android進(jìn)行的二次開發(fā)。要將硬件加速做好、規(guī)范第三方應(yīng)用質(zhì)量，在Android開放的理念下是幾近不 可能完成的任務(wù)，且谷歌自己都難以收拾局面。

　　Android的開放和碎片化帶來的問題還遠(yuǎn)不止上面這些，一個典型的例子是iOS和Windows Phone都具備了特別出色的信息推送機(jī)制，比如說QQ、微信接收消息，在iOS和Windows Phone中，應(yīng)用本身不需要常駐后臺，通過每臺手機(jī)和推送服務(wù)器保持唯一連接，就能收到推送通知，無論對性能和功耗的節(jié)省都具備了極大的意義。

　　Android系統(tǒng)當(dāng)然也具備了消息推送的可行性，但由于碎片化問題，以及國內(nèi)因?yàn)槟撤N原因不得不去掉谷歌服務(wù)的現(xiàn)狀，令A(yù)ndroid不同應(yīng)用采 用五花八門的推送機(jī)制。許多Android應(yīng)用獲取消息的方式是輪詢(而非推送)，即應(yīng)用主動地與服務(wù)器連接并查詢是否有新消息，可想而知它對系統(tǒng)和網(wǎng)絡(luò) 資源的消耗。

　　關(guān)乎Android系統(tǒng)本身，則除了文首提到的虛擬機(jī)機(jī)制，還有許多相當(dāng)微妙的問題形成它與iOS之間的流暢性差異，比如Android對多任務(wù)的 支持更類似于桌面系統(tǒng)，本身就只有靠堆砌硬件才能滿足這種多任務(wù)的需求，當(dāng)然iOS的多任務(wù)也已經(jīng)不像很多人理解的那樣，是多年前的“假后臺”了，它針對 第三方應(yīng)用開放的多任務(wù)API正越來越多。

　　總之，Android的卡頓和不流暢是個極其復(fù)雜、龐大的問題，上面所提的這些也只是挖掘了其中的一部分。就Android系統(tǒng)的發(fā)展軌跡來看，從 初代問世至今，其發(fā)展史都可以看做是谷歌在系統(tǒng)流暢性問題上所做的一次次努力，流暢性改善甚至是Android前行的一條線索，所以谷歌也才毫不吝嗇地一 次次地宣傳，我們的系統(tǒng)更流暢了，不管相較競爭對手有多大差距和多少不可控性，現(xiàn)在的Android也已經(jīng)比過去流暢了很多，雖然未來還有很長的路要走。

linux操作系統(tǒng)文章專題：linux操作系統(tǒng)詳解（linux不再難懂）