不主动调用Gc 通过finalize阶段通知队列更新是否可行

[hwt83525055]

ResourcePlugin中
Leakcanary是手动调用GC去poll 引用队列，gc后需要等待一段时间， 而ResourcePlugin也是手动GC检查创建引用指向的对象，在Debug的时候频繁GC不会导致抖动吗？是否可以在创建引用阶段交由引用对象的finalize，也就是有效的系统GC【GC请求可能被忽视】的时候，再去通知mDetectExecutor添加新的Task，这样除了结果不能第一时间得到，不会有任何影响

[tys282000]

你的意思是通过finalize方法里去通知mDetectorExecutor，而不是固定时间间隔触发gc吗？
其实也行，但是选谁的finalize方法是个问题。如果自己构造一个对象的话，他被finalize了我还要再找个时机重新把它new出来方便下次继续触发它的finalize，这个时机不好找哇。

[hwt83525055]

监听activity/fragment生命周期destory的时候新建作用域仅限于方法的自己构造的对象，存储当前Object（activity/fragmnet）的弱引用，finalize的时候往循环队列添加一个check的任务，检查引用对象是否被回收，没被回收则添加任务，这样不会每次退出activity都创建一个RetryableTask ，只有发生了泄漏才进行task的执行 且 避免了GC频繁的调用

[hwt83525055]

另外请问一下为啥matrix的内存泄漏插件不监测Fragment的泄漏？我看LeakCanary的code监听了Fragment的生命周期，是有什么坑嘛吗😂

[tys282000]

监听activity/fragment生命周期destory的时候新建作用域仅限于方法的自己构造的对象，存储当前Object（activity/fragmnet）的弱引用，finalize的时候往循环队列添加一个check的任务，检查引用对象是否被回收，没被回收则添加任务，这样不会每次退出activity都创建一个RetryableTask ，只有发生了泄漏才进行task的执行 且 避免了GC频繁的调用

理论上可行，后面我看下这样改造之后还有没有其他问题哈。

不监测Fragment的泄漏是因为最开始设计方案的时候发现Fragment会通过mHost隐含持有他attach到的Activity，这样Fragment泄漏就可以通过他attach到的Activity的泄漏间接反映出来，所以最后就没单独再处理Fragment的泄漏了。

[hwt83525055]

后续有考虑添加分析hrpof文件计算泄漏引用路径吗？