前言

  通過這幾天對好幾個應用的記憶體洩露檢測和改善，效果明顯：

• 完全退出應用時，手動觸發GC，從原來佔有記憶體100多M降到低於20M；

• 手動觸發GC後，通過adb shell dumpsys meminfo packagename -d檢視Activity和View的數量也趨近於0了（沒有做到歸零是因為SDK中存在記憶體洩露，需要中間層去處理）；

• 發現一個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、數字1：啟動Activity在這些類中是可以的，但是需要建立一個新的task，一般情況不推薦；

2、數字2：在這些類中去layout inflate是合法的，但是會使用系統預設的主題樣式，如果你自定義了某些樣式可能不會被使用；

3、數字3：在Receiver為null時允許，在4.2或以上的版本中，用於獲取黏性廣播的當前值。（可以無視）；

4、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分析，周而復始，改善到自己滿意為止。

推薦閱讀