最近要對產品進行內存泄漏的檢查，最后選擇了使用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的內存泄漏提示圖
Ok，使用LeakLeakCanary很簡單，但是解決有些內存泄漏確實有點麻煩，但是不論什么樣的內存泄漏，最關鍵的一點就是：在生命周期結束之前，把對象銷毀即可。如果感覺我的文章對您有用，請給個喜歡，謝謝
Demo下載地址連接LeakDemo.rar
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持VEVB武林網。
新聞熱點
疑難解答
