一、性能優化
TraceView性能分析工具
TraceView: ddms中的一個分析工具
使用方式 start method profiling 開始跟蹤 stop method profiliing 結束跟蹤
按方法調用消耗時間的降序排列，分析耗時較多的方法是否有優化的空間；
二、內存優化
內存溢出(out of memory)：簡稱oom是指程序在申請內存空間後，沒有足夠的內存空間供其使用
內存泄漏(memory leak):是指程序在申請內存空間後，無法釋放已申請的內存空間。
程序加載到手機內存中，數據擠爆內存稱爲oom，數據引用無法得到釋放稱爲內存泄露
內存溢出:編譯的時候就會報錯，這個好解決，一般都是加載大圖，或者大數據
內存泄露:運行的時候，沒有報錯，程序正常運行，但是運行多邊，就會卡頓，或者蹦掉。
可以用使用工具來檢查:leakcanary
1.使用方法
添加依賴:
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
Application中初始化:
public class ExampleApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 初始化LeakCanary
if (LeakCanary.isInAnalyzerProcess(this)) {
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}
運行之後，打開你要檢查的app,隨意點擊，會有彈框出現，有消息顯示內存泄漏。
常見你的內存泄漏情況:
1.靜態變量的使用(靜態變量直接或者間接地引用了Activity對象會造成內存泄漏)
Activity定義成了靜態變量(activity靜態變量直接加載到內存中，然而突然app關閉當前activity，內存中還有引用指向activity，造成了內存泄漏)
Activity中使用了靜態的View(View會持有Activity的對象引用)（靜態的view也是開始的時候加載到內存中，每當activity中關閉的時候，view的引用還在內存空間中，沒有得到釋放，就會造成內存泄漏）
ImageSpan引用了Activity Context
單例引用了Activity Context（單例同樣是靜態的，引用了activity的引用）
2.線程(包括AsyncTask)的使用:Activity退出後線程還在運行，並且線程中使用了Activity或View對象
3.Handler對象的使用:Activity退出後Handler仍有消息要處理；（Handler接收子線程中發過來的消息，應該是activity退出後，Handler也要取消，消息不再接收，引用釋放掉，handler的輪詢器在內存中運行，activity沒有關閉後，沒有釋放handler，handler還有activity的引用）
4.廣播接收者沒有註銷;服務沒有解綁;遊標關閉，流關閉
5.在Activity中創建了非靜態內部類(內部類中直接或者間接引用到了Activity)的靜態變量
6.靜態集合保存的對象沒有及時清除;（LeakCanary分析不了，使用DDMS及MAT）
注意在Java中，非靜態(匿名)內部類會引用外部類對象，而靜態內部類不會引用外部類對象。
通過DDMS和MAT工具分析，操作步驟如下：
通過DDMS（或者AS的monitor -> memery窗口）發現問題： 通過AS中的Monitor窗口進行分析，查看內存分配情況，如果操作應用時內存一直往上漲說明可能存在內存泄漏。
通過MAT定位問題： 使用 Memory Analyzer tool(MAT)
使用： 需要生成一個hprof文件，再使用hprof-conv.exe對hprof文件進行處理， 再用MAT打開該文件進行分析
hprof-conv.exe工具的使用
hprof-conv a.hprof b.hprof