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

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

1. Android 内存空间不足会引发的问题
- 1.1 异常
- 1.2 卡顿
- 1.3 从 Java 堆内存超限这个问题开始
2. 内存优化着手点
- 2.1 检测 RAM usage
- 2.2 进程
- 2.3 安装包大小
- 2.4 Bitmap 优化
- 2.5 内存泄漏
- - 2.5.1 Java 内存泄漏
3. Android 内存监控相关的开源库
- 3.1 开源库简介
- 3.2 内存泄漏检测方案对比
4. LeakCanary 原理
5. 项目应用
补充链接

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长时间冻结的问题