--- theme: smartblue highlight: androidstudio --- 本文已参与「新人创作礼」活动，一起开启掘金创作之路。 **LeakCanary 系列文章：** [LeakCanary 2.0（一）工作原理及使用详解](https://juejin.cn/post/7121320019878903816) [LeakCanary 2.0（二）源码分析及总结](https://juejin.cn/post/7216227563013226553) # 一 LeakCanary 简介 LeakCanary 是一款 Android 平台上进行内存泄漏检测的工具，由大名鼎鼎的 square 公司制作并开源( [square](https://github.com/square/leakcanary) [/](https://github.com/square/leakcanary) [leakcanary](https://github.com/square/leakcanary) )，能够帮助开发人员显著减少 App 中 **Application Not Responding** 问题和 **OutOfMemoryError** 崩溃问题。目前通常应用在 App 开发测试阶段，主打一个提前检测提前修复。

## **1.1 内存泄漏简介** 在 Android 开发中，内存泄漏是一种编程错误，它表现为应用程序保留对不再需要的对象的引用。为该对象分配的内存无法回收，最终导致 OutOfMemoryError (OOM) 崩溃。内存泄漏详细介绍可参考： [Android 内存泄漏总结](https://juejin.cn/post/7120500283469365261) ## 1.2 LeakCanary 优缺点 **优点** * 针对 Android Activity 组件完全自动化的内存泄漏检查 * 可定制一些行为（`dump` 文件和 leak trace 对象的数量、分析结果的自定义处理等） * 集成过程简单并且使用成本很低 * 友好的界面展示和通知 **缺点** * 不适用于线上监测 * 无法检测申请大容量内存导致的 OOM 问题、Bitmap 内存未释放问题 ## 1.3 LeakCanary 工作原理安装 LeakCanary 后，它会自动检测并报告内存泄漏，分为以下 4 个步骤： 1. 检测未被 GC 回收的对象 2. 转储堆 3. 分析堆 4. 对泄漏进行分类 ### 1.3.1 检测未被 GC 回收的对象 LeakCanary Hook 到 **Android lifecycle** 以自动检测 Activitis 和 Fragments 何时被 Destroy 并且被 GC 回收。这些被 Destroy 的对象被传递给一个 `ObjectWatcher`，它持有对它们的弱引用。LeakCanary 能够自动检测以下对象的泄漏： * 被销毁的 `Activity`实例 * 被销毁的 `Fragment`实例 * 被销毁的 `fragment View`实例 * 被清除 `ViewModel`实例可以查看任意一个不再使用的对象，例如 detached view 或 destroyed presenter： ```kotlin AppWatcher.objectWatcher.watch(myDetachedView, "View was detached") ``` **如果在等待 5 秒**并运行 GC 回收后，`ObjectWatcher`持有的弱引用没有被清除，则该对象被认为是**未被回收**的，并且可能会产生泄漏。LeakCanary 就会将这些对象记录到 Logcat： ```kotlin D LeakCanary: Watching instance of com.example.leakcanary.MainActivity (Activity received Activity#onDestroy() callback) ... 5 seconds later ... D LeakCanary: Scheduling check for retained objects because found new object retained ``` LeakCanary 在转储堆之前等待未被回收对象(retained objects)的计数达到阈值，并显示具有最新计数的通知。

```java D LeakCanary: Rescheduling check for retained objects in 2000ms because found only 4 retained objects (< 5 while app visible) ``` > App **处于前台时**默认阈值为 **5 个 retained objects**，App **处于后台时**默认阈值为 **1 个 retained object**。如果看到 **retained objects**通知，然后将 App 置于后台（例如通过按下 Home 按钮），则阈值从 5 变为 1，并且 LeakCanary 会在 5 秒内转储堆。点击通知会强制 LeakCanary 立即转储堆。 ### 1.3.2 转储堆当未被回收对象的数量达到阈值时，LeakCanary 将 Java 堆 dump 到 Android 文件系统中的`.hprof`文件（堆转储）中（请参阅 [LeakCanary 在哪里存储堆转储？](https://square.github.io/leakcanary/faq/#where-does-leakcanary-store-heap-dumps) ）。转储堆会在短时间内冻结应用程序，在此期间 LeakCanary 显示以下 toast：

### 1.3.3 分析堆 LeakCanary 使用 Shark 来解析 `.hprof` 文件并在该堆转储中定位未被回收的对象。

对于每个未被回收对象，LeakCanary 会找到阻止该对象被 GC 垃圾回收的引用路径：它的 **leak trace**。

分析完成后，LeakCanary 会显示一个带有摘要的**通知，并将结果打印在 Logcat**中。请注意下面 **4 个未被回收的对象**是如何被分组为**两种不同的泄漏项**。LeakCanary **为每个** **leak trace 创建一个签名**，并将具有相同签名的泄漏项划分在一组，即由相同错误引起的泄漏。

```java ==================================== HEAP ANALYSIS RESULT ==================================== 2 APPLICATION LEAKS Displaying only 1 leak trace out of 2 with the same signature Signature: ce9dee3a1feb859fd3b3a9ff51e3ddfd8efbc6 ┬─── │ GC Root: Local variable in native code │ ... ``` 点击通知会启动一个提供更多详细信息的 Activity。稍后通过点击 LeakCanary 启动器图标再次返回它：

每行对应一**组具有相同签名的泄漏项**。LeakCanary 在应用程序第一次使用该签名触发泄漏时将一行标记为 `New`。

点击泄漏项以打开其 **leak trace**显示详情。可以通过下拉菜单在不同的泄漏对象间切换。

**泄漏签名**是导致泄漏的**每个引用的串联哈希**，即每个引用都显示有红色下划线：

当 **leak trace**以文本形式共享时，这些相同的可疑引用会带有下划线`~~~` ： ```java ... │ ├─ com.example.leakcanary.LeakingSingleton class │ Leaking: NO (a class is never leaking) │ ↓ static LeakingSingleton.leakedViews │ ~~~~~~~~~~~ ├─ java.util.ArrayList instance │ Leaking: UNKNOWN │ ↓ ArrayList.elementData │ ~~~~~~~~~~~ ├─ java.lang.Object[] array │ Leaking: UNKNOWN │ ↓ Object[].[0] │ ~~~ ├─ android.widget.TextView instance │ Leaking: YES (View.mContext references a destroyed activity) ... ``` 在上面示例中，泄漏签名的计算方式为： ```kotlin val leakSignature = sha1Hash( "com.example.leakcanary.LeakingSingleton.leakedView" + "java.util.ArrayList.elementData" + "java.lang.Object[].[x]" ) println(leakSignature) // dbfa277d7e5624792e8b60bc950cd164190a11aa ``` ### 1.3.4 对泄漏进行分类 LeakCanary 将它在 App 中发现的泄漏分为两类：**Application Leaks** 和 **Library Leaks**。**Library Leaks**是 App 中依赖的三方代码库中的已知错误引起的泄漏。此泄漏会直接影响到 App 的表现，但开发者无法直接在 App 中修复它，因此 LeakCanary 将其分离出来。这两个类别在 **Logcat**中打印的结果中是分开的： ```java ==================================== HEAP ANALYSIS RESULT ==================================== 0 APPLICATION LEAKS ==================================== 1 LIBRARY LEAK ... ┬─── │ GC Root: Local variable in native code │ ... ``` LeakCanary 在其泄漏列表中标记为 `Library Leak`：

LeakCanary 附带一个已知泄漏的数据库，它通过对引用名称的模式匹配来识别它。例如 ```java Leak pattern: instance field android.app.Activity$1#this$0 Description: Android Q added a new IRequestFinishCallback$Stub class [...] ┬─── │ GC Root: Global variable in native code │ ├─ android.app.Activity$1 instance │ Leaking: UNKNOWN │ Anonymous subclass of android.app.IRequestFinishCallback$Stub │ ↓ Activity$1.this$0 │ ~~~~~~ ╰→ com.example.MainActivity instance ``` > 可以在 [AndroidReferenceMatchers](https://github.com/square/leakcanary/blob/main/shark-android/src/main/java/shark/AndroidReferenceMatchers.kt#L49) 类中查看已知泄漏的完整列表 # 二 LeakCanary 使用 ## 2.1 引入依赖首先，需要将 `leakcanary-android` 依赖添加到项目的 app’s `build.gradle` 中: ```java dependencies { // debugImplementation because LeakCanary should only run in debug builds. debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.9.1' } ``` 因为 LeakCanary 有以下问题，所以通常只会使用在线下 debug 阶段，release 版本中不会引入 LeakCanary。 * 每次内存泄漏以后，都会生成并解析 hprof 文件，容易引起手机卡顿等问题 * 多次调用 GC，可能会对线上性能产生影响 * hprof 文件较大，信息回捞成问题然后，可过滤 Logcat 中的标签来确认 LeakCanary 在启动时是否成功运行： ```java D LeakCanary: LeakCanary is running and ready to detect leaks ``` ## 2.2 配置 LeakCanary 因为 LeakCanary 2.0 版本后完全使用 Kotlin 重写，只需引入依赖，不需要初始化代码，就能执行内存泄漏检测。当然也可以在自定义 Application 的 `onCreate`方法对 LeakCanary 进行一些自定义配置： ```kotlin class LeakApplication: Application() { override fun onCreate() { super.onCreate() leakCanaryConfig() } private fun leakCanaryConfig() { //App 处于前台时检测保留对象的阈值，默认是 5 LeakCanary.config = LeakCanary.config.copy(retainedVisibleThreshold = 3) //自定义要检测的保留对象类型，默认监测 Activity，Fragment，FragmentViews 和 ViewModels AppWatcher.config= AppWatcher.config.copy(watchFragmentViews = false) //隐藏泄漏显示活动启动器图标，默认为 true LeakCanary.showLeakDisplayActivityLauncherIcon(false) } } ``` ## 2.3 检测内存泄漏以下，举一例非静态内部类导致的内存泄漏，如何使用 LeakCanary 监控其异常，代码如下所示： ```kotlin class LeakTestActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_leak_test) val leakThread = LeakThread() leakThread.start() } // LeakThread 定义为 LeakTestActivity 的内部类 inner class LeakThread : Thread() { override fun run() { super.run() try { //线程内耗时操作 sleep(6 * 60 * 1000) } catch (e: InterruptedException) { e.printStackTrace() } } } } ``` LeakTestActivity 存在内存泄漏，原因就是非静态内部类 LeakThread 持有外部类 LeakTestActivity 的引用，LeakThread 中做了耗时操作，导致 LeakTestActivity 无法被释放。运行 App 程序，这时会在 Launch 界面生成一个名为 `Leaks` 的应用图标。接下来跳转到 App 的 LeakTestActivity 页面并不断地切换横竖屏，4 次切换后屏幕会弹出提示：`“Dumping memory app will freeze.Brrrr.”`。再稍等片刻，内存泄漏信息就会通过 Notification 展示出来，如下图所示

Notification 中提示了 LeakTestActivity 发生了内存泄漏，有 4 个对象未被回收。点击 Notification 就可以进入内存泄漏详细页，除此之外也可以通过 Leaks 应用的列表界面进入，列表界面如下图所示。

内存泄漏详细页如下图所示：

整个详情就是一个引用链：LeakTestActivity 的内部类 LeakThread 引用了 LeakThread 的 **this\$0**，**this\$0** 的含义就是内部类自动保留的一个指向所在外部类的引用，而这个外部类就是详情最后一行所给出的 LeakTestActivity 的实例，这将会导致 LeakTestActivity 无法被 GC，从而产生内存泄漏。解决方法就是将 LeakThread 改为静态内部类。再次运行程序 LeakThread 就不会给出内存泄漏的提示了。 ```kotlin ... companion object { class LeakThread : Thread() { override fun run() { super.run() try { sleep(6 * 60 * 1000) } catch (e: InterruptedException) { e.printStackTrace() } } } } ``` # 参考文档 [LeakCanary Introduction](https://square.github.io/leakcanary/fundamentals/) [Android内存优化（六）LeakCanary使用详解](https://blog.csdn.net/itachi85/article/details/77826112)