使用LeakCanary遇到的问题 就是不弹出来
今天楼主遇到引用LeakCanary时代码跟官网一样但是就不弹出来。楼主新建项目就可以正常使用。楼主郁闷半天，现在终于整出来了。
楼主主工程app引用module为thirdParty，本想为了整洁三方的都扔进这个thirdParty 结果导致了这个没弄出来。
1.写一个application ：
[java] view plaincopy print?2.写一段让程序泄露的代码：
[java] view plaincopy print?
3.添加build.gradle 由于我把所有的依赖都写在的thirdParty这个lib中
仔细观察一下这个引用不太一样：
我们平时引用都是:
[java] view plaincopy print?而LeakCanary的引用是：
[java] view plaincopy print?
后来我又写到了主app中 结果可以使用了。。。
查了一下他们的含义：
Compile
compile是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中。
Provided
Provided是对所有的build type以及favlors只在编译时使用，类似eclipse中的external-libs,只参与编译，不打包到最终apk。
APK
只会打包到apk文件中，而不参与编译，所以不能再代码中直接调用jar中的类或方法，否则在编译时会报错
Test compile
Test compile 仅仅是针对单元测试代码的编译编译以及最终打包测试apk时有效，而对正常的debug或者release apk包不起作用。
Debug compile
Debug compile 仅仅针对debug模式的编译和最终的debug apk打包。
Release compile
Release compile 仅仅针对Release 模式的编译和最终的Release apk打包。
还不太清楚为啥。。。但是给大家提个醒。
下面转一个非常好的文章：http://droidyue.com/blog/2016/03/28/android-leakcanary/
懒人可以看我下面的转载
Android内存泄漏检测利器：LeakCanary
是什么？一言以蔽之：LeakCanary是一个傻瓜化并且可视化的内存泄露分析工具
为什么需要LeakCanary？
因为它简单，易于发现问题，人人可参与。
- 简单：只需设置一段代码即可，打开应用运行一下就能够发现内存泄露。而MAT分析需要Heap Dump，获取文件，手动分析等多个步骤。
- 易于发现问题：在手机端即可查看问题即引用关系，而MAT则需要你分析，找到Path To GC Roots等关系。
- 人人可参与：开发人员，测试测试，产品经理基本上只要会用App就有可能发现问题。而传统的MAT方式，只有部分开发者才有精力和能力实施。
如何集成
尽量在app下的build.gradle中加入以下依赖
| 1 2 3 4 5 | 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中加入类似如下的代码
| 1 2 3 4 5 6 7 | public class ExampleApplication extends Application { @Override public void onCreate() { super.onCreate(); LeakCanary.install(this); } } |
到这里你就可以检测到Activity的内容泄露了。其实现原理是设置Application的ActivityLifecycleCallbacks方法监控所有Activity的生命周期回调。内部实现代码为
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | public final class ActivityRefWatcher { private final ActivityLifecycleCallbacks lifecycleCallbacks = new ActivityLifecycleCallbacks() { public void onActivityCreated(Activity activity, Bundle savedInstanceState) { } public void onActivityStarted(Activity activity) { } public void onActivityResumed(Activity activity) { } public void onActivityPaused(Activity activity) { } public void onActivityStopped(Activity activity) { } public void onActivitySaveInstanceState(Activity activity, Bundle outState) { } public void onActivityDestroyed(Activity activity) { ActivityRefWatcher.this.onActivityDestroyed(activity); } }; private final Application application; private final RefWatcher refWatcher; public static void installOnIcsPlus(Application application, RefWatcher refWatcher) { if(VERSION.SDK_INT >= 14) { ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher); activityRefWatcher.watchActivities(); } } .... } |
想要检测更多?
首先我们需要获得一个RefWatcher，用来后续监控可能发生泄漏的对象
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | 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; } } |
监控某个可能存在内存泄露的对象
| 1 | MyApplication.getRefWatcher().watch(sLeaky); |
哪些需要进行监控
默认情况下，是对Activity进行了检测。另一个需要监控的重要对象就是Fragment实例。因为它和Activity实例一样可能持有大量的视图以及视图需要的资源（比如Bitmap）即在Fragment onDestroy方法中加入如下实现
| 1 2 3 4 5 6 7 | 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，可以使用反射进行解决持有关系
加入例外
有些特殊情况，我们需要忽略一些问题，这时候就需要添加例外规则。比如ExampleClass.exampleField会导致内存泄漏，我们想要忽略，如下操作即可。
| 1 2 3 4 5 6 7 8 9 | // ExampleApplication is defined in "Customizing and using the no-op dependency" public class DebugExampleApplication extends ExampleApplication { protected RefWatcher installLeakCanary() { ExcludedRefs excludedRefs = AndroidExcludedRefs.createAppDefaults() .instanceField("com.example.ExampleClass", "exampleField") .build(); return LeakCanary.install(this, DisplayLeakService.class, excludedRefs); } } |
如何实现的
LeakCanary实际上就是在本机上自动做了Heap dump，然后对生成的hprof文件分析，进行结果展示。和手工进行MAT分析步骤基本一致。
如何不影响对外版APK
是的，这个问题确实值得关注，因为LeakCanary确实是影响程序运行的，尤其是heap dump操作，不过好在这件事Square已经考虑了，即在我们增加依赖时
| 1 2 3 | 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 |
其中releaseCompile和testCompile这两个的依赖明显不同于debugCompile的依赖。它们的依赖属于NOOP操作。
NOOP，即No Operation Performed，无操作指令。常用的编译器技术会检测无操作指令并出于优化的目的将无操作指令剔除。
因而，只要配置好releaseCompile和testCompile的依赖，就无需担心对外版本的性能问题了。
实践中的问题
- 如果targetSdkVersion为23，在6.0的机器上会存在问题，卡死，因为LeakCanary并没有很好支持Marshmallow运行时权限，所以始终得不到sd卡权限，进而导致卡死。
注意
- 目前LeakCanary一次只能报一个泄漏问题，如果存在内存泄漏但不是你的模块，并不能说明这个模块没有问题。建议建议将非本模块的泄漏解决之后，再进行检测。
Anroid中内存泄漏相关文章
- 避免Android中Context引起的内存泄露
- Android中Handler引起的内存泄露
- Google为何这样设计OnSharedPreferenceChangeListener
- Google IO：Android内存管理主题演讲记录
- 译文：理解Java中的弱引用
- 细话Java：”失效”的private修饰符
总结
以上是生活随笔为你收集整理的使用LeakCanary遇到的问题 就是不弹出来的全部内容，希望文章能够帮你解决所遇到的问题。
- 上一篇： 数组（全部子集）一
- 下一篇： Vcenter5.5安装部署：[2]we