序言
首先流暢度不僅僅是受到代碼的影響。也會跟機器的硬件配置有關係。所以第一點需要明確的是，流暢度最低保證在哪個硬件配置之上。這樣有了一個基點之後，才能比較好明確優化目標。不然你拿一個兩三年前的機子來做優化。那就真的是吃力不討好的事情。
流暢度跟兩方面有關：一、機器的配置，二、編寫的代碼。
首先明確一點：流暢意味着 每一幀的繪製在16ms內完成。
那如果在你選的最低配置的機子上達到了流暢，那就沒必要優化了。如果在你選的機子上，出現了較大的流暢性問題，那就需要着重優化。
使用的工具
我們需要使用Systrace工具來進行優化。具體的使用方法，這裏就不詳細介紹了。我在這裏附上Android官方文檔，你也可以尋找相關博客學習。Android Systrace使用文檔
這裏開始，就是假設你已經看過相關博客和官方文檔了，懂得如何使用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那裏了）
- 頻繁的創建大的臨時對象或者過多的臨時對象，觸發頻繁的垃圾回收。垃圾回收時，其他線程是會停止工作的，包括主線。等垃圾回收完畢，主線纔會繼續工作。這就導致了卡頓。