Android開發學習之路-LeakCanary使用

標籤：

LeakCanary是一個記憶體流失檢測庫，它可以在我們的應用發生記憶體流失的時候發出提醒，提醒包括通知和Log。GitHub

這個庫使用起來比較簡單：

①添加依賴：

1  dependencies {2    debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.5‘3    releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘4    testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘5  }

②自訂Application

 1 public class MyApplication extends Application { 2     @Override 3     public void onCreate() { 4         super.onCreate(); 5         if (LeakCanary.isInAnalyzerProcess(this)) { 6             return; 7         } 8         LeakCanary.install(this); 9     }10 }

這樣就可以了。

我們這裡通過簡單的例子看看它的效果，我們都知道，記憶體流失比較容易發生的，就是因為生命週期不匹配導致的。Android中的組件都是有特定生命週期的，而當這些組件中存在著不可釋放的變數時，組件的生命週期便會出現異常，導致無法被GC釋放。

這裡舉一個簡單的例子：

 1 public class SecondActivity extends AppCompatActivity { 2     static Demo sDemo; 3  4     @Override 5     protected void onCreate(Bundle savedInstanceState) { 6         super.onCreate(savedInstanceState); 7         setContentView(R.layout.activity_second); 8         if (sDemo == null) { 9             sDemo = new Demo();10         }11         finish();12     }13 14     class Demo {15     }16 17 }

這個Activity中，存在一個靜態Demo執行個體，並且這個執行個體在Activity初始化的時候也進行了初始化，接著我們在初始化完畢後finish掉這個Activity。

因為sDemo是一個靜態變數並且不為null，所以GC不會將其清理，而Activity因為持有這個靜態變數，生命週期也不能正常執行，這樣這個Activity就被泄漏了。

我們在MainActivity中開啟這個Activity，啟動應用。

模擬器的狀態列會出現一個表徵圖，我們開啟可以得到如下介面：

可以看到，和我們分析的一樣，SecondActivity的執行個體被泄漏了。

實際上，LeakCanary除了會在介面中顯示泄漏資訊之外，Log中也一樣會輸出泄漏的具體資訊：

這樣追蹤泄漏的地方就不難了。

Android開發學習之路-LeakCanary使用