android 内存监测,LeakCanary - Android内存检测工具

LeakCanary背景

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)

大名鼎鼎的OOM，就是内存泄漏，那什么是内存泄漏呢？

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

举个例子，当 Activity.onDestroy被调用之后，activity以及它涉及到的view和相关的bitmap都应该被回收。但是，如果有一个后台线程持有这个activity的引用，那么activity对应的内存就不能被回收。这最终将会导致内存耗尽，然后因为OOM而崩溃，这个，就叫做内存泄漏。

所以，我们在写程序的时候，要捕捉到我们写的存在内存泄漏的代码修复掉，LeakCanary就应运而生！

LeakCanary简介

LeakCanary 是啥？它的说明是这样的：

A memory leak detection library for Android and Java./一个Android和java内存泄漏检测库。

很简单，就是捕获内存泄漏的

LeakCanary好处

它可以在我们的应用发生内存泄漏的时候发出提醒，提醒包括通知和Log。并且集成起来特别简单方便

LeakCanary缺点

有好处就会有缺点，LeakCanary也不是万能的。

它是在相应的问题页面回退之后才会分析是否存在内存泄漏，如果存在内存泄漏，将进行相应的分析并处理，若没有则不会。它不能做到MAT或者studio中相应的实时查看内存状态，并且检测具有很大的延时，最少10s。

LeakCanary使用

①在你的build.gradle中添加依赖：

dependencies {

debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.4'

releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'

}

②在你的Application中初始化

public class MyApplication 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...

}

}

这样就可以了。

然后测试一下怎么样，我们自己弄出一个内存泄露看看它怎么工作的吧

public class ErrorTestActivity extends AppCompatActivity {

private static ErrorTest mErrorTest;

@Override

protected void onCreate(@Nullable Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

if (mErrorTest == null) {

mErrorTest = new ErrorTest();

}

finish();

}

class ErrorTest {

}

}

我们首先再来分析一下这个程序：

这个Activity中，存在一个静态的ErrorTest实例，并且这个实例在Activity初始化的时候也进行了初始化，接着我们在初始化完毕后finish掉这个Activity。

因为mErrorTest是一个静态的变量并且不为null，所以GC不会将其清理，而Activity因为持有这个静态变量，生命周期也不能正常执行，不能进行onDestroy()。这样这个Activity内存泄漏了！

安装我们的应用后，手机上会出现如下两个图标：

左侧的是自己应用的图标，右侧是自动给安装的LeakCanary的图标。

安装样式

打开我们的APP，跳转到我们的问题页面ErrorTestActivity，人为制造内存泄漏，之后Back出去，等一段时间，看情况，一般会大于10s，有些会更长(不清楚具体的触发条件，什么时候开始检测，作者也没具体说明)因为ErrorTestActivity存在内存泄漏，LeakCanary就会检测出来，Toast提示：

检测样式

OK，出现这样的Toast，你的代码就存在内存泄漏了，然后打开自动给你安装的LeakCanary小程序(这里需要点小耐心，因为需要一会才会更新到LeakCanary上面)

展示错误信息

OK，根据展示信息，ErrorTestActivity里面的的实例对象被泄漏了

LeakCanary进阶 - RefWatcher

RefWatcher的作用是监控那些本该被回收的对象

看上面我们在Application我们初始化LeakCanary的代码有这么一行：

LeakCanary.install(this);

它会返回一个预定义的RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控

调用了Activity.onDestroy()之后存在泄露的activity。我们也可以使用RefWatcher来监测我们关心的对象。

那这样我们可以这么写我们的Application

public class MyApplication extends Application {

private static RefWatcher refWatcher;

@Override

public void onCreate() {

super.onCreate();

if (LeakCanary.isInAnalyzerProcess(this)) {

return;

}

//LEAK_ENABLE就是个开关，我是用来标识发包版本关闭LeakCanary工具的

ifBuildConfig.LEAK_ENABLE){

refWatcher = LeakCanary.install(this);

}

}

public static RefWatcher getRefWatcher() {

return refWatcher;

}

}

这样我们就可以使用RefWatcher监控一些本该关掉(调用onDestroy了)的对象，比如使用RefWatcher监控自定义的Fragment：

public abstract class TLifeBaseFragment extends Fragment {

····

@Override

public void onDestroy() {

super.onDestroy();

RefWatcher refWatcher = MyApplication.getRefWatcher();

refWatcher.watch(this);

}

}

最后附上GitHub的链接地址：GitHub