最近要對產品進行內存泄漏的檢查，最后選擇了使用Square公司開源的一個檢測內存泄漏的函數庫LeakCanary，在github上面搜索了一下竟然有1.6w個star，并且Android大神JakeWharton也是這個開源庫的貢獻者。那么就趕快拿來用吧。
- 先說一下我遇到的坑，我當時是直接google的，然后就直接搜索到稀土掘金的一篇關于LeakCanary的介紹，我就按照他們的文章一步步的操作，到最后才發現，他們那個build.gradle中導入的庫太老了，會報這樣的錯誤
Closed Failed to resolve: com.squareup.leakcanary:leakcanary對于剛使用LeakCanary的我很是費解。 - 然后我就直接使用Github上的例子去引入LeakCanary https://github.com/square/leakcanary
但是又有一個問題，就是構建項目失敗，在Github上面也有說明地址連接https://github.com/square/leakcanary/issues/815 - 好了說完這些坑之后，接下來就讓我們愉快的使用LeakCanary來檢測內存泄漏吧
1 導入步驟
- 因為不想讓這樣的檢查在正式給用戶的 release 版本中也進行，所以在 dependencies 里添加
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
}
- 接下來，在你的應用里寫一個自定義 Application ，并在其中“安裝” RefWatcher
public class AppApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}
記得把它作為 android:name 配到 AndroidManifest.xml 的 Application 節點下。
- 上面的只能監控Activity中的內存，所以想要檢測Fragment中的內存泄漏的話也是很簡單只需要先在Application中保存全局的RefWatcher
public class App extends Application {
//Application為整個應用保存全局的RefWatcher
private RefWatcher refWatcher;
@Override
public void onCreate() {
super.onCreate();
refWatcher = LeakCanary.install(this);
}
public static RefWatcher getRefWatcher(Context context) {
App application = (App) context.getApplicationContext();
return application.refWatcher;
}
}
- 還需要創建一個BaseFragment添加如下代碼：
public abstract class BaseFragment extends Fragment {
@Override
public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = App.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
Ok，導入成功后，用Debug版打包，安裝后，手機上面會自動多一個leak的應用，當有內存泄漏的時候，就會在里面顯示。這里還有一個問題，就是在我的4.4的手機并不能出現那個內存泄漏的icon。
選擇打包
這里寫圖片描述
導入成功后的icon
這里寫圖片描述
2 內存泄漏解決方法
- 下面說一下常見的幾個內存泄漏的解決方法
1 單例 Context 內存泄露
這里先創建一個很簡單的單例對象
public class TestHelper {
private Context mCtx;
private TextView mTextView;
private static TestHelper ourInstance = null;
private TestHelper(Context context) {
this.mCtx = context;
}
public static TestHelper getInstance(Context context) {
if (ourInstance == null) {
ourInstance = new TestHelper(context);
}
return ourInstance;
}
}
然后我們在Activity中調用它，其實很多時候我們都會犯這樣的錯誤。造成這樣錯誤的原因很簡單，就是這個 ContextLeakActivity 不在了之后， TestHelper 依然會 hold 住它的 Context 不放。這樣就造成了內存泄漏。
public class ContextLeakActivity extends AppCompatActivity{
private TestHelper mTestHelper;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//這里容易引起內存泄漏
//我們在 ContextLeakActivity 里獲取 TestHelper 實例時因為傳入了 MainActivity 的 Context，
// 這使得一旦這個 Activity 不在了之后，
// TestHelper 依然會 hold 住它的 Context 不放，而這個時候因為 Activity 已經不在了，所以內存泄露自然就產生了。
mTestHelper=TestHelper.getInstance(this);
//避免內存泄漏的寫法
// mTestHelper=TestHelper.getInstance(this.getApplication());
}
}
Context 內存泄漏提示圖
這里寫圖片描述
2 Broadcast引起的內存泄漏： 當我們注冊過BroadcastReceiver之后，卻沒有在Activity銷毀之后，把BroadcastReceiver釋放，就很容易引起內存泄漏，所以要在onDestroy()中銷毀BroadcastReceiver。
銷毀代碼如下
@Override
protected void onDestroy() {
super.onDestroy();
getLocalBroadcastManager().unregisterReceiver(mExitReceiver);
}
Broadcast的內存泄漏提示圖
b.png
