安卓内存泄漏分析思路和案例剖析

分析思路

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

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

分析工具：Android Stuido Profiler

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

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

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

用户界面中的各项指标说明：

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

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

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

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

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

案例剖析

案例1：位图活页夹内存泄漏

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

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

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

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

先分析堆转储：

这是一个“多实例”内存泄漏，即每次抛光Activity1再打开，都会增加一个Activity对象留在堆中，无法销毁；常见于内部类引用、静态数组引用(如监听器列表)等场景；根据探查器提供的引用链，我们找到了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有一个活动的全局扩展方法startActivity2WithBitmap，里面创建了一个活页夹，将获取到的屏幕截图位图丢进去，并包在Intent中发送到活动2；显然这里有个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 $this_startActivity2WithBitmap$inlined; // 引用了activity
    // $FF: synthetic field
    final Bitmap $screenShotBitmap$inlined;

    BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1(Activity var1, Bitmap var2) {
        this.$this_startActivity2WithBitmap$inlined = var1;
        this.$screenShotBitmap$inlined = var2;
    }
    @NotNull
    public Bitmap getIntentBitmap() {
        return this.$screenShotBitmap$inlined;
    }
}

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

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

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

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

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

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

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

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

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<Bitmap>?): IBitmapInterface.Stub() {
    override fun getIntentBitmap() = bitmapRef?.get()
}

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

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

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

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

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

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

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

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

class XXPlugin: FlutterPlugin {
    private val mChannel: BasicMessageChannel<Any>? = 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
    }
}

可以看到其实FlutterPlugin其实是会持有binaryMessenger的引用的，而binaryMessenger又会有FlutterJNI的引用..。这一系列引用链最终会使FlutterPlugin持有Context、因此如果插件没有正确释放引用，就必然会出现内存泄漏.

我们看下上图引用链中loggerChannel的写法是怎么样的：

class LoggerPlugin: FlutterPlugin {
    override fun onAttachedToEngine(flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) {
        LoggerChannelImpl.init(flutterPluginBinding.getFlutterEngine())
    }

    override fun onDetachedFromEngine(binding: FlutterPlugin.FlutterPluginBinding) {
    }
}

object LoggerChannelImpl { // 这是一个单例
    private var loggerChannel: BasicMessageChannel<Any>?= null

    fun init(flutterEngine: FlutterEngine) {
        loggerChannel = BasicMessageChannel(flutterEngine.dartExecutor.binaryMessenger, LOGGER_CHANNEL, JSONMessageCodec.INSTANCE)
        loggerChannel?.setMessageHandler { messageJO, reply ->
            ...
        }
    }
}

在LoggerPlugin.onAttachedToEngine中，将FlutterEngine传入到了单例LoggerChannelImpl里面，binaryMessenger被单例持有，且onDetachedFromEngine方法未做销毁操作，因此一直被单例引用，上下文无法释放。

这个插件可能在设计时，没有考虑到多引擎的场景；单引擎时，插件的onAttachedToEngine、onDetachedFromEngine相当于是跟着应用的生命周期走的，因此不会出现内存泄漏；但在多引擎场景下，DartVM会为每个引擎分配隔离，和进程有些类似；隔离的DART堆内存是完全独立的，因此引擎之间任何对象(包括静态对象)都不互通；因此FlutterEngine会在自己的隔离中创建各自的FlutterPlugin实例，这使得每次创建引擎，插件的生命周期都会重走一遍.当销毁一个引擎时，插件没有正常回收，没有及时释放Context、FlutterEngine的相关引用，就会出现内存泄漏.

修改方案：

1. LoggerChannelImpl无需使用单例写法，替换为普通类即可，确保每个引擎的MessageChannel都是独立的；
2. LoggerPlugin.onDetachedFromEngine需要对MessageChannel做销毁和置空操作；

案例3：三方库本地引用内存泄漏

项目中接入了一个三方阅读器sdk、在一次内存分析时，发现每次打开该阅读器，内存便会上升一截并且无法下降；从堆转储文件看、事件探查器并未指出项目中存在内存泄漏，但可以看到应用程序堆中有一个活动未能回收的实例个数非常多，且内存占用较大。

查看GC根引用，发现这些Activity没有被任何已知的GC根引用：

毫无疑问这个Activity是存在内存泄漏的，因为操作的时候已经把相关页面都Finish掉并且手动GC，因此原因只能是Activity被某个不可见的GC，GCRoot引用了。

事实上、分析器的堆转储只会显示JAVA堆内存的GCRoot、而在本机堆中的GCRoot并不会显示到这个引用列表中。所以，有没有可能是这个Activity被Native对象持有了？

我们用动态分析工具Allocations Record看一下JAVA类在本机堆的引用，果然发现了这个活动的一些引用链：

但可惜引用链都是一些内存地址，没有显示类名，没法知道是何处引用到了活动；后面用泄漏金丝雀试了一下，虽然也明确说明了是本地层Global Variable的引用造成的内存泄漏，但还是没有提供具体的调用位置；

我们只好回到源码去分析下可能的调用处了.这个是DownloadActivity是我们为了适配阅读器sdk做的一个书籍下载的页面；当本地没有图书时，会先下载书籍文件，随后传入sdk中，打开sdk自己的活动；因此，DownloadActivity的功能就是下载、校验、解压书籍，并处理sdk阅读器的一些启动流程。

按常规思路，先检查下载、校验、解压的代码，都没有发现疑点，Listener之类的都做了弱引用封装；因此推测是sdk自身的写法导致的内存泄漏。

发现阅读器sdk启动时，有一个上下文入参：

class DownloadActivity {
    ... 
    private fun openBook() {
        ... 
        ReaderApi.getInstance().startReader(this, bookInfo) 
    } 
}

由于这个sdk的源码都是混淆过的，只能硬啃了，从startReader方法点进去一路跟踪调用链：

class ReaderApi: void startReader(Activity context, BookInfo bookInfo) 
        ↓ 
class AppExecutor: void a(Runnable var1) 
        ↓ 
class ReaderUtils: static void a(Activity var0, BookViewerCallback var1, Bundle var2) 
        ↓ 
class BookViewer: static void a(Context var0, AssetManager var1) 
        ↓ 
class NativeCpp: static native void initJNI(Context var0, AssetManager var1);

最后到了NativeCpp这个类的initJNI方法，可以看到这个本地方法把我们的Activity传进去了，后续处理不得而知，但基于上面的内存分析我们基本可以断定，正是由于这个方法、Activity的引用被Native的长生命周期对象持有，导致Activity出现内存泄漏。

至于为什么原生需要用到上下文则没法分析了，我们只能将这个问题反馈给开发工具包供应商，让他们做进一步处理。解决办法也不难：

1. 在销毁阅读器时及时置空活性引用；
2. startReader方法不需要指定Activity对象，入参声明改为Context即可，外部就可以将Application Context传进去.

标签：思路内存案例安卓系统