转载请注明出处：http://blog.csdn.net/llew2011/article/details/52958563

       在上篇文章Android 源码系列之<十二>从源码的角度深入理解LeakCanary的内存泄露检测机制(上)中主要介绍了Java内存分配相关的知识以及在Android开发中可能遇见的各种内存泄露情况并给出了相对应的解决方案，如果你还没有看过上篇文章，建议点击这里阅读一下，这篇文章我将要向大家介绍如何在我们的应用中使用square开源的LeakCanary库来检测应用中出现的内存泄露，如果你已经对LeakCanary的使用非常熟悉了请跳过本文(*^__^*) ……

       以介绍来自英文LeakCanary: Detect all memory leaks!的翻译，原文在这里。

java.lang.OutOfMemoryError
        at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
        at android.graphics.Bitmap.createBitmap(Bitmap.java:689)
        at com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)

没人喜欢OutOfMemoryError

       在Square Register中，在签名页面我们把客户的签名画在bitmap cache上，这个Bitmap的尺寸几乎和屏幕的尺寸一样大，在创建这个Bitmap对象时，经常会引发OutOfMemoryError，简称OOM。

        当时，我们尝试过一些解决方案，但是都没解决问题：

• 使用Bitmap.Config.ALPHA_8，因为签名仅有黑色。
• 捕捉OutOfMemoryError，尝试GC并重试(受GCUtils启发)。
• 我们没想过在Java Heap内存之外创建Bitmap，苦逼的我们，那会Fresco等库还不存在。

路子走错了

       其实Bitmap的尺寸不是真正的问题，当内存吃紧的时候，到处都有可能引发OOM，在创建大对象，比如Bitmap的时候，则更有可能引发OOM，OOM只是一个表象，更深层次的问题可能是：内存泄露。

什么是内存泄露

       一些对象有着有限的声明周期，当这些对象所要做的事情完成了，我们希望它们会被垃圾回收器回收掉。但是如果有一系列对这个对象的引用存在，那么在我们期待这个对象生命周期结束时被垃圾回收器回收的时候，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。

       比如：当Activity的onDestroy()方法被调用后，Activity以及它涉及到的View和相关的Bitmap都应该被回收掉。但是，如果有一个后台线程持有这个Activity的引用，那么该Activity所占用的内存就不能被回收，这最终将会导致内存耗尽引发OOM而让应用crash掉。

对战内存泄露

       排查内存泄露是一个全手工的过程，这在Raizlabs的Wrang Dalvik系列文章中有详细描述。以下几个关键步骤：

1. 通过Bugsnag，Crashlytics或者Developer Console等统计平台，了解OutOfMemoryError情况。
2. 重现问题。为了重现问题，机型非常重要，因为一些问题只在特定的设备上出现。为了找到特定的机型，你需要想尽一切办法，你可能需要去买，去借，甚至去偷。当然，为了确定复现步骤，你需要一遍一遍地去尝试。一切都是非常原始和粗暴的。
3. 在发生内存泄露的时候，把内存Dump出来。具体看这里。
4. 然后，你需要在MAT或者YourKit之类的内存分析工具中反复查看，找到那些原本该被回收掉的对象。
5. 计算这个对象到GC Roots的最短强引用。
6. 确定应用路径中的哪个应用是不该有的，然后修复。

       很复杂吧？如果有一个类库能在发生OOM之前把这些事情全部搞定，然后你只要修复这些问题就好了，岂不美哉！！！这就是LeakCanary的由来，接下来我们就要介绍一下LeakCanary的使用。

       由于Google已经不再对Eclipse上开发Android做支持，所以就不再Eclipse上演示如何使用LeakCanary了，LeakCanary的官方网址为：https://github.com/square/leakcanary，根据指导文档，使用LeakCanary首先要引入，在build.gradle中添加依赖，如下所示：

dependencies {
	debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.5‘
	releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘
	testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘
}

       引入了LeakCanary的依赖库后，接下来就是使用它了，根据GitHub上的指导文档，首先在我们的Application中初始化LeakCanary，如下所示：

public class ExampleApplication 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);
    }
}

public class LeakActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.leak_activity);
    }

    public void start(View view) {
        new Thread() {
            @Override
            public void run() {
                while (true) {
                    try {
                        Thread.sleep(1000);
                        Log.e(getPackageName(), "LeakCanary ----->>>>> " + System.currentTimeMillis());
                    } catch (Exception e) {
                    }
                }
            }
        }.start();
    }
}

       根据运行效果来看，在LeakActivity页面在点击按钮启动了线程后返回到主页面后，大约5秒钟后会弹出一个提示框，提示说在进行内存泄露检测，稍后你会发现在状态栏上弹出了一个Notification，我们展开这个Notification看看里边是啥东东：

       弹出的Notification大致说了包名为com.example.leakcanary下的LeakActivity发生了内存泄露，泄露的内存大约是108KB，如果想要查看更为详细的内存泄露信息，可以点击查看，然后我们点击进去看看详细的内存泄露信息，如下所示：

       内存泄露引用链清晰详细的列举了发生内存泄露的原因，根据这种引用关系我们可以很容易的定位到内存泄露点，然后修复这些泄露问题。怎么样？是不是很简单？从此可以对身边的小伙伴说：用了LeakCanary以后再也不怕内存泄露了(*^__^*) ……检测到LeakActivity发生了内存泄露，根据上篇文章的修复方法修改一下LeakActivity之后再运行程序就不会有Notification弹出了。

       LeakCanary的使用就是这么简单，如果你还没使用过它强烈建议使用一次，相信你用过之后就会离不开它的(*^__^*) ……在我们引入LeakCanary的时候我们引入了三种不同模式的库，他们之间肯定是有区别的，下载完它的源码后，其结构图如下所示：

       通过阅读LeakCanary的代码发现leakcanary-android是真正内存泄露分析库，而leakcanary-android-no-op只是一个空壳子，里边啥也没做。也就是说在打release包的时候LeakCanary库根本就不会打进去，所以不不用担心引入额外的方法，只有在debug或者test模式下LeakCanary库才会打包进APK。

       首先看一下leakcanary-android下的AndroidManifest.xml文件，如下所示：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.squareup.leakcanary">

    <!-- To store the heap dumps and leak analysis results. -->
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

    <application>
        <service
            android:name=".internal.HeapAnalyzerService"
            android:enabled="false"
            android:process=":leakcanary" />
        <service
            android:name=".DisplayLeakService"
            android:enabled="false" />

        <activity
            android:name=".internal.DisplayLeakActivity"
            android:enabled="false"
            android:icon="@drawable/leak_canary_icon"
            android:label="@string/leak_canary_display_activity_label"
            android:taskAffinity="com.squareup.leakcanary"
            android:theme="@style/leak_canary_LeakCanary.Base">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <activity
            android:name=".internal.RequestStoragePermissionActivity"
            android:enabled="false"
            android:icon="@drawable/leak_canary_icon"
            android:label="@string/leak_canary_storage_permission_activity_label"
            android:taskAffinity="com.squareup.leakcanary"
            android:theme="@style/leak_canary_Theme.Transparent" />
    </application>
</manifest>

       了解了LeakCanary的相关配置后我们再看一下它的相关资源文件：

       资源文件就不详细说明了，对于这些资源我们能做的就是如果不喜欢这些资源文件，我们可以在项目中把它替换掉。

       由于篇幅原因，这里就不再过多的分析LeakCanary的源码了，在下篇文章中我将带领小伙伴们从源码的角度出发深入分析一下LeakCanary的内存泄露分析机制，敬请期待！！！最后感谢收看(*^__^*) ……

       【参考文章：】

       https://medium.com/square-corner-blog/leakcanary-detect-all-memory-leaks-875ff8360745#.klentg7g4

Android 源码系列之<十三>从源码的角度深入理解LeakCanary的内存泄露检测机制(中)