Android 内存泄漏检测开源库LeakCanary 研究

本文主要是介绍Android 内存泄漏检测开源库LeakCanary 研究，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1. Android 内存空间不足会引发的问题

• PSS : Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）PSS相对于RSS计算共享库内存大小是按比例的。N个进程共享，该库对PSS大小的贡献只有1/N
• VSS : Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）,即单个进程全部可访问的地址空间，其大小可能包括还尚未在内存中驻留的部分。对于确定单个进程实际内存使用大小，VSS用处不大。
• RSS : Resident Set Size 实际使用物理内存（包含共享库占用的内存）,即单个进程实际占用的内存大小，RSS不太准确的地方在于它包括该进程所使用共享库全部内存大小。对于一个共享库，可能被多个进程使用，实际该共享库只会被装入内存一次。
• USS : Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）即单个进程私有的内存大小，即该进程独占的内存部分。USS揭示了运行一个特定进程在的真实内存增量大小。如果进程终止，USS就是实际被返还给系统的内存大小。
• 一般情况下有：VSS >= RSS >= PSS >= USS。

1.1 异常

内存造成的第一个问题是异常。异常包括 OOM、内存分配失败这些崩溃，也包括因为整体内存不足导致应用被杀死、设备重启等问题。

1.2 卡顿

APP: 内存造成的第二个问题是卡顿。Java 内存不足会导致频繁 GC，GC 会 stop the world, 严重的会导致掉帧，卡顿。

系统层面：除了频繁 GC 造成卡顿之外，物理内存不足时系统会触发 low memory killer 机制，系统负载过高是造成卡顿的另外一个原因。

android 60ps, 16ms 绘制一帧画面，卡顿会延长这个时间

这个问题在 Dalvik 虚拟机会更加明显。而 ART 虚拟机在内存管理跟回收策略上都做大量优化，内存分配和 GC 效率相比提升了 5～10 倍。如果想具体测试 GC 的性能，例如暂停挂起时间、总耗时、GC 吞吐量，我们可以通过发送 SIGQUIT 信号获得 ANR 日志。

• adb shell kill -S QUIT PID
• adb pull /data/anr/traces.txt

它包含一些 ANR 转储信息以及 GC 的详细性能信息。

• sticky concurrent mark sweep paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms // GC 暂停时间
  Total time spent in GC: 502.251ms // GC 总耗时
  Mean GC size throughput: 92MB/s // GC 吞吐量
  Mean GC object throughput: 1.54702e+06 objects/s

1.3 从 Java 堆内存超限这个问题开始

主要有两类问题：

• 堆内存单次分配过大多次分配累计过大。

  • 触发这类问题的原因有数据异常导致单次内存分配过大超限，也有一些是 StringBuilder 拼接累计大小过大导致等等。这类问题的解决思路比较简单，问题就在当前的堆栈。

• 堆内存累积分配触顶。

  • 这类问题的问题堆栈会比较分散，在任何内存分配的场景上都有可能会被触发，那些高频的内存分配节点发生的概率会更高，比如 Bitmap 分配内存。这类 OOM 的根本原因是内存累积占用过多，而当前的堆栈只是压死骆驼的最后一根稻草，并不是问题的根本所在。所以这类问题我们需要分析整体的内存分配情况，从中找到不合理的内存使用（比如内存泄露、大对象、过多小对象、大图等）。

• Facebook 有一个叫 device-year-class 的开源库，它会用年份来区分设备的性能
  

2. 内存优化着手点

一个原则： 用时分配，及时释放

adb shell dumpsys meminfo <package_name|pid> [-d]

2.1 检测 RAM usage

• 使用状况：official document: Inspect your app’s memory usage with Memory Profiler

2.2 进程

• 减少应用启动的进程数、减少常驻进程、有节操的保活，对低端机内存优化非常重要

不适用于我们 app

2.3 安装包大小

• 安装包中的代码、资源、图片以及 so 库的体积，跟它们占用的内存有很大的关系。一个 80MB 的应用很难在 512MB 内存的手机上流畅运行。这种情况我们需要考虑针对低端机用户推出 4MB 的轻量版本，例如 今日头条极速版都是这个思路

2.4 Bitmap 优化

统一的图片库

2.5 内存泄漏

内存泄漏简单来说就是没有回收不再使用的内存

内存泄漏主要分两种情况，一种是同一个对象泄漏，还有一种情况更加糟糕，就是每次都会泄漏新的对象，可能会出现几百上千个无用的对象。

很多内存泄漏都是框架设计不合理所导致，各种各样的单例满天飞，View、Activity 被生命周期远远大于它的对象引用（eg: handler）。

优秀的框架设计可以减少甚至避免程序员犯错，当然这不是一件容易的事情，所以我们还需要对内存泄漏建立持续的监控

2.5.1 Java 内存泄漏

eg: LeakCanary 自动化检测方案，可以做到 Activity、Fragment、View、ViewModel 和 Service 的泄漏检测。在开发过程，我们希望出现泄漏时可以弹出对话框，让开发者更加容易去发现和解决问题。

我们首先要问清楚自己几个问题，比如我们要优化到什么目标、内存对我们造成了多少异常和卡顿。只有在明确了应用的现状和优化目标后，我们才能去进行下一步的操作。

• 造成了多少异常和卡顿：应用性能接入框架: Tencent/matrix

• Android 内存泄漏检测框架：LeakCanary

• Android 线上内存检测：KOOM

3. Android 内存监控相关的开源库

3.1 开源库简介

• bytedance Rhea – 全能型性能分析工具
  • 优点：
    • 1、使用灵活，不依赖 PC 抓取脚本，同时支持线上线下多种模式和配置开关；
    • 2、支持采集和追踪包括不限层级 ATrace 函数耗时插桩、等锁信息、I/O 信息以及 Binder 耗时等在内的多种信息；
    • 3、兼容性高，支持 API 16~30 全机型的 trace 抓取；
    • 4、零侵入代码，通过 gradle 完成插件全部配置，无任何代码直接调用。
  • 缺点：native 支持不足, 计划开源但暂未开源

---

• bytedance MemoryLeakDetector – native 内存泄漏监控工具
  • 接入简单、监控范围广、性能优良、 稳定性好的特点

---

• bytedance Tailor – 通用内存快照裁剪压缩工具
  • 通过它可以在异常时直接dump出一个迷你内存快照。快照中没 有任何敏感信息，更重要的是文件非常小的同时数据也相对完整，非常适合离线分析OOM及其他类型异常的调查定位

---

• KOOM——高性能线上内存监控方案
  • 利用Copy-on-write机制fork子进程dump
  • 优点：速度快，不会阻塞主线程；文件极小，只是个json文件
    • 内存监控组件 定时采集内存资源占用情况，超过阈值触发内存镜像采集，决定镜像dump与分析时机，关键代码参考Monitor.java，主要针对 OOM 问题
    • 内存镜像采集组件 高性能内存镜像采集组件，包含fork dump和strip dump两个部分，关键代码参考HeapDumper.java，Java 内存部分在 LeakCanary 的基础上进行了大量优化，解决了线上内存监控的性能问题，在不影响用户体验的前提下线上采集内存镜像并解析
    • 内存镜像解析组件 高性能内存镜像解析组件，基于shark解析器定制优化，泄露判定关键代码参考LeakDetector.java ，解决的是 解决dump过程中app长时间冻结的问题

---

3.2 内存泄漏检测方案对比

• 内存泄漏方案比较
• 抖音 Android 性能优化系列：Java 内存优化篇

4. LeakCanary 原理

• GC 回收机制

• LeakCanary 2.7 原理分析

• 深入分析 Handler 内存泄露

5. 项目应用

• Detecting memory leaks in Android applications
• Detecting memory leaks in Android applications – 中文版

---

• DialogFragment你可能踩过或将要踩的坑

---

• 内存泄漏的8个Case
• Android Navigation 遇坑记 - 真实项目经历

补充链接

• Android GC 那点事
• Android GC原理探究

这篇关于Android 内存泄漏检测开源库LeakCanary 研究的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---