參考：
Android應用內存泄露分析、改善經驗總結
使用新版Android Studio檢測內存泄露和性能
解決安卓CPU使用率過高問題
Android CPU使用過大的問題解決以及造成的原因
AndroidStudio CPU Monitor使用介紹
Skipped 60 frames! The application may be doing too much work on its main thread
前言：
通過這幾天對好幾個應用的內存泄露檢測和改善，效果明顯：
完全退出應用時，手動觸發GC，從原來占有內存100多M降到低于20M；
手動觸發GC后，通過adb shell dumpsys meminfo packagename -d查看Activity和View的數量也趨近于0了（沒有做到歸零是因為SDK中存在內存泄露，需要中間層去處理）；
發現了一個SDK中的內存泄露（Android InputMethodManager 導致的內存泄露及解決方案）；
發現一個MTK Webview的內存泄露(org.chromium.android_webview.AwPasswordHandler.java中private static AwPasswordHandler sInstance = null導致的內存泄露)。
從結果來看我分析和改善內存泄露的方法是對的，這個過程并不復雜，所以可以梳理總結出來作為分享。
原則
對于性能問題，分析和改善有必要遵循以下原則：
- 一切看數據說話，不能跟著感覺走，感覺哪有問題就去改，很有可能會適得其反；
- 性能優化是一個持續的過程，需要不斷地改善，不要想著一氣呵成；
- 對于性能問題，不一定必須要改善，受限于架構或者其它原因某些問題可能會很難改善，必須要先保證能用，再才考慮好用。
- 改善后一定要驗證，任何一個地方的改動都需要驗證，避免因為改善性能問題導致其它的問題。
步驟
下面是我在針對內存泄露這個性能問題上的解決步驟：
優先處理常見的內存泄露問題
首先解決常見的內存泄露問題，這個過程可以借助Android Studio的Analyze-Inspect Code對代碼做靜態分析，常見的內存泄露問題有：
- 非靜態內部類導致的內存泄露，比如Handler，解決方法是將內部類寫成靜態內部類，在靜態內部類中使用軟引用/弱引用持有外部類的實例，eg：
static class ExerciseHandler extends Handler{
private SoftReference<ExerciseActivity> exerciseActivitySoftReference = null;
public ExerciseHandler(ExerciseActivity exerciseActivity){
exerciseActivitySoftReference = new SoftReference<ExerciseActivity>(exerciseActivity);
}
@Override
public void handleMessage(Message msg) {
ExerciseActivity exerciseActivity = exerciseActivitySoftReference.get();
if(null != exerciseActivity){
super.handleMessage(msg);
switch (msg.what) {
case MSG_XX:
exerciseActivity.***;
break；
default:
break;
}
}
}
}
IO操作后，沒有關閉文件導致的內存泄露，比如Cursor、FileInputStream、FileOutputStream使用完后沒有關閉，這種問題在Android Studio 2.0中能夠通過靜態代碼分析檢查出來，直接改善就可以了；
自定義View中使用TypedArray后，沒有recycle，這種問題也可以在Android Studio 2.0中能夠通過靜態代碼分析檢查出來，直接改善就可以了；
-
某些地方使用了四大組件的context，在離開這些組件后仍然持有其context導致的內存泄露，這種問題屬于共識，在編寫代碼的過程中就應該按照規則來，使用Application的Context就可以解決這類內存泄露的問題了，至于什么情況下應該使用四大組件的Context，什么時候應該使用Application的context可以參見下表：
application使用場景
備注：大家注意看到有一些NO上添加了一些數字，其實這些從能力上來說是YES，但是為什么說是NO呢？下面一個一個解釋：
數字1：啟動Activity在這些類中是可以的，但是需要創建一個新的task，一般情況不推薦；
數字2：在這些類中去layout inflate是合法的，但是會使用系統默認的主題樣式，如果你自定義了某些樣式可能不會被使用；
數字3：在Receiver為null時允許，在4.2或以上的版本中，用于獲取黏性廣播的當前值。（可以無視）；
ContentProvider、BroadcastReceiver之所以在上述表格中，是因為在其內部方法中都有一個context用于使用。
還有一種不屬于內存泄露，但在分析內存泄露的問題時應該一并解決：同一個APP，將圖片放在不同的drawable文件夾下，在相同的設備上占用的內存情況不一樣，具體可以參見：關于Android中圖片大小、內存占用與drawable文件夾關系的研究與分析。解決這個問題遵循以下原則就可以了：1、UI只提供一套高分辨率的圖，圖片建議放在drawable-xxhdpi文件夾下（放在xxxhdpi或者更高分辨率的文件夾下沒有必要，權衡利弊，照顧主流設備即可），這樣在低分辨率設備中圖片的大小只是壓縮，不會存在內存增大的情況；2、涉及到桌面插件或者不需要縮放的圖片，放在drawable-nodpi文件夾下，這個文件夾下的圖片在任何設備上都是不會縮放的。
通過工具檢查程序運行后的內存泄露
通過上面的步驟，應用中的大部分內存泄露問題都能夠得到解決，還有一些內存泄露，需要運行程序，分析運行后的內存快照來解決，比如注冊之后沒有反注冊、類中的靜態成員變量導致的內存泄露、SDK中的內存泄露等。解決這類問題可以分兩步進行：
- 通過內存泄露檢測工具先定位是哪有問題，內存泄露的檢測有兩種比較便捷的方式：1、一種是使用開源項目Leakcanary，需要添加到代碼中，運行后生成分析結果；2、另一種方式是使用adb shell dumpsys meminfo packagename -d命令，在進入一個界面之前查看一遍Activity和View的數量，在退出這個界面之后再查看一遍Activity和View的數量，對比進入前和進入后Activity和View數量的變化情況，如果有差異，則說明存在內存泄露（在使用命令查看Activity和View的數量之前，記得手動觸發GC）。
備注：在Android Studio中，可以通過如下方式獲取當前選中進程的內存信息：
然后通過MAT取程序運行時的內存快照做詳細分析，對于MAT的使用，網上有很多優質的文章，比如：Android 性能優化之使用MAT分析內存泄露問題，在使用MAT前，有必要知道這幾點：1、 不要指望MAT明確告訴你哪里存在內存泄露，這需要你根據上一步驟首先定位到可能存在內存泄露的類，然后借助MAT確認是否真的存在內存泄露，具體哪個地方存在內存泄露；2、借助Retained Size分析某一個類及與之相關的實例所消耗的內存，如果這個類的Retained Size比較大，優先分析；3、檢查某個類是否存在內存泄露時，排除其軟/弱/虛引用，右鍵某個類→Merge Shortest Paths to GC Roots→exclude all phantom/weak/soft etc.references。
驗證改善效果
根據個人經驗，我一般是這樣驗證改善效果的，運行程序，各個功能跑一遍，確保沒有改出問題，完全退出程序，手動觸發GC，然后通過adb shell dumpsys meminfo packagename -d查看Activivites和Views的數量是否趨近于0；如果不是0，通過Leakcanary檢查可能存在內存泄露的地方，繼續通過MAT分析，周而復始，改善到自己滿意為止。
