LeakCanary
一言以蔽之:LeakCanary是一个傻瓜化并且可视化的内存泄露分析工具 为什么需要LeakCanary? 因为它简单,易于发现问题,人人可参与。 简单:只需设置一段代码即可,打开应用运行一下就能够发现内存泄露。而MAT分析需要Heap Dump,获取文件,手动分析等多个步骤。 易于发现问题:在手机端即可查看问题即引用关系,而MAT则需要你分析,找到Path To GC Roots等关系。 人人可参与:开发人员,测试测试,产品经理基本上只要会用App就有可能发现问题。而传统的MAT方式,只有部分开发者才有精力和能力实施。 如何集成 尽量在app下的build.gradle中加入以下依赖 dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1' // or 1.4-beta1 releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' // or 1.4-beta1 testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' // or 1.4-beta1 } 在Application中加入类似如下的代码 public class MyApplication extends Application { private static RefWatcher sRefWatcher; @Override public void onCreate() { super.onCreate(); sRefWatcher = LeakCanary.install(this); } public static RefWatcher getRefWatcher() { return sRefWatcher; } } 到这里你就可以检测到Activity的内容泄露了。其实现原理是设置Application的ActivityLifecycleCallbacks方法监控所有Activity的生命周期回调。内部实现代码为 想要检测更多? 首先我们需要获得一个RefWatcher,用来后续监控可能发生泄漏的对象 默认情况下,是对Activity进行了检测。另一个需要监控的重要对象就是Fragment实例。因为它和Activity实例一样可能持有大量的视图以及视图需要的资源(比如Bitmap)即在Fragment onDestroy方法中加入如下实现 public class MainFragment extends Fragment { @Override public void onDestroy() { super.onDestroy(); MyApplication.getRefWatcher().watch(this); } } 其他也可以监控的对象 BroadcastReceiver Service 其他有生命周期的对象 直接间接持有大内存占用的对象(即Retained Heap值比较大的对象) 何时进行监控 首先,我们需要明确什么是内存泄露,简而言之,某个对象在该释放的时候由于被其他对象持有没有被释放,因而造成了内存泄露。 因此,我们监控也需要设置在对象(很快)被释放的时候,如Activity和Fragment的onDestroy方法。 一个错误示例,比如监控一个Activity,放在onCreate就会大错特错了,那么你每次都会收到Activity的泄露通知。 如何解决 常用的解决方法思路如下 尽量使用Application的Context而不是Activity的 使用弱引用或者软引用 手动设置null,解除引用关系 将内部类设置为static,不隐式持有外部的实例 注册与反注册成对出现,在对象合适的生命周期进行反注册操作。 如果没有修改的权限,比如系统或者第三方SDK,可以使用反射进行解决持有关系 LeakCanary