LeakCanary github地址:LeakCanary
要使用 LeakCanary，请将leakcanary-android依赖项添加到应用程序的build.gradle文件中：
dependencies {
// debugImplementation because LeakCanary should only run in debug builds.
debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.8.1'
}在项目中加入LeakCanary之后就可以检测项目的内存泄露了，LeakCanary通过过滤 Logcat 中的标签来确认 LeakCanary 在启动时运行
LeakCanary 的工作原理
安装 LeakCanary 后，它会自动检测并报告内存泄漏，分 4 个步骤：
- 检测保留对象。
- 转储堆。
- 分析堆。
- 对泄漏进行分类。
1.检测保留对象?
LeakCanary 挂钩到 Android 生命周期，以自动检测活动和片段何时被销毁并且应该被垃圾收集。这些被破坏的对象被传递给一个ObjectWatcher，它持有对它们的弱引用。LeakCanary 自动检测以下对象的泄漏：
- 销毁的
Activity实例 - 销毁的
Fragment实例 - 被破坏的片段
View实例 - 清除
ViewModel实例
您可以查看不再需要的任何对象，例如分离的视图或销毁的演示者：
AppWatcher.objectWatcher.watch(myDetachedView, "View was detached")
如果在等待 5 秒并运行垃圾回收后，持有的弱引用ObjectWatcher没有被清除，则被监视的对象被认为是保留的，并且可能泄漏。LeakCanary 将其记录到 Logcat：
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 在转储堆之前等待保留对象的计数达到阈值，并显示具有最新计数的通知。
?图 1.?LeakCanary 发现了 4 个保留对象。
D LeakCanary: Rescheduling check for retained objects in 2000ms because found
only 4 retained objects (< 5 while app visible)
信息
应用可见时默认阈值为5 个保留对象，应用不可见时默认阈值为1 个保留对象。如果您看到保留对象通知，然后将应用程序置于后台（例如通过按下 Home 按钮），则阈值从 5 变为 1，并且 LeakCanary 会在 5 秒内转储堆。点击通知会强制 LeakCanary 立即转储堆。
2. 转储堆?
当保留对象的数量达到阈值时，LeakCanary 将 Java 堆转储到存储在 Android 文件系统上的.hprof文件（堆转储）中（请参阅LeakCanary 在哪里存储堆转储？）。转储堆会在短时间内冻结应用程序，在此期间 LeakCanary 显示以下 toast：
?图 2.?LeakCanary在转储堆时显示吐司。
3. 分析堆?
LeakCanary.hprof使用Shark解析文件并在该堆转储中定位保留的对象。
?图 3.?LeakCanary 在堆转储中找到保留对象。
对于每个保留对象，LeakCanary 会找到阻止该保留对象被垃圾收集的引用路径：它的泄漏跟踪。您将在下一节中学习分析泄漏跟踪：修复内存泄漏。
?图 4.?LeakCanary 计算每个保留对象的泄漏跟踪。
分析完成后，LeakCanary 会显示一个带有摘要的通知，并将结果打印在Logcat中。请注意下面4 个保留对象如何分组为2 个不同的泄漏。LeakCanary为每个泄漏跟踪创建一个签名，并将具有相同签名的泄漏分组在一起，即由相同错误引起的泄漏。
?图 5.?4 个泄漏痕迹变成了 2 个不同的泄漏特征。
====================================
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
│
...
点击通知会启动一个提供更多详细信息的活动。稍后通过点击 LeakCanary 启动器图标再次返回它：
?图 6.?LeakCanary 为其安装的每个应用程序添加一个启动器图标。
每行对应一组具有相同签名的泄漏。LeakCanary在应用程序第一次使用该签名触发泄漏时将一行标记为新。
?图 7.?4 个泄漏分组为 2 行，一个用于每个不同的泄漏签名。
点击泄漏以打开带有泄漏痕迹的屏幕。您可以通过下拉菜单在保留对象及其泄漏跟踪之间切换。
?图 8.显示按共同泄漏特征分组的 3 个泄漏的屏幕。
泄漏签名是每个被怀疑导致泄漏的引用的串联哈希，即每个引用都显示有红色下划线：
?图 9.带有 3 个可疑引用的泄漏跟踪。
~~~当泄漏跟踪以文本形式共享时，这些相同的可疑引用会带有下划线：
...
│
├─ 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)
...
在上面的示例中，泄漏的签名将计算为：
val leakSignature = sha1Hash(
"com.example.leakcanary.LeakingSingleton.leakedView" +
"java.util.ArrayList.elementData" +
"java.lang.Object[].[x]"
)
println(leakSignature)
// dbfa277d7e5624792e8b60bc950cd164190a11aa
4. 对泄漏进行分类?
LeakCanary 将它在您的应用中发现的泄漏分为两类：应用程序泄漏和库泄漏。库泄漏是由您无法控制的 3?rd方代码中的已知错误引起的泄漏。此泄漏正在影响您的应用程序，但不幸的是，修复它可能不在您的控制范围内，因此 LeakCanary 将其分离出来。
这两个类别在Logcat中打印的结果中是分开的：
====================================
HEAP ANALYSIS RESULT
====================================
0 APPLICATION LEAKS
====================================
1 LIBRARY LEAK
...
┬───
│ GC Root: Local variable in native code
│
...
LeakCanary 在其泄漏列表中将一行标记为库泄漏：
?图 10.?LeakCanary 发现了库泄漏。
LeakCanary 附带一个已知泄漏的数据库，它通过对引用名称的模式匹配来识别它。例如：
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
内存泄漏是一种编程错误，它会导致应用程序保留对不再需要的对象的引用。在代码的某处，有一个应该被清除但没有被清除的引用。
请按照以下 4 个步骤修复内存泄漏：
- 找到泄漏痕迹。
- 缩小可疑参考范围。
- 找到导致泄漏的参考。
- 修复泄漏。
LeakCanary 帮助您完成前两个步骤。最后两个步骤由您决定！
1.查找泄漏痕迹?
泄漏跟踪是从垃圾收集根到保留对象的最佳强引用路径的较短名称，即在内存中持有对象的引用路径，因此防止它被垃圾收集。
例如，让我们在静态字段中存储一个辅助单例：
class Helper {
}
class Utils {
public static Helper helper = new Helper();
}
让我们告诉 LeakCanary 单例实例应该被垃圾回收：
AppWatcher.objectWatcher.watch(Utils.helper)
该单例的泄漏跟踪如下所示：
┬───
│ GC Root: Local variable in native code
│
├─ dalvik.system.PathClassLoader instance
│ ↓ PathClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
│ ↓ Object[].[43]
├─ com.example.Utils class
│ ↓ static Utils.helper
╰→ java.example.Helper
让我们分解吧！在顶部，PathClassLoader实例由垃圾收集 (GC) 根持有，更具体地说，是本机代码中的局部变量。GC 根是始终可访问的特殊对象，即它们不能被垃圾回收。有 4 种主要类型的 GC 根：
- 局部变量，属于线程的栈。
- 活动 Java 线程的实例。
- 系统类，永远不会卸载。
- 本机引用，由本机代码控制。
┬───
│ GC Root: Local variable in native code
│
├─ dalvik.system.PathClassLoader instance
以 开头的行├─表示 Java 对象（类、对象数组或实例），以 开头的行│ ↓表示对下一行 Java 对象的引用。
PathClassLoader有一个runtimeInternalObjects字段是对以下数组的引用Object：
├─ dalvik.system.PathClassLoader instance
│ ↓ PathClassLoader.runtimeInternalObjects
├─ java.lang.Object[] array
该数组中位置 43 处的元素是对该类Object的引用。Utils
├─ java.lang.Object[] array
│ ↓ Object[].[43]
├─ com.example.Utils class
以 开头的行╰→表示泄漏对象，即传递给AppWatcher.objectWatcher.watch()的对象。
该类Utils有一个静态helper字段，它是对泄漏对象的引用，它是 Helper 单例实例：
├─ com.example.Utils class
│ ↓ static Utils.helper
╰→ java.example.Helper instance
2. 缩小可疑参考范围?
泄漏跟踪是引用的路径。最初，该路径中的所有引用都被怀疑导致泄漏，但 LeakCanary 可以自动缩小可疑引用的范围。要了解这意味着什么，让我们手动完成该过程。
这是一个糟糕的 Android 代码示例：
class ExampleApplication : Application() {
val leakedViews = mutableListOf<View>()
}
class MainActivity : Activity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.main_activity)
val textView = findViewById<View>(R.id.helper_text)
val app = application as ExampleApplication
// This creates a leak, What a Terrible Failure!
app.leakedViews.add(textView)
}
}
LeakCanary 会生成如下所示的泄漏跟踪：
┬───
│ GC Root: System class
│
├─ android.provider.FontsContract class
│ ↓ static FontsContract.sContext
├─ com.example.leakcanary.ExampleApplication instance
│ ↓ ExampleApplication.leakedViews
├─ java.util.ArrayList instance
│ ↓ ArrayList.elementData
├─ java.lang.Object[] array
│ ↓ Object[].[0]
├─ android.widget.TextView instance
│ ↓ TextView.mContext
╰→ com.example.leakcanary.MainActivity instance
以下是如何读取泄漏痕迹：
该类
FontsContract是一个系统类（参见参考资料GC Root: System class），并且有一个sContext静态字段，该字段引用一个ExampleApplication实例，该实例具有一个leakedViews字段，该字段引用一个ArrayList实例，该实例引用一个数组（支持数组列表实现的数组），该数组具有一个引用 a 的元素，该元素TextView具有一个mContext字段它引用了MainActivity.
LeakCanary 使用 ~ ~ 下划线突出显示所有可能导致此泄漏的引用。最初，所有引用都是可疑的：
┬───
│ GC Root: System class
│
├─ android.provider.FontsContract class
│ ↓ static FontsContract.sContext
│ ~~~~~~~~
├─ com.example.leakcanary.ExampleApplication instance
│ Leaking: NO (Application is a singleton)
│ ↓ ExampleApplication.leakedViews
│ ~~~~~~~~~~~
├─ java.util.ArrayList instance
│ ↓ ArrayList.elementData
│ ~~~~~~~~~~~
├─ java.lang.Object[] array
│ ↓ Object[].[0]
│ ~~~
├─ android.widget.TextView instance
│ ↓ TextView.mContext
│ ~~~~~~~~
╰→ com.example.leakcanary.MainActivity instance
然后，LeakCanary对泄漏跟踪中对象的状态和生命周期进行推断。在 Android 应用程序中，Application实例是一个永远不会被垃圾回收的单例，因此它永远不会泄漏 (?Leaking: NO (Application is a singleton))。由此，LeakCanary 得出结论，泄漏不是由FontsContract.sContext（删除相应的~~~）引起的。这是更新的泄漏跟踪：
┬───
│ GC Root: System class
│
├─ android.provider.FontsContract class
│ ↓ static FontsContract.sContext
├─ com.example.leakcanary.ExampleApplication instance
│ Leaking: NO (Application is a singleton)
│ ↓ ExampleApplication.leakedViews
│ ~~~~~~~~~~~
├─ java.util.ArrayList instance
│ ↓ ArrayList.elementData
│ ~~~~~~~~~~~
├─ java.lang.Object[] array
│ ↓ Object[].[0]
│ ~~~
├─ android.widget.TextView instance
│ ↓ TextView.mContext
│ ~~~~~~~~
╰→ com.example.leakcanary.MainActivity instance
实例通过它的字段TextView引用被破坏的实例。视图不应在其上下文的生命周期中存活，因此 LeakCanary 知道此实例正在泄漏 (?)，因此泄漏不是由(删除对应的) 引起的。这是更新的泄漏跟踪：MainActivitymContextTextViewLeaking: YES (View.mContext references a destroyed activity)TextView.mContext~~~
┬───
│ GC Root: System class
│
├─ android.provider.FontsContract class
│ ↓ static FontsContract.sContext
├─ com.example.leakcanary.ExampleApplication instance
│ Leaking: NO (Application is a singleton)
│ ↓ ExampleApplication.leakedViews
│ ~~~~~~~~~~~
├─ java.util.ArrayList instance
│ ↓ ArrayList.elementData
│ ~~~~~~~~~~~
├─ java.lang.Object[] array
│ ↓ Object[].[0]
│ ~~~
├─ android.widget.TextView instance
│ Leaking: YES (View.mContext references a destroyed activity)
│ ↓ TextView.mContext
╰→ com.example.leakcanary.MainActivity instance
总而言之，LeakCanary 检查泄漏跟踪中对象的状态以确定这些对象是否正在泄漏 (?Leaking: YESvs?Leaking: NO)，并利用该信息来缩小可疑引用的范围。您可以提供自定义ObjectInspector实现来改进 LeakCanary 在您的代码库中的工作方式（请参阅识别泄漏对象和标记对象）。
3.找到导致泄漏的参考?
在前面的示例中，LeakCanary 缩小了对和的可疑引用ExampleApplication.leakedViews：ArrayList.elementDataObject[].[0]
┬───
│ GC Root: System class
│
├─ android.provider.FontsContract class
│ ↓ static FontsContract.sContext
├─ com.example.leakcanary.ExampleApplication instance
│ Leaking: NO (Application is a singleton)
│ ↓ ExampleApplication.leakedViews
│ ~~~~~~~~~~~
├─ java.util.ArrayList instance
│ ↓ ArrayList.elementData
│ ~~~~~~~~~~~
├─ java.lang.Object[] array
│ ↓ Object[].[0]
│ ~~~
├─ android.widget.TextView instance
│ Leaking: YES (View.mContext references a destroyed activity)
│ ↓ TextView.mContext
╰→ com.example.leakcanary.MainActivity instance
ArrayList.elementData和Object[].[0]是 的实现细节ArrayList，并且实现中不太可能存在错误ArrayList，因此导致泄漏的引用是唯一剩余的引用：ExampleApplication.leakedViews.
4.修复泄漏?
一旦找到导致泄漏的引用，您需要弄清楚该引用是关于什么的，何时应该清除它以及为什么没有清除。
无法通过用弱引用替换强引用来修复内存泄漏。在尝试快速解决内存问题时，这是一种常见的解决方案，但它永远不会奏效。导致引用保留时间超过必要的错误仍然存??在。最重要的是，它会产生更多的错误，因为一些对象现在将比它们应该更快地被垃圾收集。它也使代码更难维护。