1 減少過渡繪制
1.1 怎么查看是否存在過度繪制？
我們可以通過手機設置里面的開發者選項，打開Show GPU Overdraw的選項，可以觀察UI上的Overdraw情況。
藍色，淡綠，淡紅，深紅代表了4種不同程度的Overdraw情況，我們的目標就是盡量減少紅色Overdraw，看到更多的藍色區域
1.2 怎么解決過度繪制？
1.2.1 移除Window默認的Background
在onCreate方法中加入,getWindow().setBackgroundDrawable(null);
1.2.2 移除XML布局文件中非必需的Background
1.2.3 自定義 View 時重寫 hasOverlappingRendering 方法返回false。
該方法用來標記當前view是否存在過度繪制，存在返回ture，不存在返回false，默認返回為true。
當繼承了hasOverlappingRendering()方法返回false后，android會自動進行合理的優化，避免使用offscreen buffer。
2 布局優化
2.1 減少布局的嵌套層級
可以hierarchyviewer去看布局的嵌套層級
原則:
1，用RelativeLayout減少嵌套的層級。
2，同等層級情況下可以實現的選用LinearLayout而不是RelativeLayout。
2.2 當某些UI滿足某種條件才顯示復雜UI就用ViewStub
在開發過程中，經常會遇到這樣一種情況，有些布局很復雜但是卻很少使用。例如條目詳情、進度條標識或者未讀消息等，這些情況如果在一開始初始化，雖然設置可見性 View.GONE ,但是在Inflate的時候View仍然會被Inflate，仍然會創建對象，由于這些布局又想到復雜，所以會很消耗系統資源。
ViewStub就是為了解決上面問題的，ViewStub是一個輕量級的View，它一個看不見的，不占布局位置，占用資源非常小的控件。
2.3 有些大像素有規律的圖片用.9去代替
2.4 去掉無用的UI
2.5 合并布局，用TextView代替圖片加文字
3 分析代碼耗時情況
可以通過traceview去分析代碼的耗時情況。
traceView雖然很牛逼。但是網上大部分文章都是淺淺說一下。
經過這段時間不段試錯，整理一個可行的套路。
套路開始：
3.1 生成.trace 文件
首先肯定生成用TraceView生成.trace文件。
生成.trace文件是方式有兩種。
3.1.1 在DDMS工具中生成
最常用的使用方式
1，選擇到DDMS界面，選擇要檢測耗時的進程，比如我的就是com.android.dialer
2，點擊采集如下圖
會出現這樣的對話框（這個就是多長時間采集一次數據），點擊ok即可。
這時候開啟采集按鈕會編程停止采集的按鈕（帶黑色正方形）
3，在手機執行你檢測耗時的操作。比如：我想測試最近通話和聯系人Tab的切換耗時。就去手動去不斷去切換Tab界面或者也可以用腳本
4，執行完操作后，點擊停止采集的按鈕（帶黑色正方形）停止采集，就會生成.trace文件，如下圖：
3.1.2 在代碼中用代碼設置開始采集的點和停止采集的點
比如應用的冷啟動，進程還沒有出現是無法選擇進程的。比如界面跳轉的耗時情況想精確到哪里開啟采集，哪里結束采集。就需要在代碼中用代碼設置。
下面以冷啟動舉個栗子
1，設置開始采集點--Debug.startMethodTracing();
在Application的onCreate()方法中寫上Debug.startMethodTracing();為開始采集
2，設置結束采集點 -- Debug.stopMethodTracing();
我們就在主界面顯示的時候設置采集結束點，可以在onResume的末尾，也可以在onWindowFocusChanged參數出入為true的時候設置結束點。
3，運行代碼，生成.trace文件
那么.trace文件在哪里呢？
只可能在兩個地方。
一就是在SD根目錄
二就是在/sdcard/Android/data/包名/files/dmtrace.trace
4.取出來。相信大家都會。
注意：不采集了要把Debug.startMethodTracing();和Debug.stopMethodTracing();刪掉。
3.2 打開.trace 文件
打開.trace文件也有兩種方式：
3.2.1 在Eclipse上打開（建議你忘記這種方式）
為什么要忘記這種方式？
因為這個搜索用不了。
如果搜索用不了，那么3.3的快速找到耗時的方法就就進行不了。但是還是能找到耗時的方法的。但是就是體力活，說得更準確一點就是眼力活，我保證看到你想哭。所以忘記這樣方式吧。
3,.2.2 用命令打開（推薦）
1,怎么用命令打開？
把.trace 文件拷貝到\sdk\tools這個文件夾下。
1.trace（因為我改名字了而已）。
在這文件夾打開命令行輸入 traceview.bat 1.trace (.trace的全名稱),如下圖
就打開了，如下圖
用命令打開有什么好處呢？當然就是能搜索關鍵字啊！如下圖
但是在DDMS工具中生成.trace 文件默認就是在Eclipse上打開的。怎么辦？
但是是找到這個DDMS生成的.trace 文件啊，但是在哪里呢？
鼠標放在這塊區域，
看到沒有，在這路徑下。
就在這里了。最好點擊修改日期排序，第一個就你要找的文件了。
3.3 快速找到耗時的方法
打開了，最重要的一步來了。這段時間的試錯主要是在哪里試錯，怎么快速找到耗時方法，而不是有了traceView還得用眼睛一行行去看，這是要累死人的節奏啊。
圈中的從左到右
Name ：該線程運行過程中所調用的函數名
Incl Cpu Time %： 某函數占用的CPU時間，包含內部調用其它函數的CPU時間的百分比
Incl Real Time ： 某函數運行的真實時間（以毫秒為單位），內含調用其它函數所占用的真實時間
Call+Recur Calls/Total：某函數被調用次數以及遞歸調用占總調用次數的百分比
Real Time/Call： 同CPU Time/Call類似，只不過統計單位換成了真實時間
這上面是五個列是最重要的。其他列沒有什么作用，為了不受影響，我們把這個五個列放到一起。
這樣就可以排除干擾列了，同時又有更大的空間看清楚Name列的函數名。
然后呢？
還記得Incl Real Time這列嗎？這列就是函數的耗時時間。
我們就讓這列的耗時時間從大到小排列。
點一下列名，就看到
函數的耗時時間從大到小排列了。
這樣有什么用？
這時候就用到搜索功能了。
舉個栗子
我就搜索com.andr(因為我的包名是com.android.dialer但是每一個類的命名都是以com.android.diaer開頭的，所以我搜索了com.andr盡量搜索多一下結果，再判斷是不是我程序的類)。
輸入com.andr,一個個回車，直到找到自己的類的
onPageScrolled這方法總耗時436ms，調用一次耗時1.857ms。
他的函數里面方法
getRtlPosition(position);總耗時175.106ms，占了百分之45.5
再看代碼。
這是viewpager的回調方法onPageScrolled，在切換的viewpager的時候會回調很多次。真的有必要在哪里判斷是不是從右到左的語言嗎？
所以改成：只要在onPageSelected的方法判斷就行了。這個方法在切換完成后只回調一次。
改完之后，運行代碼。再traceView一下。對比是否改好了。
用命令打開，優化的.trace 文件。
搜索onPageScrolled這個優化后的代碼看總耗時和每次耗時多少。
很明顯看出來上面的沒有優化前的被調用235次一共耗時436.367ms。每次調用1.857ms
和優化后的被調用了319次才一共耗時279.367ms要小得多。每次調用1.721ms
接下就在原來的trace文件找耗時方法了。同上。
總結 ： 就是根據Incl Real Time進行從耗時時間從長到短排序，然后搜索關鍵字符串，找屬于自己的代碼的耗時方法，優化即可
注意：traceView寫的多少ms都不等同于代碼的執行的真實時間。但是是代碼執行真實時間的倍數。有可能是2倍，5倍，10倍什么的，但是一定具備參考意義。
關于這個套路和TraceView具體使用http://www.lxweimin.com/p/2ef139f5dfac
