說到Android系統手機，大部分人的印象是用了一段時間就變得有點卡頓，有些程式在執行期間莫名其妙的出現崩潰，開啟系統資料夾一看，發現多了很多檔案，然後用手機管家 APP 不斷地進行清理優化 ，才感覺執行速度稍微提高了點，就算手機在各種效能跑分軟體面前分數遙遙領先，還是感覺無論有多大的記憶體空間都遠遠不夠用。相信每個使用Android系統的使用者都有過以上類似經歷，確實，Android系統在流暢性方面不如iOS系統，為何呢，明明在看手機硬體配置上時，Android裝置都不會輸於iOS裝置，甚至都強於它，關鍵是在於軟體上。造成這種現象的原因是多方面的，簡單羅列幾點如下：

• 其實近年來，隨著Android版本不斷迭代，Google提供的Android系統已經越來越流暢，目前最新發布的版本是Android Oreo（8.0）。但是在國內大部分使用者用的Android手機系是各大廠商定製過的版本，往往不是最新的原生系統核心，可能絕大多數還停留在Android 5.0系統上，甚至 Android 6.0以上所佔比例還偏小，更新存在延遲性。

• 由於Android系統原始碼是開放的，每個人只要遵從相應的協議，就可以對原始碼進行修改，那麼國內各個廠商就把基於Android原始碼改造成自己對外發布的系統，比如我們熟悉的小米手機MIUI系統、華為手機EMUI系統、Oppo手機ColorOS系統等。由於每個廠商都修改過Android原生系統原始碼，這裡面就會引發一個問題，那就是著名的Android碎片化問題，本質就是不同Android系統的應用相容性不同，達不到一致性。

• 由於存在著各種Android碎片化和相容性問題，導致Android開發者在開發應用時需要對不同系統進行適配，同時每個Android開發者的開發水平參差不齊，寫出來的應用效能也都存在不同型別的問題，導致使用者在使用過程中使用者體驗感受不同，那麼有些問題使用者就會轉化為Android系統問題，進而影響對Android手機的評價。

效能優化

====

今天想說的重點是Android APP效能優化，也就是在開發應用程式時應該注意的點有哪些，如何更好地提高使用者體驗。一個好的應用，除了要有吸引人的功能和互動之外，在效能上也應該有高的要求，即時應用非常具有特色，在產品前期可能吸引了部分使用者，但是使用者體驗不好的話，也會給產品帶來不好的口碑。那麼一個好的應用應該如何定義呢？主要有以下三方面：

• 業務/功能

• 符合邏輯的互動

• 優秀的效能

眾所周知，Android系統作為以移動裝置為主的作業系統，硬體配置是有一定的限制的，雖然配置現在越來越高階，但仍然無法與PC相比，在CPU和記憶體上使用不合理或者耗費資源多時，就會碰到記憶體不足導致的穩定性問題、CPU 消耗太多導致的卡頓問題等。

面對問題時，大家想到的都是聯絡使用者，然後檢視日誌，但殊不知有關效能類問題的反饋，原因也非常難找，日誌大多用處不大，為何呢？因為效能問題大部分是非必現的問題，問題定位很難復現，而又沒有關鍵的日誌，當然就無法找到原因了。這些問題非常影響使用者體驗和功能使用，所以瞭解一些效能優化的一些解決方案就顯得很重要了，並在實際的專案中優化我們的應用，進而提高使用者體驗。

四個方面

====

可以把使用者體驗的效能問題主要總結為4個類別：

• 流暢

• 穩定

• 省電、省流量

• 安裝包小

效能問題的主要原因是什麼，原因有相同的，也有不同的，但歸根到底，不外乎記憶體使用、程式碼效率、合適的策略邏輯、程式碼質量、安裝包體積這一類問題，整理歸類如下：

從圖中可以看到，打造一個高質量的應用應該以4個方向為目標：快、穩、省、小。

• 快：使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望。

• 穩：減低 crash 率和 ANR 率，不要在使用者使用過程中崩潰和無響應。

• 省：節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙。

• 小：安裝包小可以降低使用者的安裝成本。

要想達到這4個目標，具體實現是在右邊框裡的問題：卡頓、記憶體使用不合理、程式碼質量差、程式碼邏輯亂、安裝包過大，這些問題也是在開發過程中碰到最多的問題，在實現業務需求同時，也需要考慮到這點，多花時間去思考，如何避免功能完成後再來做優化，不然的話等功能實現後帶來的維護成本會增加。

卡頓優化

====

Android 應用啟動慢，使用時經常卡頓，是非常影響使用者體驗的，應該儘量避免出現。卡頓的場景有很多，按場景可以分為4類：UI 繪製、應用啟動、頁面跳轉、事件響應，如圖：

這4種卡頓場景的根本原因可以分為兩大類：

• 介面繪製。主要原因是繪製的層級深、頁面複雜、重新整理不合理，由於這些原因導致卡頓的場景更多出現在UI和啟動後的初始介面以及跳轉到頁面的繪製上。

• 資料處理。導致這種卡頓場景的原因是資料處理量太大，一般分為三種情況，一是資料在處理UI執行緒，二是資料處理佔用CPU高，導致主執行緒拿不到時間片，三是記憶體增加導致GC頻繁，從而引起卡頓。

引起卡頓的原因很多，但不管怎麼樣的原因和場景，最終都是通過裝置螢幕上顯示來達到使用者，歸根到底就是顯示有問題，所以，要解決卡頓，就要先了解Android系統的顯示原理。

Android系統顯示原理

Android顯示過程可以簡單概括為：Android應用程式把經過測量、佈局、繪製後的Surface快取資料，通過SurfaceFlinger把資料渲染到顯示螢幕上， 通過Android的重新整理機制來重新整理資料。也就是說應用層負責繪製，系統層負責渲染，通過程序間通訊把應用層需要繪製的資料傳遞到系統層服務，系統層服務通過重新整理機制把資料更新到螢幕上。

我們都知道在Android的每個View繪製中有三個核心步驟：Measure、Layout、Draw。具體實現是從 ViewRootImp類的performTraversals() 方法開始執行，Measure和Layout都是通過遞迴來獲取View的大小和位置，並且以深度作為優先順序，可以看出層級越深、元素越多、耗時也就越長。

真正把需要顯示的資料渲染到螢幕上，是通過系統級程序中的SurfaceFlinger服務來實現的，那麼這個SurfaceFlinger服務主要做了哪些工作呢？如下：

• 響應客戶端事件，建立Layer與客戶端的Surface建立連線。

• 接收客戶端資料及屬性，修改Layer屬性，如尺寸、顏色、透明度等。

• 將建立的Layer內容重新整理到螢幕上。

• 維持Layer的序列，並對Layer最終輸出做出裁剪計算。

既然是兩個不同的程序，那麼肯定是需要一個跨程序的通訊機制來實現資料傳遞，在Android顯示系統中，使用了Android的匿名共享記憶體：SharedClient，每一個應用和SurfaceFlinger之間都會建立一個SharedClient ，然後在每個SharedClient中，最多可以建立31個 SharedBufferStack，每個Surface都對應一個SharedBufferStack，也就是一個Window。

一個SharedClient對應一個Android應用程式，而一個Android應用程式可能包含多個視窗，即Surface。也就是說SharedClient包含的是SharedBufferStack的集合，其中在顯示重新整理機制中用到了雙緩衝和三重緩衝技術。最後總結起來顯示整體流程分為三個模組：應用層繪製到快取區，SurfaceFlinger把快取區資料渲染到螢幕，由於是不同的程序，所以使用Android的匿名共享記憶體SharedClient快取需要顯示的資料來達到目的。

除此之外，我們還需要一個名詞：FPS。FPS表示每秒傳遞的幀數。在理想情況下，60FPS就感覺不到卡，這意味著每個繪製時長應該在16ms以內。但是 Android系統很有可能無法及時完成那些複雜的頁面渲染操作。Android系統每隔16ms發出VSYNC訊號，觸發對UI進行渲染，如果每次渲染都成功，這樣就能夠達到流暢的畫面所需的60FPS。如果某個操作花費的時間是24ms ，系統在得到VSYNC訊號時就無法正常進行正常渲染，這樣就發生了丟幀現象。那麼使用者在32ms內看到的會是同一幀畫面，這種現象在執行動畫或滑動列表比較常見，還有可能是你的Layout太過複雜，層疊太多的繪製單元，無法在16ms完成渲染，最終引起重新整理不及時。

卡頓根本原因

根據Android系統顯示原理可以看到，影響繪製的根本原因有以下兩個方面：

• 繪製任務太重，繪製一幀內容耗時太長。

• 主執行緒太忙，根據系統傳遞過來的VSYNC訊號來時還沒準備好資料導致丟幀。

繪製耗時太長，有一些工具可以幫助我們定位問題。主執行緒太忙則需要注意了，主執行緒關鍵職責是處理使用者互動，在螢幕上繪製畫素，並進行載入顯示相關的資料，所以特別需要避免任何主執行緒的事情，這樣應用程式才能保持對使用者操作的即時響應。總結起來，主執行緒主要做以下幾個方面工作：

• UI生命週期控制

• 系統事件處理

• 訊息處理

• 介面佈局

• 介面繪製

• 介面重新整理

除此之外，應該儘量避免將其他處理放在主執行緒中，特別複雜的資料計算和網路請求等。

效能分析工具

效能問題並不容易復現，也不好定位，但是真的碰到問題還是需要去解決的，那麼分析問題和確認問題是否解決，就需要藉助相應的的除錯工具，比如檢視Layout層次的Hierarchy View、Android系統上帶的GPU Profile工具和靜態程式碼檢查工具Lint等，這些工具對效能優化起到非常重要的作用，所以要熟悉，知道在什麼場景用什麼工具來分析。

1，Profile GPU Rendering

在手機開發者模式下，有一個卡頓檢測工具叫做：Profile GPU Rendering，如圖：

它的功能特點如下：

• 一個圖形監測工具，能實時反應當前繪製的耗時

• 橫軸表示時間，縱軸表示每一幀的耗時

• 隨著時間推移，從左到右的重新整理呈現

• 提供一個標準的耗時，如果高於標準耗時，就表示當前這一幀丟失

2，TraceView

TraceView是Android SDK自帶的工具，用來分析函式呼叫過程，可以對Android的應用程式以及Framework層的程式碼進行效能分析。它是一個圖形化的工具，最終會產生一個圖表，用於對效能分析進行說明，可以分析到每一個方法的執行時間，其中可以統計出該方法呼叫次數和遞迴次數，實際時長等引數維度，使用非常直觀，分析效能非常方便。

3，Systrace UI 效能分析

Systrace是Android 4.1及以上版本提供的效能資料取樣和分析工具，它是通過系統的角度來返回一些資訊。它可以幫助開發者收集Android關鍵子系統，如Surfaceflinger、WindowManagerService等Framework部分關鍵模組、服務、View系統等執行資訊，從而幫助開發者更直觀地分析系統瓶頸，改進效能。Systrace的功能包括跟蹤系統的I/O操作、核心工作佇列、CPU負載等，在UI顯示效能分析上提供很好的資料，特別是在動畫播放不流暢、渲染卡等問題上。

優化建議

1，佈局優化

佈局是否合理主要影響的是頁面測量時間的多少，我們知道一個頁面的顯示測量和繪製過程都是通過遞迴來完成的，多叉樹遍歷的時間與樹的高度h有關，其時間複雜度O(h)，如果層級太深，每增加一層則會增加更多的頁面顯示時間，所以佈局的合理性就顯得很重要。

那佈局優化有哪些方法呢，主要通過減少層級、減少測量和繪製時間、提高複用性三個方面入手。總結如下：

• 減少層級。合理使用RelativeLayout和LinerLayout，合理使用Merge。

• 提高顯示速度。使用ViewStub，它是一個看不見的、不佔佈局位置、佔用資源非常小的檢視物件。

• 佈局複用。可以通過標籤來提高複用。

• 儘可能少用wrap_content。wrap_content 會增加布局measure時計算成本，在已知寬高為固定值時，不用wrap_content 。

• 刪除控制元件中無用的屬性。

2，避免過度繪製

過度繪製是指在螢幕上的某個畫素在同一幀的時間內被繪製了多次。在多層次重疊的UI結構中，如果不可見的UI也在做繪製的操作，就會導致某些畫素區域被繪製了多次，從而浪費了多餘的CPU以及GPU源。

如何避免過度繪製呢，如下：

• 佈局上的優化。移除XML中非必須的背景，移除Window預設的背景、按需顯示佔位背景圖片

• 自定義View優化。使用 canvas.clipRect()來幫助系統識別那些可見的區域，只有在這個區域內才會被繪製。

3，啟動優化

通過對啟動速度的監控，發現影響啟動速度的問題所在，優化啟動邏輯，提高應用的啟動速度。啟動主要完成三件事：UI佈局、繪製和資料準備。因此啟動速度優化就是需要優化這三個過程：

• UI佈局。應用一般都有閃屏頁，優化閃屏頁的UI佈局，可以通過Profile GPU Rendering檢測丟幀情況。

• 啟動載入邏輯優化。可以採用分佈載入、非同步載入、延期載入策略來提高應用啟動速度。

• 資料準備。資料初始化分析，載入資料可以考慮用執行緒初始化等策略。

4，合理的重新整理機制

在應用開發過程中，因為資料的變化，需要重新整理頁面來展示新的資料，但頻繁重新整理會增加資源開銷，並且可能導致卡頓發生，因此，需要一個合理的重新整理機制來提高整體的UI流暢度。合理的重新整理需要注意以下幾點：

• 儘量減少重新整理次數。

• 儘量避免後臺有高的CPU執行緒執行。

• 縮小重新整理區域。

5，其他

在實現動畫效果時，需要根據不同場景選擇合適的動畫框架來實現。有些情況下，可以用硬體加速方式來提供流暢度。

記憶體優化

====

在Android系統中有個垃圾記憶體回收機制，在虛擬機器層自動分配和釋放記憶體，因此不需要在程式碼中分配和釋放某一塊記憶體，從應用層面上不容易出現記憶體洩漏和記憶體溢位等問題，但是需要記憶體管理。Android系統在記憶體管理上有一個Generational Heap Memory模型，記憶體回收的大部分壓力不需要應用層關心，Generational Heap Memory有自己一套管理機制，當記憶體達到一個閾值時，系統會根據不同的規則自動釋放系統認為可以釋放的記憶體，也正是因為Android程式把記憶體控制的權力交給了Generational Heap Memory，一旦出現記憶體洩漏和溢位方面的問題，排查錯誤將會成為一項異常艱難的工作。除此之外，部分Android應用開發人員在開發過程中並沒有特別關注記憶體的合理使用，也沒有在記憶體方面做太多的優化，當應用程式同時執行越來越多的任務，加上越來越複雜的業務需求時，完全依賴Android的記憶體管理機制就會導致一系列效能問題逐漸呈現，對應用的穩定性和效能帶來不可忽視的影響，因此，解決記憶體問題和合理優化記憶體是非常有必要的。

Android記憶體管理機制

Android應用都是在 Android的虛擬機器上執行，應用 程式的記憶體分配與垃圾回收都是由虛擬機器完成的。在Android系統，虛擬機器有兩種執行模式：Dalvik和ART。

1，Java物件生命週期

一般Java物件在虛擬機器上有7個執行階段：

建立階段->應用階段->不可見階段->不可達階段->收集階段->終結階段->物件空間重新分配階段

2，記憶體分配

在Android系統中，記憶體分配實際上是對堆的分配和釋放。當一個Android程式啟動，應用程序都是從一個叫做Zygote的程序衍生出來，系統啟動 Zygote 程序後，為了啟動一個新的應用程式程序，系統會衍生Zygote程序生成一個新的程序，然後在新的程序中載入並執行應用程式的程式碼。其中，大多數的RAM pages被用來分配給Framework程式碼，同時促使RAM資源能夠在應用所有程序之間共享。

但是為了整個系統的記憶體控制需要，Android系統會為每一個應用程式都設定一個硬性的Dalvik Heap Size最大限制閾值，整個閾值在不同裝置上會因為RAM大小不同而有所差異。如果應用佔用記憶體空間已經接近整個閾值時，再嘗試分配記憶體的話，就很容易引起記憶體溢位的錯誤。

3，記憶體回收機制

我們需要知道的是，在Java中記憶體被分為三個區域：Young Generation(年輕代)、Old Generation(年老代)、Permanent Generation(持久代)。最近分配的物件會存放在Young Generation區域。物件在某個時機觸發GC回收垃圾，而沒有回收的就根據不同規則，有可能被移動到Old Generation，最後累積一定時間在移動到Permanent Generation 區域。系統會根據記憶體中不同的記憶體資料型別分別執行不同的GC操作。GC通過確定物件是否被活動物件引用來確定是否收集物件，進而動態回收無任何引用的物件佔據的記憶體空間。但需要注意的是頻繁的GC會增加應用的卡頓情況，影響應用的流暢性，因此需要儘量減少系統GC行為，以便提高應用的流暢度，減小卡頓發生的概率。

記憶體分析工具

做記憶體優化前，需要了解當前應用的記憶體使用現狀，通過現狀去分析哪些資料型別有問題，各種型別的分佈情況如何，以及在發現問題後如何發現是哪些具體物件導致的，這就需要相關工具來幫助我們。

1，Memory Monitor

Memory Monitor是一款使用非常簡單的圖形化工具，可以很好地監控系統或應用的記憶體使用情況，主要有以下功能：

• 顯示可用和已用記憶體，並且以時間為維度實時反應記憶體分配和回收情況。

• 快速判斷應用程式的執行緩慢是否由於過度的記憶體回收導致。

• 快速判斷應用是否由於記憶體不足導致程式崩潰。

2，Heap Viewer

Heap Viewer的主要功能是檢視不同資料型別在記憶體中的使用情況，可以看到當前程序中的Heap Size的情況，分別有哪些型別的資料，以及各種型別資料佔比情況。通過分析這些資料來找到大的記憶體物件，再進一步分析這些大物件，進而通過優化減少記憶體開銷，也可以通過資料的變化發現記憶體洩漏。

3，Allocation Tracker

Memory Monitor和Heap Viewer都可以很直觀且實時地監控記憶體使用情況，還能發現記憶體問題，但發現記憶體問題後不能再進一步找到原因，或者發現一塊異常記憶體，但不能區別是否正常，同時在發現問題後，也不能定位到具體的類和方法。這時就需要使用另一個記憶體分析工具Allocation Tracker，進行更詳細的分析，Allocation Tracker可以分配跟蹤記錄應用程式的記憶體分配，並列出了它們的呼叫堆疊，可以檢視所有物件記憶體分配的週期。

4，Memory Analyzer Tool(MAT)

MAT是一個快速，功能豐富的Java Heap分析工具，通過分析Java程序的記憶體快照HPROF分析，從眾多的物件中分析，快速計算出在記憶體中物件佔用的大小，檢視哪些物件不能被垃圾收集器回收，並可以通過檢視直觀地檢視可能造成這種結果的物件。

常見記憶體洩漏場景