1 UI卡頓（Jank）

內容的快速載入很重要，渲染的流暢性也很重要。android團隊把滯緩，不流暢的動畫定義為jank，一般是由於丟幀引起的。安卓裝置的螢幕重新整理率一般是60幀每秒（1/60fps＝16.6ms每幀），所以你想要渲染的內容能在16ms內完成十分關鍵。每丟一幀，使用者就會感覺的動畫在跳動，會出現違和感。

2 專項優化方法

定位效能問題，一般需要多個工具配合使用，trace是必不可少的，既可以用DDMS裡面的，也可以用Android Device Monitor裡面帶的（支援分執行緒統計）；再結合DDMS裡面的其他工具及開發人員選項裡面的工具便可解決問題。

2.1 UI過度繪製優化

在設定->開發者選項->除錯GPU過度繪製->開啟顯示過度繪製區域後，可以看見如下圖（對settings當前介面過度繪製進行分析）：

可以發現，開啟後在我們想要除錯的應用介面中可以看到各種顏色的區域，具體含義如下：

我們需要依據此顏色分佈進行程式碼優化，多數情況下，大面積的過度繪製一般是由於父佈局及上層容器設定了冗餘的background導致的。我們可以通過DDMS中的Dump View Hierarchy for UI Automator檢視過度繪製區域的層級結構，快速一層層的進行優化，如圖：

2.2冗餘層級優化及效能瓶頸查詢

使用Hierarchy View工具來進行兩點優化
A．查詢整個view樹中的冗餘層級，減少層次，優化結構；
B．快速找出效能瓶頸位置（通過分析各view中measure，layout，draw時間比例）

2.2.1 啟動Hierarchy View
一種是在Android sdk中，在 tools 目錄下面找到hierarchyviewer.bat即可
另外一種從Android Device Monitor中開啟，啟動 Android Device Monitor 成功之後，在新的視窗中點選切換檢視圖示，選擇 Hierarchy View ，如下圖：

2.2.2 load Activity的view樹

黑體字就是表示當前介面的Activity，雙擊就load，等下下就能看見view tree了

Ps：該功能只能用在開發機或者虛擬機器上，普通的手機沒法用（安全性考慮）；第三方虛擬機器如bluestack可以使用，速度比較快；Android自帶的虛擬機器也可以，就是速度比較慢。

上圖所示為一個Activity的view tree，右上角視窗是整個樹結構的概覽圖，右下角視窗是整個介面的概覽圖，中間視窗可以拖拽、縮放，選中某個view後會顯示詳細資訊，右下角視窗標識出對應區域，Tree View視窗底部有搜尋功能。
一個介面的層次結構越複雜、層級越深，測量、繪製時所需要的時間就越多；通過檢視view tree，可以快速定位冗餘層級，減少不必要層次（線性排列的view group能否合併）、合併不必要分割（比如兩個兄弟view group能否合併）。

2.2.3 Obtain layout time for tree rooted as selected node

選中一個view後，點選上圖中的綠紅紫按鈕，就會以該view為根節點，測量它所有子view的measure、layout、draw時間。Ps：用第三方的虛擬機器，比如bluestack，該功能不好使，可以用Android自帶的虛擬機器，也不好用的時候，換不同的Android版本試試；
得到下圖所示結果：

點選每個view都可以看到具體細節，詳細意義如下圖:

每個view裡紅色，黃色和綠色的圓圈，它們表示該view在那一層樹形結構裡measure，layout和draw所花費的相對時間（從左到右）。綠色表示最快的前50%，黃色表示最慢的前50%，紅色表示那一層裡面最慢的view。顯然，紅色的部分是我們優先優化的物件。

2.3 靜態頁面靜態測試及優化

靜態頁面標準：在當前介面中沒有動畫，沒有主動執行的後臺操作，介面是靜態的，意味著這種情況下是不會有cpu消耗或者極少消耗。
當我們在使用app過程中，需要重點測試有各類動畫和後臺功能的頁面，當該頁面切換到靜態頁面時，該頁面可能有兩種狀態，onStop或者onDestroy了，這時執行靜態測試，測試是否有未停止的動畫、執行緒、未remove的handler runnable等；

測試方法1
在開發者選項中，開啟顯示CPU使用情況開關，如下圖
A．在右邊會顯示當前執行的程序列表，排列順序是按照CPU佔用降序排列，越往上表示消耗CPU越多
B. 綠色表示 userspace佔用cpu百分比,紅色表示kernel 佔用cpu百分比,藍色表示 io interrupt 佔用cpu百分比.
C. 第一行表示所有程序疊加的佔用CPU百分比，從左到右三個數表示userspace，kernel，io interrupt

通過觀察被測應用程序的cpu使用情況，理論情況下，靜態頁面中，應用應該不消耗或者消耗極少的cpu，如果應用程序一直排在前面在消耗cpu的情況，說明一直有方法在執行，這時可以使用測試方法2找出哪些方法在後面跑。

測試方法2
使用DDMS中的Traceview進行定位
Traceview工具是一個分析器，記錄了應用程式中每個函式的執行時間；
開啟DDMS，然後選擇一個程序，接著點選上面的“Start Method Profiling”按鈕（紅色小點變為黑色即開始執行，再次點選後停止）。

靜態情況下，幾乎沒有cpu消耗，如下圖

有幀動畫在執行，如下圖，AnimationDrawable是幀動畫相關的方法

通過Traceview，可以查找出哪些方法沒有正確的停止，避免不必要的cpu消耗，影響效能；

2.4啟動速度優化

1.從程式碼層面直接查詢Activity初始化時，初始化了哪些方法，依次估算這些方法的效能消耗，儘可能的不要在主執行緒中執行耗時操作，影響介面重新整理造成卡頓；
2.使用Traceview進行定位
啟動應用或者頁面時同時開始Trace採集，可以看到所有方法消耗cpu的百分比及排序，將方法依次對應回程式碼中，特別是觀察執行在main執行緒的方法有沒有優化空間；
3.不必須模組使用時載入
不必要的模組或者不必要的方法，延時載入或者使用時動態載入。比如drawerlayout的側邊欄，FrameLayout中的多個層，可以使用時再載入；Viewpager的多個頁面平衡什麼時候載入；

2.5 列表滑動卡頓優化

A. 使用GPU呈現模式圖考核UI效能
通過開發者選項中GPU呈現模式圖工具來進行流暢度考量的流程是（注意：如果是在開啟應用後才開啟此功能，記得先把應用結束後重新啟動）在設定->開發者選項->GPU呈現模式（不同裝置可能位置或者叫法不同）中開啟除錯後可以看見如下圖（對settings當前介面上下滑動列表後的圖表）：

開啟上圖視覺化工具後，我們可以在手機畫面上看到豐富的GPU繪製圖形資訊，分別展示了StatusBar、Activity區域等的GPU渲染時間資訊，隨著介面的重新整理，介面上會以實時柱狀圖來顯示每幀的渲染時間，柱狀圖越高表示渲染時間越長，每個柱狀圖偏上都有一根代表16ms基準的綠色橫線，每一條豎著的柱狀線都包含三部分（藍色代表測量繪製Display List的時間，prepare（紫色），紅色代表OpenGL渲染Display List所需要的時間，黃色代表CPU等待GPU處理的時間），只要我們每一幀的總時間低於基準線就不會發生UI卡頓問題（個別超出基準線其實也不算啥問題的）。

可以發現，這個工具是有侷限性的，他雖然能夠看出來有幀耗時超過基準線導致了丟幀卡頓，但卻分析不到造成丟幀的具體原因。所以說為了配合解決分析UI丟幀卡頓問題我們還需要藉助traceview和systrace來進行原因追蹤。

B. 使用Systrace進行分析優化
開啟DDMS->Capture system wide trace using Android systrace->設定時間與選項點選OK就開始了抓取，接著操作APP，完事生成一個trace.html檔案，用Chrome開啟即可如下圖：

介面很複雜，涉及的東西比較多，要想完全弄明白需要紮實的Android基礎；
主要看兩個地方，一個是如圖帶有警示標示的圓圈，這些都是有問題的地方，點選小圓圈在左下方會有詳細說明

另外一個地方看，帶有F標記的小圓圈

每個F標記表示一幀，原點不是綠色的基本都代表存在一定問題，點選後下面會提示你選擇的幀相關詳細資訊或者alert資訊，但是遺憾的是通過Systrace只能大體上發現是否存在效能問題，具體問題還需要通過Traceview或者程式碼中嵌入Trace工具類等去繼續詳細分析；

2.6 主執行緒block自動化監測工具——BlockCanary

BlockCanary對主執行緒操作進行了完全透明的監控，並能輸出有效的資訊，幫助開發分析、定位到問題所在，迅速優化應用。其特點有：
非侵入式，簡單的兩行就開啟監控，不需要到處打點，破壞程式碼優雅性。
精準，輸出的資訊可以幫助定位到問題所在（精確到行），不需要像Logcat一樣，慢慢去找。
目前包括了核心監控輸出檔案，以及UI顯示卡頓資訊功能。
具體原理參見git地址：https://github.com/markzhai/AndroidPerformanceMonitor
可以設定debug模式下彈通知欄，方便定位問題

2.7 記憶體洩漏查詢及優化

~~待續