美文网首页Android开发
Leakcanary(一)

Leakcanary(一)

作者: 小水neo | 来源:发表于2020-12-16 16:35 被阅读0次

    它是什么

    一句话说,就是:

    Android项目中,用于检测内存泄露,优化性能的工具

    解决了什么问题

    解决了,内存泄漏难以发现的问题。通过Leakcanary,可以轻松的找到GC中跟搜索法可达,然而不再使用的对象。
    一般情况下,这种问题是很难被发现的,原因是他的出现是不经意间的,其中,内存泄露常见的场景有:

    内存泄露常见场景

    非静态内部类的静态实例

    1. 非静态内部类会持有外部类的引用
    2. 在外部类生命周期结束后,静态实例会长期维持着外部类的引用,导致无法被gc

    多线程相关的匿名内部类\非静态内部类

    1. 匿名内部类同样也会持有外部类实例的引用,例如(AsyncTask、Tread、Runnable接口的实现类)
    2. 匿名内部类\非静态内部类中有耗时操作,在外部类生命周期结束后,仍然长时间维持着外部类的引用,导致无法被gc

    Handler内存泄露

    1. Handler定义为非静态的,即持有了外部引用
    2. Message存储到MessageQueue中,耗时较长,无法被回收

    怎样去使用它

    集成进项目之中

    1. 新版本的Leakcanary只需添加依赖,无需更改代码

      debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.5'
      

    发现内存泄露

    Leaknary 能够发现内存泄露的位置有:

    • 销毁的Activity 实例
    • 销毁的Fragment 实例
    • 销毁的View 实例
    • 销毁的ViewModel 实例
      LeakCanary可以hook到Android生命周期中,从而自动检测Activity和Fragment何时destroy,并进行垃圾收集。ObjectWatcher持有这些被destroy的对象的弱引用。通过以下方法,可以找到被Destroy的对象,例如
    AppWatcher.objectWatcher.watch(myDetachedView, "View was detached")
    

    如果运行垃圾回收,并等待5秒钟后ObjectWatcher仍未清除 ,则认定可能发生内存泄漏。LeakCanary将此记录到Logcat:


    在未被正常清楚的对象达到一定数量后,LeakCanary将其dump到存储堆,并显示通知:
    图1.LeakCanary找到了4个未被正常清楚的对象。
    注意:

    当应用程序的状态是可见的时候,默认阈值为5 ,当应用程序是不可见的时候,默认阈值为1,。如果看到Leakcanary弹出通知,然后将应用程序压至后台(例如,直接上划进入主页),则LeakCanary阈值从5更改为1,并在5秒钟后dump到存储堆。若点击按钮将强制LeakCanary立即dump到存储堆。

    打印堆中的信息

    当保留对象的数量达到阈值时,LeakCanary将Java堆dump到存储在Android文件系统上的.hprof文件中(详见LeakCanary在何处存储堆转储?)。转储堆会使应用程序停止运行一小段时间,在此期间LeakCanary会显示Toast:

    图2.LeakCanary显示了在堆放时的Toast

    分析堆中的信息

    LeakCanary.hprof使用Shark解析文件,并在该堆存储中找到保留的对象。

    图3.LeakCanary在堆存储中查找保留的对象。
    对于每个保留的对象,LeakCanary会查找引用路径,以防止对该保留的对象进行垃圾回收:至于泄露跟踪的具体内容,将在下一部分中展开:修复内存泄漏
    图4.LeakCanary计算每个保留对象的泄漏跟踪
    分析完成后,LeakCanary将显示带有摘要的通知,并在Logcat中显示结果。注意:下图将4个保留的对象归为2个不同的泄漏。LeakCanary为每个泄漏跟踪创建一个签名,并将具有相同签名的泄漏(即,由同一bug引起的泄漏)组合在一起。
    图5. 4条泄漏迹线变成2个不同的泄漏特征。
    点击弹出的通知,将提供更多详细的信息。也可以通过启动Leaks来找到该条内存泄露的详细信息
    图6.LeakCanary为安装的每个应用程序添加一个启动器图标。
    在Leaks中,每行对应一组具有相同签名的泄漏。应用程序首次出现的内存泄露类型将标记为“New”。
    图7.将4个泄漏分组为2行,每个泄漏标记对应一个
    点击泄漏将展示整个泄露的跟踪信息。
    图8. 显示了3个同一类别的内存泄露
    泄漏签名是每个级联的散列参考怀疑导致泄漏,即,每个参考与红色下划线显示:
    图9.带有3个可疑参考的泄漏跟踪。
    当泄漏跟踪以文本形式共享时,这些相同的可疑引用都带有下划线:如

    并计算出响应的signature ,例如上述的签名为

    分类内存泄露信息

    常见的内存泄露Leaknary将其分成了第三方库和程序员操作失误两种。

    1. 第三方库的泄露如下所示:(带有Library Leak)


      图10.LeakCanary发现了Library Leak。
    2. 程序员异常操作的泄露:


      图10.NewsFragment.mRootV处泄露

    如何解决内存泄露

    1. 我们在代码中能不用static变量持有context就不用,非要用就用weak引用。
    2. 对于内部类,尽量用静态内部类,这样就不会持有外部类引用。如果需要外部类引用做一些事,就手动赋给一个weak引用。
    3. 对于匿名内部类,不要图简单方便,实在不行就 写成外部类
    4. 在使用handler时,记得在activity的onDestroy()中加上remove(),有待尝试

    相关文章

      网友评论

        本文标题:Leakcanary(一)

        本文链接:https://www.haomeiwen.com/subject/fjengktx.html