Android 内存泄漏分析思路和案例剖析，2024年最新Android开发学习视频

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

分析思路

内存泄漏是指 Android 进程中，某些对象已经不再使用，但被一些生命周期更长的对象引用，导致其占用的内存资源无法被GC回收，内存占用不断增加的一种现象；内存泄漏是导致我们应用性能下降、卡顿的一种常见因素，解决此类问题最核心的思路可以总结为以下两步：

1. 模拟内存泄漏的操作路径，观察应用 Heap 内存变化，确定出现问题的大概位置；
2. 针对具体位置展开分析，找到泄漏对象指向 GC Root 的完整引用链，从源头治理内存泄漏。

分析工具：Android Stuido Profiler

Profiler 中常用到的内存分析的工具有两个：内存曲线图和 Heap Dump；内存曲线可以实时观察内存使用状态，协助我们进行内存的动态分析；

内存泄漏出现时，内存曲线典型的现象就是呈现阶梯状，一旦上升则难以下降；例如 Activity 泄漏后，反复打开、关闭页面内存占用会一路上升，并且点击垃圾桶图标手动GC后，占用量无法下降到打开 Activity 之前的水平，这时大概率出现内存泄漏了。

这时，我们可以手动 dump 此时刻应用堆内存中的内存分布情况，用作静态分析：

UI中的各项指标说明：

1. Allocations：堆内存中该类的实例个数；
2. Native Size：该类所有实例引用到的Native对象所占内存
3. Shallow Size：该类所有实例自身的实际内存占用大小，不包括其所引用到的对象的内存占用大小；
4. Retained Size：与 Shallow Size 不同，这个数字代表该类所有实例及其所有引用到的对象的内存占用大小；

借助一张图，可以对这几个属性有更直观的印象：

如上图，红点的内存大小代表 Shallow Size，蓝点为 Native Size，所有橙色点的内存大小则为 Retained Size；当出现内存泄漏时，我们更应该关注 Retained Size 这个数字，它的意义是，因内存泄漏导致 Java 堆内存中所浪费的内存空间大小。 因为内存泄漏往往会形成“链式效应”，从泄漏的对象出发，该对象引用的所有对象和 Native 资源都无法回收，造成内存使用效率的下降。

另外 Leaks 代表可能的内存泄漏实例数量；点击列表中的类可以查看该类的实例详情；Instance 列表中的 depth 代表该实例到达 GC Root 的最短调用链深度，在图1右侧 Reference 一栏堆栈中可以直观地看到完整调用链，这时就可以一路追溯找出最可疑的引用，结合代码分析泄漏原因，并对症下药，根治问题。

接下来分析几个我们在项目中遇到一部分典型内存泄漏的案例：

案例剖析

案例1：BitmapBinder 内存泄漏

在涉及跨进程传输 Bitmap 的场景时，我们采用了一种 BitmapBinder 的方法；因为 Intent 支持我们传入自定义的 Binder，因此可以借助 Binder 实现 Intent 传输 Bitmap 对象：

// IBitmapBinder AIDL文件
import android.graphics.Bitmap;
interface IBitmapInterface {
Bitmap getIntentBitmap();
}

然而，Activity1 在使用 BitmapBinder 向 Activity2 传递 Bitmap 后，出现了两个严重的内存泄漏问题：

1. 跳转后再返回，Activity1 finish 时无法回收；
2. 反复跳转时，Bitmap 和 Binder 对象会反复创建且无法回收；

先分析 Heap Dump：

这是一个『多实例』内存泄漏，即每次 finish Activity1 再打开，都会增加一个 Activity 对象留在 Heap 中，无法销毁；常见于内部类引用、静态数组引用（如监听器列表）等场景；根据 Profiler 提供的引用链，我们找到了 BitmapExt 这个类：

suspend fun Activity.startActivity2WithBitmap() {
val screenShotBitmap = withContext(Dispatchers.IO) {
SDKDeviceHelper.screenShot()
} ?: return
startActivity(Intent().apply {
val bundle = Bundle()
bundle.putBinder(KEY_SCREENSHOT_BINDER, object : IBitmapInterface.Stub() {
override fun getIntentBitmap(): Bitmap {
return screenShotBitmap
}
})
putExtra (INTENT_QUESTION_SCREENSHOT_BITMAP, bundle)
})
}

BitmapExt 有一个 Activity 的全局扩展方法 startActivity2WithBitmap，里面创建了一个 Binder，将获取到的屏幕截图 Bitmap 丢进去，并包在 Intent 中发送到 Activity2 ；显然这里有个IBitmapInterface的匿名内部类，看来泄漏是从这里发生的；

但有两个疑问，一是这个内部类是写在方法里的，方法结束时，不会把方法栈中的内部类引用清除掉吗？二是这个内部类也并没有引用到 Activity 吧？

要搞明白这两点，就要把 Kotlin 代码反编译成 Java 看看了：

@Nullable
public static final Object startActivity2WithBitmap(@NotNull Activity $this$startActivity2WithBitmap, boolean var1, @NotNull Continuation var2) {
…
Bitmap var14 = (Bitmap)var10000;
if (var14 == null) {
return Unit.INSTANCE;
} else {
Bitmap screenShotBitmap = var14;
Intent var4 = new Intent();
int var6 = false;
Bundle bundle = new Bundle();
// 内部类创建位置：
bundle.putBinder(“screenShotBinder”, (IBinder)(new BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1($this$startActivity2WithBitmap, screenShotBitmap)));
var4.putExtra(“question_screenshot_bitmap”, bundle);
Unit var9 = Unit.INSTANCE;
$this$startActivity2WithBitmap.startActivity(var4);
return Unit.INSTANCE;
}
}

// 这是kotlin compiler自动生成的一个普通类：
public final class BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1 extends IBitmapInterface.Stub {
// $FF: synthetic field
final Activity $thi{s}_{s}tartActivity2WithBitmap$inlined; // 引用了activity
// $FF: synthetic field
final Bitmap $screenShotBitmap$inlined;

BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambdaKaTeX parse error: Expected '}', got 'EOF' at end of input: …p var2) { this.this_startActivity2WithBitmap$inlined=var1;this.$screenShotBitmapKaTeX parse error: Expected 'EOF', got '}' at position 17: …nlined = var2; }̲ @NotNull publi…screenShotBitmap$inlined;
}
}

在 Kotlin Compiler 编译生成的 Java 文件中，IBitmapInterface 匿名内部类被替换为普通类 BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1，并且这个普通类持有了 Activity。出现这个情况的原因是，Kotlin 为了在该类的内部能正常使用方法内的变量，把方法的入参以及内部类代码以上创建的所有变量都写进了该类的成员变量中；因此 Activity 被该类引用；另外 Binder 本身生命周期长于 Activity，因此产生内存泄漏。

解决方法是，直接声明一个普通类，即可绕过 Kotlin Compiler 的“优化”，移除 Activity 的引用。

class BitmapBinder(private val bitmap: Bitmap): IBitmapInterface.Stub() {
override fun getIntentBitmap( ) = bitmap
}

// 使用：
bundle.putBinder(KEY_SCREENSHOT_BINDER, BitmapBinder(screenShotBitmap))

接下来，问题是 Bitmap 和 Binder 会反复创建且无法回收的问题，内存现象如图，每次跳转再关闭，内存都会上涨一点，如同阶梯；GC 后无法释放；

heap 中，通过 Bitmap 尺寸 2560x1600, 320density 可以推断，这些都是未能回收的截图 Bitmap 对象，被 Binder 持有；但查看 Binder 的引用链，却并没有发现任何被我们应用相关的引用；

我们推测 Binder 应该是被生命周期较长的 Native 层引用了，与 Binder 的实现有关，但没找到回收 Binder 的有效方法；

一种解决办法是，复用 Binder，确保每次打开 Activity2 时，Binder 不会重复创建；另外将 BitmapBinder 的 Bitmap 改为弱引用，这样即使 Binder 不能回收，Bitmap 也能被及时回收，毕竟 Bitmap 才是内存大户。

object BitmapBinderHolder {
private var mBinder: BitmapBinder? = null // 保证全局只有一个BitmapBinder

fun of(bitmap: Bitmap): BitmapBinder {
return mBinder ?: BitmapBinder(WeakReference(bitmap)).apply { mBinder = this }
}
}

class BitmapBinder(var bitmapRef: WeakReference?): IBitmapInterface.Stub() {
override fun getIntentBitmap() = bitmapRef?.get()
}

// 使用：
bundle.putBinder(KEY_SCREENSHOT_BINDER, BitmapBinderHolder.of(screenShotBitmap))

验证：如内存图，一次 GC 后，创建的所有 Bitmap 都可以正常回收。

案例2：Flutter 多引擎场景 插件内存泄漏

有不少项目使用了多引擎方案实现 Flutter 混合开发，在 Flutter 页面关闭时，为避免内存泄漏，不但要将 FlutterView、FlutterEngine、MessageChannel 等相关组件及时解绑销毁，同时也需要关注各个 Flutter 插件是否有正常的释放操作。

例如在我们的一个多引擎项目中，通过反复打开关闭一个页面，发现了一个内存泄漏点：

这个activity是一个二级页面，使用多引擎方案，在上面跑了一个 FlutterView ；看样子是一个『单实例』的内存泄漏，即无论开关多少次，Activity 只会保留一个实例在heap中无法释放，常见的场景是全局静态变量的引用。这种内存泄漏对内存的影响比多实例泄漏略轻一点，但如果这个 Activity 体量很大，持有较多的 Fragment、View，这些相关组件一起泄漏的话，也是要着重优化的。

从引用链来看，这是 FlutterEngine 内的一个通信 Channel 引起的内存泄漏；当 FlutterEngine 被创建时，引擎内的每个插件会创建出自己的MessageChannel并注册到FlutterEngine.dartExecutor.binaryMessenger中，以便每个插件都能独立和 Native 通信。

例如一个普通插件的写法可能是这样：

class XXPlugin: FlutterPlugin {
private val mChannel: BasicMessageChannel? = null

override fun onAttachedToEngine(@NonNull flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) { // 引擎创建时回调
mChannel = BasicMessageChannel(flutterPluginBinding.flutterEngine.dartExecutor.binaryMessenger, CHANNEL_NAME, JSONMessageCodec.INSTANCE)
mChannel?.setMessageHandler { message, reply ->
…
}
}

override fun onDetachedFromEngine(@NonNull binding: FlutterPlugin.FlutterPluginBinding) { // 引擎销毁时回调
mChannel?.setMessageHandler(null)
mChannel = null
}
}

最后

我见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了5、6年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

转存中…(img-uxwHtun3-1713668143150)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-mjTucJtp-1713668143150)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！