android leakcanary 源码分析,LeakCanary源码分析
大家好，我是苍王。
以下是我这个系列的相关文章，有兴趣可以参考一下，可以给个喜欢或者关注我的文章。
LeakCanary，金丝雀，在组件化Gank研发的时候，近来踩了一下坑，发现其内存泄露检测的思想非常精妙。
通读在这编文章你将会学会
1.知道LeakCanary对内存泄漏检测的原理
2.如何安装了应用后，隐藏和显示应用在launcher的显示
3.如何在主线程空闲时触发任务
4.如何检测顶层Activity的生命周期状态
5.除了凭借更改样式显示在TextView，是否还有其他方法改变TextView的显示样式？
6.如果判断进程是否在后台
一.配置
可以看到release debug所引用的leakcanary的工具是不同的。
工程目录
其中leakcanary-android/leakcanary-android-no-op是依赖于leakcanary-analyzer。
而leakcanary-analyzer依赖于leakcanary-watcher
工程使用的时候，需要在自定义的Application中使用
其还使用使用了StrictMode，这里有StrictMode详细介绍
二.源码分析
RefWatcher对象的安装
构建一个AndroidRefWatcherBuilder的对象
其是继承于RefWatcherBuilder对象的
设置后台的监听
其设置的监听者是用于分析泄露结果，和发送通知
在RefWatcherBuilder中设置excluedeRefs
这里创建泄露路径的记录建造者
其最终会build方法创建一个ExcludedRefs的对象
其参数用于记录泄露对象的路径参数
使用buildAndAInstall构建出RefWatcher对象
可以看出只支持4.0 ICS以上的
这里在RefWatcherBuilder利用建造者设计模式设置参数
关于具体这些参数分析
1.watchExecutor 是线程控制器，控制activity销毁后5s再去观察泄露情况
2.debuggerControl 控制debugger的，并未编写任何执行事件
3.gcTrigger 用来触发垃圾回收的，上面的线程控制器5s后观察有泄露，不算泄露，必须垃圾回收后，再去观察一次。所以最多会观察两次。第一次是5s后观察，第二次是5s后在垃圾回收后观察。
4.heapDumpListener hprof文件解释完后，会告诉这个监听者。这个监听者就会更新状态栏
5.excludedRefs 这玩意是做额外处理的，这里面定义了一些类，如果是这些类泄露了，不会提示的。例如我就是想我的Activity泄露，你别管我，那你可以把类名加到excludedRefs 中。
这里面还要打开显示泄露的Activity
这里面DisplayLeakActivity就是显示泄露的
我们看到AndroidManifest里面组件默认enabled =false的
而且这里可以看出HeapAnalyzerService分析内存泄露的后台是新的进程
这里使用PackageManager的setComponedtEnabledSettings开启。
正是这样，才能一开始未存在泄露时隐藏leakCanary的图标。
通过ActivityRefWatcher.install启动监听泄露
通过监听application.registerActivityLifecyleCallbacks的方法来监听周期
三.泄露过程分析
通过查看监听ActivityLifecycleCallbacks的回调监听destroy的方法。
启动对前台的Activity的检测
转化为对象去观看
可以看到此时创建一个持有Activity的弱引用
通过watchExcuter执行调用
这里面会是用的是AndroidWatchExcuter的对象
其时间是5秒
我们这里可以看到其会去持有主消息队列和创建出线程的消息队列
然后调用execute的方法来，无论waitForIdle或是postWaitForIdle，都是需要切换到主队列。
然后使用MessageQueue.IdleHandler可以用来在线程空闲的时候，指定一个操作，使用IdleHandler的好处在于可以不用指定一个将来时间，只要线程空闲了，就可以执行它指定的操作。
这里是使用Retryable，是有枚举状态的，如果是RETRY的返回状态，会重新执行。
AndroidWatchExcuter会调用ensureGone的方法
这里会需要试着移除弱引用，
判断队列里面是是否有对应Activity的弱引用对象
然后试着在retainedKeys集合里面试着移除
再次判断是否在集合中是否还包含引用对象，如果不包含就说明没有泄露
这里继续会走GC内存回收的流程
RunTime.getRunTime().gc()触发系统gc操作
enqueueReference通过强制限制100毫秒的时间给gc
System.runFinalization()是强制调用已经失去引用的对象的finalize方法
然后再进行弱引用对象移除
在判断如果依然没被移除，会调用heapDumper.dumpHeap的方法
这里泄露目录的定义
默认最多七个Dump文件
这里调用dumpHeap会创建文件.hrof的文件
newHeapDumpFile来创建.hrof文件
这里使用Debug.dumpHprofData这个类，是heap堆的快照，可以获知程序的哪些部分正在使用大部分的内存
然后使用heapdumpListener.analyze的方法分析堆内存
这里heapdumpListener使用的是AndroidRefWatcherBuilder里面的
进一步看到是使用HeapAnalyzerService.runAnalysis的方法
这里是启动一个其自身作为一个IntentService，
启动IntentService就会直接运行onHanldeIntent的方法，运行完就会释放回收掉Service
这里HeapAnalyzer会使用checkForLeak的方法来分析内存泄露结果
然后回调结果给上层的DisplayLeakService来处理结果
会调用findLeakTrace的侦测
这里建立检测泄露节点和返回泄露对象的详细信息。
这里最终会调用到squaredup的haha库，专用于分析Android的堆分析
我们看看将结果回调给Service的时候，会启动Service，然后将相应的result参数传递过去
我们看到IntentService，会调用onHeapAnalyzed的方法
DisplayLeakService被启动后读取相应的参数
可以看到设置了一些显示的参数后，会提示Notification和处理堆
LeackCanaryInternals发送Notification到状态栏
其通知的pendingIntent实际跳转到DisplayLeakActivity
这里提供了最终调用的方法给用户自己处理。
关于DisplayLeakActivity就是要将AnalysisResult展示出来。
其使用LIstView显示路径的时候，TextView的解析是使用html.forHtml来解析HTML文本拼接
我们可以看到其使用elementToHtmlString来拼接Html文本
然后回到一开始的Application装载LeakCanary，
其使用isInAnalyzerProcess分析应用函数
判断是否在后台进程
然后这里LeakCanary封装了一个非常好的判断是否后台进程的方法。
总结
显然leakCanary的设计非常精妙，可以非常容易检测的大部分内存泄漏了。
但是暂时发现的缺陷
1.如果首页的Activity一直不销毁(onDestroy)那么将一直无法检测到首页的调用栈的内存泄漏
2.无法检测Service产生的内存泄漏。
这节就到这里，
下一节将会更精彩，敬请期待！！！
群号是316556016，也可以扫码进群。我在这里期待你们的加入！！！