第24章 Native层内存优化

课程目录第24章 Native层内存优化

第24章：Native层内存优化：C/C++内存管理、Native Heap分析与JNI全局引用泄漏

各位同学，今天我们来聊聊Android性能优化里最硬核的一块——Native层内存管理。说实话，很多做Android应用开发的同学，平时接触Java/Kotlin比较多，对Native层往往有点发怵。但你要知道，但凡涉及到音视频编解码、游戏引擎、OpenGL渲染、或者某些高性能计算库，底层基本都是C/C++在跑。一旦Native层内存出了问题，那可不是OOM那么简单了——直接就是段错误、闪退、甚至系统重启。

我个人习惯把Native内存优化分成三个维度来看：分配与释放、堆内存分析、JNI引用管理。咱们一个一个来拆解。

24.1 C/C++内存管理：malloc/free的那些坑

C/C++的内存管理，说白了就是「谁分配，谁释放」这六个字。但实际项目中，这六个字背后全是血泪史。

先看一个最基础的例子：

// 错误示例：忘记释放
void process_data() {
    char* buffer = (char*)malloc(1024 * 1024); // 分配1MB
    // 使用buffer...
    // 忘记free(buffer) — 内存泄漏！
}

// 正确示例
void process_data() {
    char* buffer = (char*)malloc(1024 * 1024);
    if (buffer == NULL) {
        // 处理分配失败
        return;
    }
    // 使用buffer...
    free(buffer);
    buffer = NULL; // 避免野指针
}

嗯，这里要注意：malloc之后一定要检查返回值。我在项目中遇到过好几次，内存不足时malloc返回NULL，但代码没做检查，直接往NULL地址写数据——啪，段错误。

⚠️ 避坑指南： 我曾经在一个视频处理模块里，因为忘记在异常路径上释放临时分配的缓冲区，导致App运行半小时后内存暴涨到800MB。后来排查了整整两天，才发现是某个goto跳过了free语句。从那以后，我给自己定了个规矩：malloc和free成对出现，写malloc的同时就把free写好。

另外，new/delete和malloc/free不要混用。C++的new会调用构造函数，malloc不会。混用的话，轻则资源未初始化，重则内存损坏。

24.2 Native Heap分析：Malloc Debug与AddressSanitizer

光靠肉眼审查代码，Native内存泄漏很难抓。我们需要工具。Android平台提供了两大利器：Malloc Debug和AddressSanitizer（ASan）。

24.2.1 Malloc Debug：轻量级的内存检测

Malloc Debug是Android系统自带的一套malloc钩子机制。你不需要改代码，只需要在启动App时设置一些属性：

# 启用malloc debug，记录所有分配/释放的调用栈
adb shell setprop libc.debug.malloc.options "backtrace=32"
adb shell setprop libc.debug.malloc.program your_app_package
# 重启App
adb shell am force-stop your_app_package
adb shell am start your_app_package/.MainActivity

然后抓取heap dump：

adb shell am dumpheap your_app_package /data/local/tmp/heap.dump

这个dump文件可以用perfetto或者simpleperf来分析。我个人习惯先用perfetto看整体趋势，再定位到具体调用栈。

💡 小技巧： Malloc Debug的开销比较大，建议只在debug版本或者压测环境下使用。线上版本千万别开，否则性能会下降50%以上。

24.2.2 AddressSanitizer：逮住内存错误的终极武器

ASan能检测什么？越界访问、use-after-free、double free、内存泄漏……基本上你能想到的内存错误，它都能抓。代价是性能下降约2倍，内存占用增加约3倍。

启用ASan需要在Android.mk或CMakeLists.txt中配置：

# CMakeLists.txt
target_compile_options(your_lib PRIVATE -fsanitize=address -fno-omit-frame-pointer)
target_link_options(your_lib PRIVATE -fsanitize=address)

然后在AndroidManifest.xml中为application添加：

<application
    android:name=".YourApplication"
    android:debuggable="true"
    ...>
    <meta-data
        android:name="android.asan.options"
        android:value="detect_leaks=1" />
</application>

运行后，如果发生内存错误，ASan会直接打印出详细的错误信息，包括出错的地址、调用栈、以及附近的内存布局。举个例子：

==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
WRITE of size 4 at 0x... thread T0
    #0 0x... in process_data native/lib.cpp:42
    #1 0x... in Java_com_example_app_NativeBridge_process ...
0x... is located 0 bytes to the right of 1024-byte region [0x..., 0x...)
allocated by thread T0 here:
    #0 0x... in malloc
    #1 0x... in process_data native/lib.cpp:38

你看，它直接告诉你在lib.cpp:42行写越界了，而内存是在lib.cpp:38行分配的。这比你自己一行行看代码高效太多了。

🔑 核心观点：
我个人建议，所有Native模块在开发阶段都应该开启ASan。虽然慢一点，但能帮你省下至少80%的排查时间。等发布release版本时再关掉。

24.3 JNI全局引用泄漏：一个容易被忽视的重灾区

JNI引用泄漏，说白了就是Java层和Native层之间的「桥梁」没管理好。很多同学以为C/C++代码里不直接操作Java对象就没事，其实恰恰相反——JNI引用泄漏往往比纯Native泄漏更难排查。

JNI引用分两种：局部引用和全局引用。

局部引用：在Native函数返回时自动释放。但如果函数内部有循环，或者调用了PushLocalFrame，就需要手动管理。
全局引用：必须显式调用DeleteGlobalRef释放。忘记释放的话，对应的Java对象永远不会被GC回收。

看一个典型的泄漏场景：

// 错误示例：全局引用泄漏
jclass g_clazz = NULL;

JNIEXPORT void JNICALL
Java_com_example_app_NativeBridge_init(JNIEnv* env, jobject thiz) {
    if (g_clazz == NULL) {
        jclass local_clazz = (*env)->FindClass(env, "com/example/app/MyClass");
        g_clazz = (jclass)(*env)->NewGlobalRef(env, local_clazz);
        // 注意：这里没有释放local_clazz，但局部引用会在函数返回时自动释放
        // 问题在于：g_clazz这个全局引用，在整个App生命周期内都没有被删除！
    }
}

// 正确示例：在适当的时候释放全局引用
void release_global_ref(JNIEnv* env) {
    if (g_clazz != NULL) {
        (*env)->DeleteGlobalRef(env, g_clazz);
        g_clazz = NULL;
    }
}

为什么会这样？因为NewGlobalRef创建的引用会阻止GC回收对应的Java对象。如果你在Native层缓存了一个jclass或jobject，但忘记释放，那这个对象就永远留在内存里了。

⚠️ 避坑指南： 我曾经在一个直播推流SDK里，因为缓存了jclass的全局引用，导致每次推流结束后，对应的Java回调对象都无法被回收。用户连续推流10次后，内存就涨了200MB。最后用jcmd配合MAT分析，才发现是JNI全局引用泄漏。修复后，内存稳定在50MB以内。

如何检测JNI全局引用泄漏？有两个方法：

使用jcmd命令：adb shell dumpsys meminfo your_package，查看JNI Global Reference的数量。如果这个数字持续增长，说明有泄漏。
使用Android Studio的Memory Profiler：在Native内存视图中，可以看到JNI全局引用的数量和具体对象。

24.4 知识体系总览

说了这么多，咱们用一张图来总结本章的核心内容。这张图展示了Native层内存优化的三个维度以及它们之间的关系：

24.5 实战建议

最后，我给大家几个实战中的建议：

写C/C++代码时，脑子里要时刻有一根弦：这块内存是谁分配的？什么时候释放？异常路径上有没有漏掉？
JNI全局引用一定要成对管理：我习惯在JNI_OnLoad中初始化全局引用，在JNI_OnUnload中释放。这样生命周期清晰，不容易漏。
善用智能指针：C++11的std::unique_ptr和std::shared_ptr能帮你自动管理内存，减少手动free的遗漏。但注意，JNI引用不能用智能指针管理，必须手动DeleteGlobalRef。
定期做Native内存压测：用malloc_hook或者heapprofd抓取长时间运行后的堆内存，看看有没有持续增长的趋势。

💡 我的个人习惯： 每次提交Native代码前，我都会在本地跑一遍ASan的单元测试。虽然慢一点，但能保证不会把内存错误带到集成环境。你想想看，如果等到QA报了一个「偶现闪退」，那排查成本可就高了去了。

好了，Native层内存优化就讲到这里。记住一句话：Native内存无小事，一个字节的泄漏，都可能成为压垮骆驼的最后一根稻草。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录