Android效能優化——介面流暢度優化

序言

首先流暢度不僅僅是受到程式碼的影響。也會跟機器的硬體配置有關係。所以第一點需要明確的是，流暢度最低保證在哪個硬體配置之上。這樣有了一個基點之後，才能比較好明確優化目標。不然你拿一個兩三年前的機子來做優化。那就真的是吃力不討好的事情。

流暢度跟兩方面有關：一、機器的配置，二、編寫的程式碼。

首先明確一點：流暢意味著 每一幀的繪製在16ms內完成。

那如果在你選的最低配置的機子上達到了流暢，那就沒必要優化了。如果在你選的機子上，出現了較大的流暢性問題，那就需要著重優化。

使用的工具

我們需要使用Systrace工具來進行優化。具體的使用方法，這裡就不詳細介紹了。我在這裡附上Android官方文件，你也可以尋找相關部落格學習。

這裡開始，就是假設你已經看過相關部落格和官方文件了，懂得如何使用systrace來測量介面流暢性。

需要的東西：1. 作為基準的手機。 2. chrome 3.Android Monitor工具集。

步驟

1. 獲取測試報告(也就是.trace檔案) 
   當開始systrace測試時，在相應的頁面上滾動。然後systrace就會在設定的時長（預設5秒）結束。並在（預設在user目錄）相應的目錄下生成trace.html報告
2. 使用chrome開啟 
   在chrom中鍵入 chrome://tracing ，回車。得到如下頁面。 開啟剛剛生成的檔案 
   
   
   點選Load，回彈出一個檔案選擇器，選中剛剛生成的 trace.html 檔案。就開啟該報告
3. 分析 
   滾動到幀相應的行。Frames，並展開UIThread 
   

往右邊看，我們可以看到F標記。一個F表示一幀。綠色的F，表示該幀在16ms內繪製完成。而紅色則表示，嚴重超出了16ms。也就是通常所說的掉幀。 

從上面這幅圖可以看到。紅框框出來的地方就是卡頓的地方。我們通過快捷鍵w(放大）s(縮小) a(向左移動）d(向右移動）來操控 
就讓我們放大紅色區域看看 

 
可以看到藍綠部分都是GridView inflate操作，看起來GridView回收機制沒有生效。然後回到程式碼中分析後，發現原來是因為這個頁面的結構是ListView嵌套了GridView。這就是不斷inflate的原因所在。

解決

發現問題之後，解決起來也就有方向了。這個就得看具體原因了。

總結

介面流暢度一般來說就以下兩種造成

1. getView執行時間過長。（絕大多說滾動的頁面都是ListView或者RecycleView做的，所以出問題就在getView那裡了）
2. 頻繁的建立大的臨時物件或者過多的臨時物件，觸發頻繁的垃圾回收。垃圾回收時，其他執行緒是會停止工作的，包括主線。等垃圾回收完畢，主線才會繼續工作。這就導致了卡頓。