跳到内容
🤔 文档有问题? 报告编辑

介绍

基础部分介绍了 LeakCanary 如何工作以及如何使用它来检测和修复内存泄漏。本文档旨在帮助所有级别的开发者,因此请随时报告任何令人困惑的部分。

什么是内存泄漏?

在基于 Java 的运行时环境中,内存泄漏是一种编程错误,它导致应用程序持有一个不再需要的对象的引用。因此,为该对象分配的内存无法被回收。

例如,一个 Android 的 Activity 实例在其 onDestroy() 方法被调用后就不再需要了,但将该实例的引用存储在静态字段中会阻止它被垃圾回收。

内存泄漏的常见原因

大多数内存泄漏是由与对象生命周期相关的错误引起的。以下是一些常见的 Android 错误

  • 在将 Fragment 实例添加到返回栈时,未在 Fragment.onDestroyView() 中清除该 Fragment 的视图字段(更多详情请参阅 此 StackOverflow 回答)。
  • 将一个 Activity 实例作为 Context 字段存储在因配置更改而存活的对象中。
  • 注册一个引用带有生命周期的对象的监听器、广播接收器或 RxJava 订阅,并在生命周期结束时忘记解除注册。

我为什么应该使用 LeakCanary?

内存泄漏在 Android 应用中非常常见。随着小的内存泄漏累积,内存使用量会增加,垃圾收集器 (GC) 运行更频繁并消耗更多 CPU,导致卡顿、UI 冻结和 应用程序无响应 (ANR) 报告,最终导致 内存溢出错误 (OOME) 崩溃。LeakCanary 将帮助你在开发过程中找到并修复这些内存泄漏。当 Square 工程师首次在 Square Point Of Sale 应用中启用 LeakCanary 时,他们成功修复了多个泄漏,并将 OOM 崩溃率降低了 94%

信息

你的崩溃报告工具可能无法正确报告 OOME。当由于内存泄漏累积导致内存不足时,OOM 可能从应用程序代码的任何地方抛出,这意味着每个 OOM 都有不同的堆栈跟踪。因此,OOM 不会被报告为一个包含 1000 次崩溃的崩溃条目,而是被报告为 1000 个不同的崩溃,并隐藏在低频崩溃的长尾中。

接下来是什么?了解 LeakCanary 如何工作