那你讲一下LeakCanary的原理

最新推荐文章于 2023-04-10 16:41:02 发布
原创 最新推荐文章于 2023-04-10 16:41:02 发布 · 386 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入解析了内存泄漏检测工具LeakCanary的1.5.1版本核心源码，从RefWatcher的watch方法入手，详细解释了弱引用和引用队列的工作原理。LeakCanary通过弱引用监测Activity的生命周期，当Activity被回收时，其KeyedWeakReference会进入引用队列。如果队列中不存在该引用，即判定为内存泄漏，并通过heapDumper.dumpHeap生成调用链，展示在通知栏和DisplayLeakActivity页面。此外，文章还介绍了如何通过Runtime.gc()触发GC并等待对象加入队列的过程。

今天来写一波内存泄漏工具LeakCanary的分析，也整理一下之前的笔记，废话不多说，源码整起来。

我用的1.5.1版本。

LeakCanary核心源码解析

看源码还是那句话，先找入口，顺着入口看主流程。

LeakCanary监听Activity的onDestory方法，然后介入，所以从这里开始

发现入口在RefWatcher.watch方法里，这个RefWatcher是核心类，跟进去watch方法。

可以看出这里开始搞事情了，先解释一下这些变量的意义

这样就可以解释，上图watch方法里面的操作了

使用randomUUID生成一个随机数key，并加到了一个set中，这个key跟当前监控的activity是一一对应的，这个很关键，watchedReference就是当前关闭的activity对象，然后包装成KeyedWeakReference对象，KeyedWeakReference继承了WeakReference。

后续就是就操作这个KeyedWeakReference这个弱引用。

到了这里就不得不提一下，强软弱虚这四个东西，如果还有不懂的小伙伴，还是要去看一下的，这里只提一下弱引用，简单来说就是。

弱引用持有的对象被回收了，那么弱引用就会放到与之关联的引用队列中。

？？？

讲人话！那举个栗子

就是上面watch方法的watchedReference(就是那个被监测的activity)被KeyedWeakReference弱引用持有了，当activity被回收了，RefWatcher#queue里面就会有这个KeyedWeakReference。

反之如果一顿操作之后queue都没有这个KeyedWeakReference，说明activity没有被回收，那么就判定为内存泄漏。

这也是LeakCanary的核心思想。

好，接着watch方法往下走，ensureGoneAsync方法跟进去到一个ensureGone的核心方法里

红框这里是核心中的核心。看起来很短，但浓缩才是精华。

removeWeaklyReachableReferences方法里就是遍历把引用队列queue里的对象，在retainsKeys这个set里面移除掉。

讲了半天，还记得开头这个retainsKeys放的什么吗？是那个UUID生成的与每个activity一一对应的key，可以理解为activity对应的一个值。当队列有一个弱引用了，说明有一个对应activity被回收了。

gone方法里判断retainsKeys集合里还有没有这个activity对应的值，没有说明正常回收了。

ensureGone的整个流程基本就清楚了，理一下ensureGone的流程。

首先根据队列的对象，移除对应set里对应的key值，gone判断是否移除成功，成功返回DONE，没有泄露结束流程，gone判断还存在，原谅ta再给一次机会，调用runGc触发回收，再次移除key值，gone判断还存在，不好意思，没有机会了，使用heapDumper.dumpHeap出调用链，showNotification展示到通知栏，最后展示到DisplayLeakActivity页面上。

最后还是弱引用基础知识的应用，所以说为什么大厂喜欢问基础知识，其实很多东西都是构建在基础知识之上。

关于gc的补充点

这里补充一点东西，也是之前被某厂问到了，当时没答出来的，主要是之前没看那么细，后面又翻了一下源码。

当时问的是上面gc的时候，是怎么gc的？第二次removeWeaklyReachableReferences是什么时候触发的？

当时想的是gc不都是System.gc嘛，还能有什么骚操作？回来打开一下源码，咦，发现还真有。。

那从GCTrigger入手了。

发现runGc里面不是直接调用System.gc的，用了一个Runtime.getRuntime().gc(),这是啥？

然后看见上面一堆注释还贴了源码url，觉得事情很重要，静下心来用我多年修炼来的四级的英语阅读能力扫了一遍。

简单来说就是，作者从AOSP那里Ctrl+c来了一段代码，因为System.gc()不能保证每次gc而Runtime.gc()会相对更可靠。

然后调用了enqueuReferences方法，里面就直接sleep了100ms，简单粗暴。。作者对于此的解释是没有很好能够获取到对象真正加入到队列的时机，所以直接等100ms让回收，100ms后执行runFinalization，然后就可以去第二次remove。

好家伙一个类就解答了两个问题，核心流程写完了，这次先写到这里，第一次用掘金，不知道掘金文章支不支持后续编辑，后续再补充一波

谢谢，朋友们

 

LeakCanary从使用到源码分析
itbird的专栏
08-01 768
LeakCanary源码大概分析完了，这里我们做个简单的小结，把知识点梳理一下。其中重点无非两点如何实现对象销毁的监听？Activity最简单，是通过监听onActivityDestroyed回调如何判断对象销毁之后是否存在内存泄露？1）设计一个框架时，初始化的代码，不一定非得让用户来调用，可以像LeakCanary2.X版本一样，借助ActivityThreadbindapplication时会遍历manifest中的contentprovider来做到这点。...
LeakCanary原理分析
三木仔
01-16 1595
LeakCanary是一个检测内存泄漏的工具，使用非常简单。主要用来检测Activity和Fragment内存泄漏，如果发生内存泄漏，直接在用UI显示哪里发生了泄漏并展示对象引用链。
LeakCanary核心原理源码浅析
Cloud_Huan的专栏
11-08 1万+
网上大牛太多，不敢说分析，也不敢装成大大，所以只能是浅析… 那么今天这篇主要解决什么问题呢？其实就一个问题，LeakCanay.install(this)这个函数到底是怎么走的，用测试的话说就是数据流是怎么走的，用探索性测试的方法说就是：快递法。 LeakCanay项目的地址是:https://github.com/square/leakcanary那么经过半天的下载之后，成功导入到as中。直
LeakCanary2.3 核心原理浅析
chidh的博客
05-18 2168
概述 LeakCanary是Android开发中常用的用来检测内存泄漏的框架，它能够帮助开发者快速发现是否发生内存泄漏，并可视化的给予提示。 这里基于LeakCanary 2.3版本进行分析。 只需要在工程中进行简单的集成配置，就能自动对Activity、Fragment、fragment View进行自动检测。也可以通过ObjectWatcher#watch方法对指定对象进行检测。 dependencies { // debugImplementation because LeakCanary sho
LeakCanary原理是什么
codehxy的专栏
07-30 307
1，如何发现内存泄露 内存泄露本质是长生命周期的对象引用了短生命周期对象，导致短生命周期对象内存空间不能及时回收。 LeakCanary在 Activity里销毁的时候，将activity实例放入弱引用中，再将弱引用放入引用队列中，然后执行gc，最后检测引用队列中是否有activity实例，如果有说明发生了内存泄露。 弱引用，就是gc后就回收。软引用是内存不足才回收。强引用是不回收。既然gc之后，弱引用里面的activity实例没有被销毁，说明还有对象引用activity实例。也就是内存泄露了。 2，如何找
LeakCanary 原理分析
Deaht_Huimie的博客
03-18 496
LeakCanary 以1.5版本为例子，简单分析其中的原理。 LeakCanary 可以检测App的内存泄漏，在我们自定义的 Application 的 onCreate() 方法中执行 LeakCanary.install(this); 这行代码即可。代码很简单，我们看看它做了什么 public static RefWatcher install(Application application) { return refWatcher(application).listenerServ...
面试系列“讲一下吧”之 LeakCanary
01-20
LeakCanary 的工作原理是通过一个 ContentProvider 来与你的应用程序进行绑定。在 AndroidManifest.xml 文件中，你需要添加 LeakCanary 的配置，但通常这个过程不需要开发者手动操作，因为 LeakCanary 已经包含了这...
LeakCanary原理解析
王三的专栏
10-10 1万+
转载注明出处：http://blog.youkuaiyun.com/xiaohanluo/article/details/78196755 使用 LeakCanary是Square为Android应用提供的一个监测内存泄露的工具，源码地址：https://github.com/square/leakcanary。 在gradle文件中引入依赖： dependencies { debug...
LeakCanary最新2.8.1版本源码 原理分析 [2022年初kotlin版]
admin_jalen的博客
01-22 3104
首先从LeakCanary的使用开始讲,接着会到底层分析源码逻辑 kotlin新版本如何使用 dependencies { // debugImplementation because LeakCanary should only run in debug builds. debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.8.1' } 只需要这样一步就搞定了. 默认监测哪些泄漏 官方网站的说明,无侵入式依赖,会自动给
内存泄露（八）-- LeakCanary
xuyin1204的博客
06-18 602
添加LeakCanary依赖包 https://github.com/square/leakcanary 在主模块app下的build.gradle下添加如下依赖: debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1' releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1' 开启LeakCanary 添加Application子类   首先
Android内存泄漏排查利器LeakCanary
01-05
本文为大家分享了Android内存泄漏排查利器，供大家参考，具体内容如下 开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖， 然后sync 一下， 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5' testCompile 'com.squareu
LeakCanary的原理初探
分享+记录
03-07 6226
一、前言： LeakCanary是很早之前的大名鼎鼎的square推出的一款安卓排查内存泄漏的工具。其功嫩相当强大，还记得19年的时候刚刚接触这款工具时，我们之前花了一整天找到的内存泄漏问题，用这款工具只用了大约十分钟就顺利的定位到了问题原因。 LeakCanary主要分为两块内容，第一块是发现排查内存泄漏问题，第二块是根据内存的状态输出泄漏的堆栈。本文主要讲解第一块内容，后续有时间会把第二块内容也补上。 PS：目前LeakCanary已经更新到2.8.1的版本，但是新版本代码结构较为复杂。所以本文还
彻底理解LeakCanary的工作原理
xuyin1204的博客
04-10 4835
LeakCanary工作原理解析
LeakCanary原理解析，理解起来超简单！
热门推荐
braintt的博客
08-17 1万+
一.引言 LeakCanary我相信大家都不会陌生的，在我们的开发过程中，为了避免内存泄漏的问题，我们可以在我们的项目中集成LeakCanary，来观察我们的应用程序是存在内存泄漏的问题。今天我们就来看看LeakCanary的原理，了解它是怎么去判断我们的应用程序是发生了内存泄漏的。 二.源码解析 在LeakCanary的源码中使用到了一个非常关键的数据结构，这个数据结构是LeakCanary判断...
Android 主流开源框架（九）LeakCanary 源码解析
wildma的博客
12-09 1215
前言 最近有个想法——就是把 Android 主流开源框架进行深入分析，然后写成一系列文章，包括该框架的详细使用与源码解析。目的是通过鉴赏大神的源码来了解框架底层的原理，也就是做到不仅要知其然，还要知其所以然。 这里我说下自己阅读源码的经验，我一般都是按照平时使用某个框架或者某个系统源码的使用流程入手的，首先要知道怎么使用，然后再去深究每一步底层做了什么，用了哪些好的设计模式，为什么要这么设计。 系列文章： Android 主流开源框架（一）OkHttp 铺垫-HttpClient 与 HttpURLCo
三方库详细解读——LeakCanary的实现
luoluofeixia的博客
07-21 305
综述 我们知道LeakCanary是用来检查Activity和Fragment是否存在内存泄漏的。那么他是如何监测的呢？我们本篇文章就来解析 监测生命周期 监测Activity生命周期 public final class ActivityRefWatcher { public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) { Application application = (Ap
请你给我讲讲 Handler 是如何持有 Activity 的引用的
最新发布
03-26
<think>嗯，用户问的是Handler如何持有Activity的引用，原理和实现方式。首先，我需要回忆一下Android中Handler的工作原理。Handler用于线程间通信，特别是子线程和主线程之间的消息传递。当在Activity中创建Handler时，通常会作为内部类，这样就会隐式持有外部类Activity的实例，对吧？ 那内部类持有外部类引用的问题，Java里内部类默认会持有外部类的实例，所以如果Handler是Activity的非静态内部类，就会导致Handler持有Activity的引用。这种情况下，如果Handler没有被正确释放，比如有未处理的消息或者Runnable，就会导致Activity无法被GC回收，造成内存泄漏。 然后，用户提到的引用里有几个解决方案，比如使用静态内部类加弱引用，或者使用Application的上下文。需要解释这些方法的原理。静态内部类不会隐式持有外部类的引用，所以结合WeakReference，可以在需要时获取Activity的实例，同时不会阻止GC回收Activity。 另外，Application上下文的使用场景是当Handler不需要访问Activity的特定资源时，避免持有Activity的引用。这种情况下，使用getApplicationContext()可以防止内存泄漏。 还有，用户可能想知道为什么Handler会导致Activity泄漏。比如，当MessageQueue中还有未处理的消息指向Handler时，Handler又持有Activity的引用，这些消息会保持Handler的引用，进而保持Activity的引用，导致无法回收。 需要详细说明这些机制，以及如何通过代码示例来避免问题。比如，引用中的静态内部类加弱引用的例子，要解释清楚如何实现，并说明在handleMessage时检查弱引用是否还存在，避免空指针。 可能还要提到在Activity生命周期结束时，比如onDestroy中，移除所有回调和消息，这样可以及时释放Handler对Activity的引用。这也是常见的优化方法。 总结一下，回答的结构应该是先解释原理，即内部类持有外部类引用，消息队列未处理导致Handler存活，进而导致Activity无法回收。然后介绍实现方式，包括默认的非静态内部类，以及推荐的静态类加弱引用或使用Application上下文。最后给出优化建议，如及时移除消息。 检查是否有遗漏的点，比如Looper和MessageQueue的角色，不过用户的问题集中在引用持有，可能不需要深入线程机制。需要确保引用标记正确，每个解决方案对应相应的引用来源。比如使用Application上下文对应引用[2]，静态内部类对应引用[4]。 用户可能对弱引用的具体实现不太清楚，需要简要说明WeakReference的作用，即不会阻止GC回收，但使用时需要检查是否还存在实例。另外，要提到内存泄漏的风险和实际开发中的处理方式，比如LeakCanary工具检测。 最后，生成的相关问题可能涉及如何检测Handler内存泄漏，其他避免内存泄漏的方法，或者不同上下文使用的区别。这些需要根据内容来设计相关问题。</think>### Handler 持有 Activity 引用的原理及实现方式 #### 1. **Handler 持有 Activity 引用的原理** Handler 是 Android 线程间通信的核心组件，**当 Handler 作为非静态内部类或匿名内部类定义在 Activity 中时**，会隐式持有外部类（即 Activity）的引用[^3]。 具体机制如下： - **隐式引用关系**：Java 的内部类默认持有外部类的实例。例如： ```java public class MainActivity extends Activity { private Handler mHandler = new Handler() { // 匿名内部类隐式持有 MainActivity 的引用 @Override public void handleMessage(Message msg) { // 更新 UI } }; } ``` - **生命周期不一致问题**：如果 Handler 未被及时释放（例如，仍有未处理的 Message 或 Runnable 在 MessageQueue 中），即使 Activity 已被销毁，Handler 仍会通过引用链阻止 Activity 被垃圾回收（GC），导致内存泄漏[^3]。 --- #### 2. **实现方式与风险场景** - **默认实现（非静态内部类）**： - **风险**：若 Activity 销毁后，Handler 仍有未处理的消息，会导致 Activity 实例无法释放。 - **示例**： ```java public class LeakyActivity extends Activity { private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { // 若 Activity 已销毁，此处操作可能引发崩溃 } }; } ``` - **静态内部类+弱引用**（推荐方案）： - **原理**：静态内部类不持有外部类引用，结合 `WeakReference` 弱引用 Activity，允许 GC 回收 Activity。 - **代码示例**： ```java private static class SafeHandler extends Handler { private final WeakReference<Activity> mActivityRef; public SafeHandler(Activity activity) { mActivityRef = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { Activity activity = mActivityRef.get(); if (activity != null && !activity.isDestroyed()) { // 安全操作 Activity } } } ``` [^4] --- #### 3. **优化建议** - **使用 Application 上下文**：若 Handler 无需操作 Activity 的 UI 或资源，可用 `getApplicationContext()` 创建 Handler[^2]。 - **及时清理消息**：在 Activity 的 `onDestroy()` 中调用 `mHandler.removeCallbacksAndMessages(null)`，移除所有未处理消息。 - **避免匿名内部类**：优先使用静态内部类或独立类封装 Handler。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值