效能問題分析主要包括三個方面

1.介面渲染
2.記憶體與GC

3.電量優化

介面渲染

大多數使用者感知到的卡頓等效能問題的最主要根源都是因為渲染效能我們希望App能夠有更多的動畫，圖片等時尚元素來實現流暢的用 戶體驗。但是Android系統很有可能無法及時完成那些複雜的介面渲染操作。Android系統每隔16ms發出VSYNC訊號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程式的大多數操作都必須在16ms內完成。 。                                                         
如果你的某個操作花費時間是24ms，系統在得到VSYNC訊號的時候就無法進行正常渲染，這樣就發生了丟幀現象。那麼使用者在32ms內看到的會是同一幀畫面，為了能夠使得App流暢，我們需要在每一幀16ms以內處理完所有的CPU與GPU計算，繪製，渲染等等操作
                                                             
使用者容易在UI執行動畫或者滑動ListView的時候感知到卡頓不流暢，是因為這裡的操作相對複雜，容易發生丟幀的現象，從而感覺卡頓。有很多原 因可以導致丟幀，也許是因為你的layout太過複雜，無法在16ms內完成渲染，有可能是因為你的UI上有層疊太多的繪製單元，還有可能是因為動畫執行 的次數過多。這些都會導致CPU或者GPU負載過重

問題分析

造成UI效能問題分析，大致有以下三種情況 1.UI上有層疊太多的繪製單元，多次繪製
2.layout太過複雜，無法在16ms內完成渲染
3.操作複雜，造成丟幀

Overdraw分析重複繪製 

OverDraw是分析介面重複繪製的工具，可以幫助我們分析介面哪個地方進行了不必要的多次繪製，幫助我們分析介面那個地方可以優化
使用方法。
開啟手機的開發者選項，在硬體加速渲染一欄中選擇“除錯GPU過度繪製”，選擇“顯示過度繪製區域”

OverDraw工具對介面分析分為5中顏色 1. 原色：沒有過度繪製
2. 藍色：過度繪製一次
3. 綠色：過度繪製兩次
4. 粉色：過度繪製三次
5. 紅色：過度繪製大於等於四次
根據顏色可以判斷UI重複繪製的次數，然後進行相應的優化。在應用程式中過度繪製是不可避免的，但是我們應該儘量去增大原色區域和藍色區域

過度繪製分析

過度繪製其實是一個性能和設計的交叉點。我們在設計上追求很華麗的視覺效果，但一般來說這種視覺效果會採用非常多的層疊元件來實現，這時候就會帶來過度繪製的問題。比如：我們有一疊UI元件，這些元件從上到下分佈，上面的元件是可以被使用者看見的，而在下面的元件是不可見的，但是我們依然要花很多時間去繪製那些不可見的元件，因為在某些時候，它也可能會顯示出來。但這確實是在浪費CPU和GPU的資源啊

過度繪製產生的原因

1.太多重疊的背景
重疊著的背景有時候是有必要的，有時候是沒必要的。這要視你的專案具體情況而定.
2.太多疊加的View
本來這個UI佈局就很複雜或者你是為了追求一個炫麗的視覺效果，這都有可能使得很多view疊加在一起。這個情況非常普遍，下面的建議中會談談怎麼減少這種情況帶來的影響。
3.複雜的Layout層級
複雜的層級關係，這個在佈局中也很常見，下面也會說這種情況怎麼做可以儘可能的減少過度繪製。

解決過度繪製的一些方法

太多重疊的背景
這個問題其實最容易解決，建議就是檢查你在佈局和程式碼中設定的背景，有些背景是被隱藏在底下的，它永遠不可能顯示出來，這種沒必要的背景一定要移除，因為它很可能會嚴重影響到app的效能。如果採用的是selector的背景，將normal狀態的color設定為”@android:color/transparent”,也同樣可以解決問題。
太多重疊的view
第一個建議是：使用ViewStub來載入一些不常用的佈局，它是一個輕量級且預設不可見的檢視，可以動態的載入一個佈局，只有你用到這個重疊著的view的時候才載入，推遲載入的時間。第二個建議是：如果使用了類似viewpager+Fragment這樣的組合或者有多個Fragment在一個介面上，需要控制Fragment的顯示和隱藏，儘量使用動態地Inflation view，它的效能要比SetVisiblity好。
複雜的Layout層級
這裡的建議比較多一些，首先推薦用Android提供的佈局工具Hierarchy Viewer來檢查和優化佈局。第一個建議是：如果巢狀的線性佈局加深了佈局層次，可以使用相對佈局來取代。第二個建議是：用標籤來合併佈局，這可以減少佈局層次。第三個建議是：用標籤來重用佈局，抽取通用的佈局可以讓佈局的邏輯更清晰明瞭。記住，這些建議的最終目的都是使得你的Layout在Hierarchy Viewer裡變得寬而淺，而不是窄而深。

HierarchyViewer分析Layout結構

用途：
Hierarchy Viewer有兩個用途，
一.是用於分析當前頁面檢視層級
二.再者也能分析佈局的時間統計（Measrue、Layout、Draw）所需要的具體時間
使用方法：
1.連線模擬器或者手機裝置
2.執行要測試的應用的介面
3.開啟Hierarchyviewer工具
4.雙擊要檢視的應用

觀察層次結構圖
這個圖有點大，可以拖動。View Hierarchy視窗顯示了Activity的所有View物件，選中某個View還可以檢視View的具體資訊
檢視單個View的詳細資訊
選擇view的某一個節點，點選obtain layout times,檢視該節點的具體資訊View Hierarcy 同時能幫助你識別渲染效能比較低的部分。View節點中帶有紅色或黃色的點代表速度較慢的View物件。如單步執行應用程式那樣，你可以這樣來判斷某個View 速度一直很慢，還是隻在某個特定環境下速度才慢。請注意，低效能並不表示一定有問題，特別像是ViewGroup物件，View的子節點越多，結構越複雜，效能越差。View Hierarchy 視窗還可以幫助你找到效能問題。只要看每個View節點的效能指標（顏色點）就可以，你可以看到測量（佈局或繪製）最慢的View物件是哪個，這樣你就能快速確定，要優先察看哪個問題

TraceView分析操作耗時

介紹
Android平臺特有的資料分析採集工具，主要用於分析Android應用程式中的Hotspot，traceView本身只是一個數據分析工具，而資料採集則要靠Android SDK的Debug類或者DDMS工具。
兩種使用方法
最簡單的方式就是直接開啟DDMS，選擇一個程序，然後按上面的“Start Method Profiling”按鈕，等紅色小點變成黑色以後就表示TraceView已經開始工作了。然後我就可以滑動一下列表。操作最好不要超過5s，因為最好是進行小範圍的效能測試。然後再按一下剛才按的按鈕，等一會就會出現上面這幅圖，然後就可以開始分析了。
第2種方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，當運行了這段程式碼的時候，就會有一個trace檔案在/sdcard目錄中生成，也可以呼叫startMethodTracing(String traceName) 設定trace檔案的檔名，最後你可以使用adb pull /sdcard/test.trace /tmp 命令將trace檔案複製到你的電腦中，然後用DDMS工具開啟就會出現第一幅圖了

Traceview UI分為上下兩個部分，(上)時間線面板和(下)分析面板
上面是你測試的程序中每個執行緒的執行情況，每個執行緒佔一行；下面是每個方法執行的各個指標的值

name	該執行緒執行過程中呼叫的函式名
Incl cpu time	某函式呼叫CPU的時間，包括內部呼叫其他函式的時間
Excl cpu time	某函式呼叫CPU的時間，不包括內部呼叫其他函式的時間
Incl real time	某函式呼叫CPU的真實時間(ms)，包括內部呼叫其他函式的真實時間
Excl real time	某函式呼叫CPU的真實時間(ms)，不包括內部呼叫其他函式的真實時間
call+Recur call/total	某函式的呼叫次數及遞迴呼叫佔總呼叫次數的百分比
Cpu time/call	cpu時間與呼叫次數的比值，相當於函式平均執行時間
Real time/call	同Cpu time/call類似，統計單位為真實時間

1. Incl Cpu Time
這個指標表示 這個方法以及這個方法的子方法（比如top方法中的a、b、c、d方法）一共執行的時間


public void top() {
    a();
    b();
    c();
    d();
}

佈局優化的一些策略

1. <include>標籤
2. <viewstub>標籤
3.<merge>標籤
4.去除不必要的巢狀和View節點
5.減少不必要的infalte
6.View區域性更新