安卓應用性能調試和優化經驗分享

安卓綠色聯盟應用性能標準主要基於主觀體驗、資源消耗和應用質量三個方面進行制定。

一、主觀體驗

主觀體驗主要是對應用啓動時間和界面幀率制定標準，要求應用在視覺上足夠流暢。其中應用啓動時間又分爲冷啓動時間和熱啓動時間。

安卓綠色聯盟性能標準要求，應用冷啓動時間需小於1000ms，熱啓動時間需小於500ms；普通應用幀率應大於55fps，遊戲視頻幀率應大於25fps。

二、資源消耗

資源消耗主要是要求應用不能佔用太高的內存和CPU。

安卓綠色聯盟性能標準要求應用前臺內存佔用應小於500M，後臺內存佔用應小於400M；在CPU佔用方面要求應用在後臺滅屏5分鐘後，CPU佔用不超過2%。

三、應用質量

應用質量主要是對應用過分繪製和內存泄露的狀況做出要求，規定應用不能存在過分繪製和內存泄露。

安卓綠色聯盟性能標準要求應用界面任意像素點不存在4x的繪製的狀況， 3x繪製的區域不能超過界面面積的1/3，在Strict Mode中不容許有紅框閃爍。

性能調試方法

在瞭解性能調試方法以前，咱們能夠先經過下圖瞭解安卓應用性能與系統之間的關係。一個應用從應用繪製到最終顯示在LCD上經歷了一個漫長的路徑，在任何一個階段出現延時都會致使界面上的卡頓。

一、Strict Mode

Strict Mode意思爲嚴格模式，是Android提供的一種運行時檢測機制，通常用來檢測在主線程發生的耗時動做，好比IO讀寫、數據庫操做、複雜算法等。在手機設置開發者選項把Strict Mode打開，就能夠在界面上把它打開了。

嚴格模式主要有2個策略，一個是線程策略，即ThreadPolicy，主要檢測主線程中的一些耗時操做；另外一個是虛擬機策略，即VmPolicy，主要檢測一些對象的泄漏。

兩大策略檢測的內容和開啓方法能夠依據下圖中的說明進行使用。

嚴格模式有三種懲罰模式：應用崩潰、彈窗警告和打印日誌。在性能測試中，咱們能夠經過APPLogcat抓取Strict Mode的日誌，同時利用代碼啓用Strict Mode，配合咱們所須要的策略和懲罰，就能夠及時定位應用的違規細節，並及時進行性能優化。

當咱們碰到違規的行爲時，該如何進行治理呢？建議將文件操做放到工做線程去完成，若是在主線程上說起操做，建議使用Apply和Commit去完成。若是存在對象未關閉的狀況，能夠經過對應的StackTrace進行關閉。

二、OverDraw DeBugger

Overdraw是指屏幕上的某個像素在同一幀的時間內被繪製了屢次，這個工具使用色塊來表明不一樣數量的過分繪製，咱們可使用這個工具來定位由過分繪製引發的用戶界面卡頓問題。

在開發者選項中選擇開啓 Debug GPU Overdraw選項，便可在安卓設備上將過分繪製問題可視化。

左圖爲正常模式下顯示的視圖，右圖爲開啓GPU Overdraw後顯示的視圖

三、Profile GPU Rendering

ProfileGPU Rendering 工具以滾動直方圖的形式直觀地顯示渲染界面窗口幀所花費的相對時間（以每幀 16 毫秒的速度做爲對比基準）。這個工具一樣也是在安卓設備的開發者選項中開啓。每一個管線的高度表示時間，管線中各個彩色區段表明不一樣含義。

下表介紹了使用運行Android 6.0及更高版本的設備時分析器中不一樣豎條區段的含義。

四、Android Profiler

Android Profiler是一個Android Studio集成的應用性能分析器，能夠實時查看CPU、Memory和Network的動態狀況。如下重點介紹CPU Profiler：

CPU Profiler 可幫助您實時檢查應用的 CPU 使用率和線程 Activity，並記錄函數跟蹤，方便你們優化和調試應用代碼。

當打開 CPU Profiler 時，它將顯示應用的 CPU 使用率和線程 Activity。

CPU Profiler能夠選擇不一樣的標籤，並對應用線程進行跟蹤。如：

（1）Flame Chart標籤會提供一個倒置的調用圖表，彙總相同的調用堆棧，收集調用順序徹底一致的函數，並在火焰圖中用一個較長的橫條表示它們。

（2）Top Down標籤可以提供每一個函數調用上所花費的CPU時間。Self表示函數調用在執行本身的代碼上所花的時間；Children表示函數調用子方法所花費的時間；Total表示Self和Children時間的總和。

五、Systrace

Systrace是咱們分析性能最經常使用的工具之一，它能夠分析整機系統性能及動態場景的性能問題。

Systrace 容許您在系統級別收集和檢查設備上運行的全部進程的計時信息。它未來自Android內核的數據（例如CPU調度程序，磁盤活動和應用程序線程）組合起來，以生成HTML報告。

上圖左部是Systrace的界面，咱們能夠經過右邊的代碼抓取Systrace，觀察進程的執行時間。在輸入抓取命令時，時間參數通常選擇5到10秒，由於時間太短可能會抓不到想要的數據，時間過長則可能抓取失敗。

通常咱們經過Chrome瀏覽器查看生成的trace文件，也能夠經過DDMS圖形界面去抓取Systrace。

拿到一個Systrace時主要考察哪些因素？首先看一下CPU的頻率，找到對應的進程或者線程，查看相關信息；同時還要觀察GPU的頻率、Surface Flinger還有繪圖的Buffer狀態等。

當應用發生卡頓時，咱們能夠經過Systrace進行分析。在生成的trace文件中，找到主線程UI，每一幀都會標記一個帶有F的圓形。當原型爲綠色時，表明頁面流暢，而黃色和紅色則存在超時，咱們能夠點擊去查看具體存在什麼問題。

性能案例分析

案例1：界面滑動卡頓

從圖中能夠看到，這是一個手動滑動事件，當deliverInput事件發生後，第一幀就發生了卡頓。從systrace看UI thread執行draw的時間至關耗時致使丟幀卡頓，並且大部分時間都在作decodeBitmap，共耗時99.045ms。這時，咱們打開applog發現，有StrictMode相關的錯誤提示，從中能夠定位到耗時函數。

從上圖咱們看出有一個網絡訪問違規，大概能夠推測應用在從網絡上下載了一個數據流，數據流裏可能包含了一些圖形，經過decodeBitmap把它解析出來展現在UI界面中。正產狀況下，咱們應該把網絡訪問放在工做線程裏面去處理，將數據下載完了以後再放到主線程中去展現，避免這種問題的發生。

案例2：Strict Mode錯誤提示

從上圖Strict Mode的日誌能夠看出：StrictMode policy violation耗時2秒左右。經過最下行藍色的log，能夠知道應用是在某一個目錄裏面尋找一個文件，判斷文件是否存在。

面對這種問題，咱們應該把IO操做放到工做線程。正常狀況下IO的發生很是快，可是在系統繁忙時，IO放在主線程會產生較大的問題，由於它要等別的程序讀寫完成以後，纔會下發，產生超時。

案例3：GPU調用不當致使的卡頓問題

這是一個GPU的例子，上圖主要問題是GPU使用了太長時間處理應用傳過來的buffer,例子中Surfaceflinger 使用GPU 作了圖像疊加，說明圖層比較多。使用GPU作疊加主要會產生功耗和喚醒耗時的問題。你們在作界面設計的時候，儘可能不要使用GPU進行疊加。在上面的例子中，GPU疊加以後，致使了大概15ms左右的延時，由於GPU操做完成之後還須要交給Surfaceflinger把圖像顯示到屏幕上。

案例4：CPU調用不當致使的界面滑動卡頓問題

能夠經過上圖的紅色條塊瞭解messageloop RunTask信息，紅色條塊上的藍色bar，表示線程在CPU上的狀態。藍色表示這個線程處於等待CPU調度的狀態，可見等待超過8ms的時間，是正常調度週期好幾倍。致使這種狀況發生的緣由有兩個：CPU負載過大或CPU調度出現了問題。在上圖中咱們能夠看出，CPU0和CPU1使用率100%，可是CPU2和CPU3是offline的狀態，說明系統出現問題，致使CPU2和CPU3未能喚醒，幫助完成系統任務。

性能優化建議

一、避免內存泄露

在應用開發過程當中，首先要避免內存泄露的問題，內存泄露是一種比較嚴重的性能問題，在安卓綠色聯盟應用性能標準中也要求應用不容許發生內存泄露。

下圖是常見的內存泄露防範方法和內存泄露檢測工具。

二、避免不良設計或程序算法致使CPU佔有率持續偏高

• 主要業務處理分散到不一樣線程，便於後續利用多核處理器的並行處理能力，避免一核累死，7核圍觀；
• 使用top命令觀察應用線程的CPU佔有率，找出高負載的進程進行分析，並針對優化。

三、避免OnXXX 回調函數中進行耗時操做，避免主線程卡頓

Android系統中正常狀況下全部onXXX類函數均運行在主線程中。

在上圖中，咱們能夠看到兩幀中間有一個由於接收廣播處理致使的158ms的卡頓。在這些函數中，咱們應該避免網絡通訊操做、文件讀寫操做、數據庫數據改動的操做、圖形處理、文本分析等操做，將這些工做盡量的移到工做線程中去，從而避免主線程卡頓。

四、合理使用系統資源

合理使用系統資源主要指的是軟資源。下圖是對廣播資源調用的一些建議。

關注安卓綠色聯盟公號，回覆關鍵詞「23」，獲取PPT