通過這幾天對好幾個應用的記憶體洩露檢測和改善，效果明顯：
從結果來看我分析和改善記憶體洩露的方法是對的，這個過程並不複雜，所以可以梳理總結出來作為分享。
對於效能問題，分析和改善有必要遵循以下原則：
下面是我在針對記憶體洩露這個效能問題上的解決步驟：
首先解決常見的記憶體洩露問題，這個過程可以借助android studio的analyze-inspect code對**做靜態分析，常見的記憶體洩露問題有：
備註：大家注意看到有一些no上新增了一些數字，其實這些從能力上來說是yes，但是為什麼說是no呢？下面乙個乙個解釋：
1、數字1：啟動activity在這些類中是可以的，但是需要建立乙個新的task，一般情況不推薦；
2、數字2：在這些類中去layout inflate是合法的，但是會使用系統預設的主題樣式，如果你自定義了某些樣式可能不會被使用；
3、數字3：在receiver為null時允許，在4.2或以上的版本中，用於獲取黏性廣播的當前值。（可以無視）；
4、contentprovider、broadcastreceiver之所以在上述**中，是因為在其內部方法中都有乙個context用於使用。
1、ui只提供一套高解析度的圖，建議放在drawable-xxhdpi資料夾下（放在***hdpi或者更高解析度的資料夾下沒有必要，權衡利弊，照顧主流裝置即可），這樣在低解析度裝置中的大小只是壓縮，不會存在記憶體增大的情況；
2、涉及到桌面外掛程式或者不需要縮放的，放在drawable-nodpi資料夾下，這個資料夾下的在任何裝置上都是不會縮放的。
通過上面的步驟，應用中的大部分記憶體洩露問題都能夠得到解決，還有一些記憶體洩露，需要執行程式，分析執行後的記憶體快照來解決，比如註冊之後沒有反註冊、類中的靜態成員變數導致的記憶體洩露、sdk中的記憶體洩露等。解決這類問題可以分兩步進行：
根據個人經驗，我一般是這樣驗證改善效果的，執行程式，各個功能跑一遍，確保沒有改出問題，完全退出程式，手動觸發gc，然後通過adb shell dumpsys meminfo packagename -d檢視activivites和views的數量是否趨近於0；如果不是0，通過leakcanary檢查可能存在記憶體洩露的地方，繼續通過mat分析，周而復始，改善到自己滿意為止。
張明雲，
Android記憶體洩露
android應用記憶體洩漏的的原因有以下幾個 1查詢資料庫後沒有關閉游標cursor 2 構造adapter時，沒有使用 convertview 重用 3 bitmap物件不在使用時呼叫recycle 釋放記憶體 4 物件被生命週期長的物件引用，如activity被靜態集合引用導致activity...
android 記憶體洩露
記憶體洩露情況 1 使用單例導致記憶體洩露 public class singleton public static singleton getsingleton context context return singleton 原因 靜態的單例使它的生命週期與應用的生命週期一樣長，context一...
記憶體洩露分析
記憶體洩露分析demo gflags標誌設定好後，開啟cmd 鍵入要定位記憶體洩露的程式gflags.exe i memroyleak.exe 程式名稱 ust 如圖成功後，開啟memoryleak.exe程式 命令格式 umdh pn memoryleak.exe 程式名稱 f snap1.log...