Android性能優化——界面流暢度優化

序言

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

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

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

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

使用的工具

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

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

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

步驟

獲取測試報告(也就是.trace文件)
當開始systrace測試時，在相應的頁面上滾動。然後systrace就會在設定的時長（默認5秒）結束。並在（默認在user目錄）相應的目錄下生成trace.html報告 使用chrome打開
在chrom中鍵入 chrome://tracing ，回車。得到如下頁面。 打開剛剛生成的文件

點擊Load，回彈出一個文件選擇器，選中剛剛生成的 trace.html 文件。就打開該報告 分析
滾動到幀相應的行。Frames，並展開UIThread

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

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


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

解決

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

總結

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

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