Android 效能優化典範
2015年伊始，Google釋出了關於Android效能優化典範的專題， 一共16個短視訊，每個3-5分鐘，幫助開發者建立更快更優秀的Android App。課程專題不僅僅介紹了Android系統中有關效能問題的底層工作原理，同時也介紹瞭如何通過工具來找出效能問題以及提升效能的建議。主要從三個 方面展開，Android的渲染機制，記憶體與GC，電量優化。下面是對這些問題和建議的總結梳理。
0)Render Performance
大多數使用者感知到的卡頓等效能問題的最主要根源都是因為渲染效能。從設計師的角度，他們希望App能夠有更多的動畫，圖片等時尚元素來實現流暢的用 戶體驗。但是Android系統很有可能無法及時完成那些複雜的介面渲染操作。Android系統每隔16ms發出VSYNC訊號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程式的大多數操作都必須在16ms內完成。
如果你的某個操作花費時間是24ms，系統在得到VSYNC訊號的時候就無法進行正常渲染，這樣就發生了丟幀現象。那麼使用者在32ms內看到的會是同一幀畫面。
使用者容易在UI執行動畫或者滑動ListView的時候感知到卡頓不流暢，是因為這裡的操作相對複雜，容易發生丟幀的現象，從而感覺卡頓。有很多原 因可以導致丟幀，也許是因為你的layout太過複雜，無法在16ms內完成渲染，有可能是因為你的UI上有層疊太多的繪製單元，還有可能是因為動畫執行 的次數過多。這些都會導致CPU或者GPU負載過重。
我們可以通過一些工具來定位問題，比如可以使用HierarchyViewer來查詢Activity中的佈局是否過於複雜，也可以使用手機設定裡 面的開發者選項，開啟Show GPU Overdraw等選項進行觀察。你還可以使用TraceView來觀察CPU的執行情況，更加快捷的找到效能瓶頸。
1)Understanding Overdraw
Overdraw(過度繪製)描述的是螢幕上的某個畫素在同一幀的時間內被繪製了多次。在多層次的UI結構裡面，如果不可見的UI也在做繪製的操作，這就會導致某些畫素區域被繪製了多次。這就浪費大量的CPU以及GPU資源。
當設計上追求更華麗的視覺效果的時候，我們就容易陷入採用越來越多的層疊元件來實現這種視覺效果的怪圈。這很容易導致大量的效能問題，為了獲得最佳的效能，我們必須儘量減少Overdraw的情況發生。
幸運的是，我們可以通過手機設定裡面的開發者選項，開啟Show GPU Overdraw的選項，可以觀察UI上的Overdraw情況。
藍色，淡綠，淡紅，深紅代表了4種不同程度的Overdraw情況，我們的目標就是儘量減少紅色Overdraw，看到更多的藍色區域。
Overdraw有時候是因為你的UI佈局存在大量重疊的部分，還有的時候是因為非必須的重疊背景。例如某個Activity有一個背景，然後裡面 的Layout又有自己的背景，同時子View又分別有自己的背景。僅僅是通過移除非必須的背景圖片，這就能夠減少大量的紅色Overdraw區域，增加 藍色區域的佔比。這一措施能夠顯著提升程式效能。
2)Understanding VSYNC
為了理解App是如何進行渲染的，我們必須瞭解手機硬體是如何工作，那麼就必須理解什麼是VSYNC。
在講解VSYNC之前，我們需要了解兩個相關的概念：
-
Refresh Rate：代表了螢幕在一秒內重新整理螢幕的次數，這取決於硬體的固定引數，例如60Hz。
-
Frame Rate：代表了GPU在一秒內繪製操作的幀數，例如30fps，60fps。
GPU會獲取圖形資料進行渲染，然後硬體負責把渲染後的內容呈現到螢幕上，他們兩者不停的進行協作。
不幸的是，重新整理頻率和幀率並不是總能夠保持相同的節奏。如果發生幀率與重新整理頻率不一致的情況，就會容易出現Tearing的現象(畫面上下兩部分顯示內容發生斷裂，來自不同的兩幀資料發生重疊)。
理解影象渲染裡面的雙重與三重快取機制，這個概念比較複雜，請移步檢視這裡：http://source.android.com/devices/graphics/index.html，還有這裡http://article.yeeyan.org/view/37503/304664。
通常來說，幀率超過重新整理頻率只是一種理想的狀況，在超過60fps的情況下，GPU所產生的幀資料會因為等待VSYNC的重新整理資訊而被Hold住，這樣能夠保持每次重新整理都有實際的新的資料可以顯示。但是我們遇到更多的情況是幀率小於重新整理頻率。
在這種情況下，某些幀顯示的畫面內容就會與上一幀的畫面相同。糟糕的事情是，幀率從超過60fps突然掉到60fps以下，這樣就會發生LAG，JANK，HITCHING等卡頓掉幀的不順滑的情況。這也是使用者感受不好的原因所在。
3)Tool:Profile GPU Rendering
效能問題如此的麻煩，幸好我們可以有工具來進行除錯。開啟手機裡面的開發者選項，選擇Profile GPU Rendering，選中On screen as bars的選項。
選擇了這樣以後，我們可以在手機畫面上看到豐富的GPU繪製圖形資訊，分別關於StatusBar，NavBar，啟用的程式Activity區域的GPU Rending資訊。
隨著介面的重新整理，介面上會滾動顯示垂直的柱狀圖來表示每幀畫面所需要渲染的時間，柱狀圖越高表示花費的渲染時間越長。
中間有一根綠色的橫線，代表16ms，我們需要確保每一幀花費的總時間都低於這條橫線，這樣才能夠避免出現卡頓的問題。
每一條柱狀線都包含三部分，藍色代表測量繪製Display List的時間，紅色代表OpenGL渲染Display List所需要的時間，黃色代表CPU等待GPU處理的時間。
4)Why 60fps?
我們通常都會提到60fps與16ms，可是知道為何會是以程式是否達到60fps來作為App效能的衡量標準嗎？這是因為人眼與大腦之間的協作無法感知超過60fps的畫面更新。
12fps大概類似手動快速翻動書籍的幀率，這明顯是可以感知到不夠順滑的。24fps使得人眼感知的是連續線性的運動，這其實是歸功於運動模糊的 效果。24fps是電影膠圈通常使用的幀率，因為這個幀率已經足夠支撐大部分電影畫面需要表達的內容，同時能夠最大的減少費用支出。但是低於30fps是 無法順暢表現絢麗的畫面內容的，此時就需要用到60fps來達到想要的效果，當然超過60fps是沒有必要的。
開發app的效能目標就是保持60fps，這意味著每一幀你只有16ms=1000/60的時間來處理所有的任務。
5)Android, UI and the GPU
瞭解Android是如何利用GPU進行畫面渲染有助於我們更好的理解效能問題。那麼一個最實際的問題是：activity的畫面是如何繪製到螢幕上的？那些複雜的XML佈局檔案又是如何能夠被識別並繪製出來的？
Resterization柵格化是繪製那些Button，Shape，Path，String，Bitmap等元件最基礎的操作。它把那些元件拆分到不同的畫素上進行顯示。這是一個很費時的操作，GPU的引入就是為了加快柵格化的操作。
CPU負責把UI元件計算成Polygons，Texture紋理，然後交給GPU進行柵格化渲染。
然而每次從CPU轉移到GPU是一件很麻煩的事情，所幸的是OpenGL ES可以把那些需要渲染的紋理Hold在GPU Memory裡面，在下次需要渲染的時候直接進行操作。所以如果你更新了GPU所hold住的紋理內容，那麼之前儲存的狀態就丟失了。
在Android裡面那些由主題所提供的資源，例如Bitmaps，Drawables都是一起打包到統一的Texture紋理當中，然後再傳遞到 GPU裡面，這意味著每次你需要使用這些資源的時候，都是直接從紋理裡面進行獲取渲染的。當然隨著UI元件的越來越豐富，有了更多演變的形態。例如顯示圖 片的時候，需要先經過CPU的計算載入到記憶體中，然後傳遞給GPU進行渲染。文字的顯示更加複雜，需要先經過CPU換算成紋理，然後再交給GPU進行渲 染，回到CPU繪製單個字元的時候，再重新引用經過GPU渲染的內容。動畫則是一個更加複雜的操作流程。
為了能夠使得App流暢，我們需要在每一幀16ms以內處理完所有的CPU與GPU計算，繪製，渲染等等操作。
6)Invalidations, Layouts, and Performance
順滑精妙的動畫是app設計裡面最重要的元素之一，這些動畫能夠顯著提升使用者體驗。下面會講解Android系統是如何處理UI元件的更新操作的。
通常來說，Android需要把XML佈局檔案轉換成GPU能夠識別並繪製的物件。這個操作是在DisplayList的幫助下完成的。DisplayList持有所有將要交給GPU繪製到螢幕上的資料資訊。
在某個View第一次需要被渲染時，DisplayList會因此而被建立，當這個View要顯示到螢幕上時，我們會執行GPU的繪製指令來進行渲 染。如果你在後續有執行類似移動這個View的位置等操作而需要再次渲染這個View時，我們就僅僅需要額外操作一次渲染指令就夠了。然而如果你修改了 View中的某些可見元件，那麼之前的DisplayList就無法繼續使用了，我們需要回頭重新建立一個DisplayList並且重新執行渲染指令並 更新到螢幕上。
需要注意的是：任何時候View中的繪製內容發生變化時，都會重新執行建立DisplayList，渲染DisplayList，更新到螢幕上等一 系列操作。這個流程的表現效能取決於你的View的複雜程度，View的狀態變化以及渲染管道的執行效能。舉個例子，假設某個Button的大小需要增大 到目前的兩倍，在增大Button大小之前，需要通過父View重新計算並擺放其他子View的位置。修改View的大小會觸發整個 HierarcyView的重新計算大小的操作。如果是修改View的位置則會觸發HierarchView重新計算其他View的位置。如果佈局很復 雜，這就會很容易導致嚴重的效能問題。我們需要儘量減少Overdraw。
我們可以通過前面介紹的Monitor GPU Rendering來檢視渲染的表現效能如何，另外也可以通過開發者選項裡面的Show GPU view updates來檢視檢視更新的操作，最後我們還可以通過HierarchyViewer這個工具來檢視佈局，使得佈局儘量扁平化，移除非必需的UI組 件，這些操作能夠減少Measure，Layout的計算時間。
7)Overdraw, Cliprect, QuickReject
引起效能問題的一個很重要的方面是因為過多複雜的繪製操作。我們可以通過工具來檢測並修復標準UI元件的Overdraw問題，但是針對高度自定義的UI元件則顯得有些力不從心。
有一個竅門是我們可以通過執行幾個APIs方法來顯著提升繪製操作的效能。前面有提到過，非可見的UI元件進行繪製更新會導致Overdraw。例 如Nav Drawer從前置可見的Activity滑出之後，如果還繼續繪製那些在Nav Drawer裡面不可見的UI元件，這就導致了Overdraw。為了解決這個問題，Android系統會通過避免繪製那些完全不可見的元件來儘量減少 Overdraw。那些Nav Drawer裡面不可見的View就不會被執行浪費資源。
但是不幸的是，對於那些過於複雜的自定義的View(重寫了onDraw方法)，Android系統無法檢測具體在onDraw裡面會執行什麼操作，系統無法監控並自動優化，也就無法避免Overdraw了。但是我們可以通過canvas.clipRect()來 幫助系統識別那些可見的區域。這個方法可以指定一塊矩形區域，只有在這個區域內才會被繪製，其他的區域會被忽視。這個API可以很好的幫助那些有多組重疊 元件的自定義View來控制顯示的區域。同時clipRect方法還可以幫助節約CPU與GPU資源，在clipRect區域之外的繪製指令都不會被執 行，那些部分內容在矩形區域內的元件，仍然會得到繪製。
除了clipRect方法之外，我們還可以使用canvas.quickreject()來判斷是否沒和某個矩形相交，從而跳過那些非矩形區域內的繪製操作。做了那些優化之後，我們可以通過上面介紹的Show GPU Overdraw來檢視效果。
8)Memory Churn and performance
雖然Android有自動管理記憶體的機制，但是對記憶體的不恰當使用仍然容易引起嚴重的效能問題。在同一幀裡面建立過多的物件是件需要特別引起注意的事情。
Android系統裡面有一個Generational Heap Memory的模型，系統會根據記憶體中不同 的記憶體資料型別分別執行不同的GC操作。例如，最近剛分配的物件會放在Young Generation區域，這個區域的物件通常都是會快速被建立並且很快被銷燬回收的，同時這個區域的GC操作速度也是比Old Generation區域的GC操作速度更快的。
除了速度差異之外，執行GC操作的時候，任何執行緒的任何操作都會需要暫停，等待GC操作完成之後，其他操作才能夠繼續執行。
通常來說，單個的GC並不會佔用太多時間，但是大量不停的GC操作則會顯著佔用幀間隔時間(16ms)。如果在幀間隔時間裡面做了過多的GC操作，那麼自然其他類似計算，渲染等操作的可用時間就變得少了。
導致GC頻繁執行有兩個原因：
-
Memory Churn記憶體抖動，記憶體抖動是因為大量的物件被建立又在短時間內馬上被釋放。
-
瞬間產生大量的物件會嚴重佔用Young Generation的記憶體區域，當達到閥值，剩餘空間不夠的時候，也會觸發GC。即使每次分配的物件佔用了很少的記憶體，但是他們疊加在一起會增加 Heap的壓力，從而觸發更多其他型別的GC。這個操作有可能會影響到幀率，並使得使用者感知到效能問題。
解決上面的問題有簡潔直觀方法，如果你在Memory Monitor裡面檢視到短時間發生了多次記憶體的漲跌，這意味著很有可能發生了記憶體抖動。
同時我們還可以通過Allocation Tracker來檢視在短時間內，同一個棧中不斷進出的相同物件。這是記憶體抖動的典型訊號之一。
當你大致定位問題之後，接下去的問題修復也就顯得相對直接簡單了。例如，你需要避免在for迴圈裡面分配物件佔用記憶體，需要嘗試把物件的建立移到循 環體之外，自定義View中的onDraw方法也需要引起注意，每次螢幕發生繪製以及動畫執行過程中，onDraw方法都會被呼叫到，避免在onDraw 方法裡面執行復雜的操作，避免建立物件。對於那些無法避免需要建立物件的情況，我們可以考慮物件池模型，通過物件池來解決頻繁建立與銷燬的問題，但是這裡 需要注意結束使用之後，需要手動釋放物件池中的物件。
9)Garbage Collection in Android
JVM的回收機制給開發人員帶來很大的好處，不用時刻處理物件的分配與回收，可以更加專注於更加高階的程式碼實現。相比起Java，C與C++等語言 具備更高的執行效率，他們需要開發人員自己關注物件的分配與回收，但是在一個龐大的系統當中，還是免不了經常發生部分物件忘記回收的情況，這就是記憶體洩 漏。
原始JVM中的GC機制在Android中得到了很大程度上的優化。Android裡面是一個三級Generation的記憶體模型，最近分配的物件 會存放在Young Generation區域，當這個物件在這個區域停留的時間達到一定程度，它會被移動到Old Generation，最後到Permanent Generation區域。
每一個級別的記憶體區域都有固定的大小，此後不斷有新的物件被分配到此區域，當這些物件總的大小快達到這一級別記憶體區域的閥值時，會觸發GC的操作，以便騰出空間來存放其他新的物件。
前面提到過每次GC發生的時候，所有的執行緒都是暫停狀態的。GC所佔用的時間和它是哪一個Generation也有關係，Young Generation的每次GC操作時間是最短的，Old Generation其次，Permanent Generation最長。執行時間的長短也和當前Generation中的物件數量有關，遍歷查詢20000個物件比起遍歷50個物件自然是要慢很多 的。
雖然Google的工程師在儘量縮短每次GC所花費的時間，但是特別注意GC引起的效能問題還是很有必要。如果不小心在最小的for迴圈單元裡面執 行了建立物件的操作，這將很容易引起GC並導致效能問題。通過Memory Monitor我們可以檢視到記憶體的佔用情況，每一次瞬間的記憶體降低都是因為此時發生了GC操作，如果在短時間內發生大量的記憶體上漲與降低的事件，這說明 很有可能這裡有效能問題。我們還可以通過Heap and Allocation Tracker工具來檢視此時記憶體中分配的到底有哪些物件。
10)Performance Cost of Memory Leaks
雖然Java有自動回收的機制，可是這不意味著Java中不存在記憶體洩漏的問題，而記憶體洩漏會很容易導致嚴重的效能問題。
記憶體洩漏指的是那些程式不再使用的物件無法被GC識別，這樣就導致這個物件一直留在記憶體當中，佔用了寶貴的記憶體空間。顯然，這還使得每級Generation的記憶體區域可用空間變小，GC就會更容易被觸發，從而引起效能問題。
尋找記憶體洩漏並修復這個漏洞是件很棘手的事情，你需要對執行的程式碼很熟悉，清楚的知道在特定環境下是如何執行的，然後仔細排查。例如，你想知道程式 中的某個activity退出的時候，它之前所佔用的記憶體是否有完整的釋放乾淨了？首先你需要在activity處於前臺的時候使用Heap Tool獲取一份當前狀態的記憶體快照，然後你需要建立一個幾乎不這麼佔用記憶體的空白activity用來給前一個Activity進行跳轉，其次在跳轉到 這個空白的activity的時候主動呼叫System.gc()方法來確保觸發一個GC操作。最後，如果前面這個activity的記憶體都有全部正確釋 放，那麼在空白activity被啟動之後的記憶體快照中應該不會有前面那個activity中的任何物件了。
如果你發現在空白activity的記憶體快照中有一些可疑的沒有被釋放的物件存在，那麼接下去就應該使用Alocation Track Tool來仔細查詢具體的可疑物件。我們可以從空白activity開始監聽，啟動到觀察activity，然後再回到空白activity結束監聽。這樣操作以後，我們可以仔細觀察那些物件，找出記憶體洩漏的真凶。
11)Memory Performance
通常來說，Android對GC做了大量的優化操作，雖然執行GC操作的時候會暫停其他任務，可是大多數情況下，GC操作還是相對很安靜並且高效的。但是如果我們對記憶體的使用不恰當，導致GC頻繁執行，這樣就會引起不小的效能問題。
為了尋找記憶體的效能問題，Android Studio提供了工具來幫助開發者。
-
Memory Monitor：檢視整個app所佔用的記憶體，以及發生GC的時刻，短時間內發生大量的GC操作是一個危險的訊號。
-
Allocation Tracker：使用此工具來追蹤記憶體的分配，前面有提到過。
-
Heap Tool：檢視當前記憶體快照，便於對比分析哪些物件有可能是洩漏了的，請參考前面的Case。
12)Tool – Memory Monitor
Android Studio中的Memory Monitor可以很好的幫組我們檢視程式的記憶體使用情況。
13)Battery Performance
電量其實是目前手持裝置最寶貴的資源之一，大多數裝置都需要不斷的充電來維持繼續使用。不幸的是，對於開發者來說，電量優化是他們最後才會考慮的的事情。但是可以確定的是，千萬不能讓你的應用成為消耗電量的大戶。
Purdue University研究了最受歡迎的一些應用的電量消耗，平均只有30%左右的電量是被程式最核心的方法例如繪製圖片，擺放佈局等等所使用掉的，剩下的 70%左右的電量是被上報資料，檢查位置資訊，定時檢索後臺廣告資訊所使用掉的。如何平衡這兩者的電量消耗，就顯得非常重要了。
有下面一些措施能夠顯著減少電量的消耗：
-
我們應該儘量減少喚醒螢幕的次數與持續的時間，使用WakeLock來處理喚醒的問題，能夠正確執行喚醒操作並根據設定及時關閉操作進入睡眠狀態。
-
某些非必須馬上執行的操作，例如上傳歌曲，圖片處理等，可以等到裝置處於充電狀態或者電量充足的時候才進行。
-
觸發網路請求的操作，每次都會保持無線訊號持續一段時間，我們可以把零散的網路請求打包進行一次操作，避免過多的無線訊號引起的電量消耗。關於網路請求引起無線訊號的電量消耗，還可以參考這裡http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/efficient-network-access.html
我們可以通過手機設定選項找到對應App的電量消耗統計資料。我們還可以通過Battery Historian Tool來檢視詳細的電量消耗。
如果發現我們的App有電量消耗過多的問題，我們可以使用JobScheduler API來對一些任務進行定時處理，例如我們可以把那些任務重的操作等到手機處於充電狀態，或者是連線到WiFi的時候來處理。
關於JobScheduler的更多知識可以參考http://hukai.me/android-training-course-in-chinese/background-jobs/scheduling/index.html
14)Understanding Battery Drain on Android
電量消耗的計算與統計是一件麻煩而且矛盾的事情，記錄電量消耗本身也是一個費電量的事情。唯一可行的方案是使用第三方監測電量的裝置，這樣才能夠獲取到真實的電量消耗。
當裝置處於待機狀態時消耗的電量是極少的，以N5為例，開啟飛航模式，可以待機接近1個月。可是點亮螢幕，硬體各個模組就需要開始工作，這會需要消耗很多電量。
使用WakeLock或者JobScheduler喚醒裝置處理定時的任務之後，一定要及時讓裝置回到初始狀態。每次喚醒無線訊號進行資料傳遞，都會消耗很多電量，它比WiFi等操作更加的耗電，詳情請關注http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/efficient-network-access.html
修復電量的消耗是另外一個很大的課題，這裡就不展開繼續了。
15)Battery Drain and WakeLocks
高效的保留更多的電量與不斷促使使用者使用你的App來消耗電量，這是矛盾的選擇題。不過我們可以使用一些更好的辦法來平衡兩者。
假設你的手機裡面裝了大量的社交類應用，即使手機處於待機狀態，也會經常被這些應用喚醒用來檢查同步新的資料資訊。Android會不斷關閉各種硬 件來延長手機的待機時間，首先螢幕會逐漸變暗直至關閉，然後CPU進入睡眠，這一切操作都是為了節約寶貴的電量資源。但是即使在這種睡眠狀態下，大多數應 用還是會嘗試進行工作，他們將不斷的喚醒手機。一個最簡單的喚醒手機的方法是使用PowerManager.WakeLock的API來保持CPU工作並 防止螢幕變暗關閉。這使得手機可以被喚醒，執行工作，然後回到睡眠狀態。知道如何獲取WakeLock是簡單的，可是及時釋放WakeLock也是非常重 要的，不恰當的使用WakeLock會導致嚴重錯誤。例如網路請求的資料返回時間不確定，導致本來只需要10s的事情一直等待了1個小時，這樣會使得電量 白白浪費了。這也是為何使用帶超時引數的wakelock.acquice()方法是很關鍵的。但是僅僅設定超時並不足夠解決問題，例如設定多長的超時比 較合適？什麼時候進行重試等等？
解決上面的問題，正確的方式可能是使用非精準定時器。通常情況下，我們會設定一個時間進行某個操作，但是動態修改這個時間也許會更好。例如，如果有 另外一個程式需要比你設定的時間晚5分鐘喚醒，最好能夠等到那個時候，兩個任務捆綁一起同時進行，這就是非精確定時器的核心工作原理。我們可以定製計劃的 任務，可是系統如果檢測到一個更好的時間，它可以推遲你的任務，以節省電量消耗。
這正是JobScheduler API所做的事情。它會根據當前的情況與任務，組合出理想的喚醒時間，例如等到正在充電或者連線到WiFi的時候，或者集中任務一起執行。我們可以通過這個API實現很多免費的排程演算法。
從Android 5.0開始釋出了Battery History Tool，它可以檢視程式被喚醒的頻率，又誰喚醒的，持續了多長的時間，這些資訊都可以獲取到。
請關注程式的電量消耗，使用者可以通過手機的設定選項觀察到那些耗電量大戶，並可能決定解除安裝他們。所以儘量減少程式的電量消耗是非常有必要的。
稿源：hukai.me