17、Native内存管理：JNI内存泄漏、Native Heap分析（Malloc Debug）、C++智能指针、跨层内存协调
说到Android内存管理，大家第一反应往往是Java堆。但说实话，真正让大厂资深工程师头疼的，往往是Native层。Java层有GC帮你兜底，Native层可没人惯着你——内存泄漏了就是泄漏了，野指针了就是野指针了，轻则OOM，重则直接Crash。
我这些年排查过不少线上问题，有一半以上的疑难杂症都跟Native内存有关。今天咱们就把这块硬骨头啃下来。
JNI内存泄漏：最隐蔽的杀手
JNI内存泄漏，说白了就是Java层和Native层之间的“垃圾”没人收。Java对象被Native引用着，GC不敢动；Native分配的内存，Java又管不着。结果就是两边都以为对方会清理，最后谁都没清理。
我遇到过最典型的一个案例：某个图片处理库，每次调用Native方法都会New一个全局引用，但从来没Delete。用户连续处理几十张图片后，App直接OOM崩溃。查了两天才定位到问题。
常见的JNI内存泄漏场景：
- 全局引用忘记释放：NewGlobalRef后没有对应的DeleteGlobalRef
- 局部引用溢出：循环中创建大量局部引用，超过JVM限制
- 跨线程引用管理不当：子线程中创建的局部引用，在父线程中无法使用
- GetStringUTFChars/ReleaseStringUTFChars不配对：获取字符串后忘记释放
// 正确的JNI引用管理示例
JNIEnv* env;
jobject globalRef = env->NewGlobalRef(localRef);
// ... 使用globalRef ...
env->DeleteGlobalRef(globalRef); // 务必释放
// 字符串处理也要配对
const char* utfStr = env->GetStringUTFChars(jstr, nullptr);
// ... 使用utfStr ...
env->ReleaseStringUTFChars(jstr, utfStr); // 别忘了Native Heap分析：Malloc Debug实战
Native内存泄漏怎么查？靠猜肯定不行。Android从9.0开始提供了Malloc Debug，这是个好东西。它本质上是一个内存分配拦截器，能记录每次malloc/free的调用栈。
启用方式很简单，在AndroidManifest的application标签里加个meta-data就行：
<meta-data android:name="android.app.malloc_debug"
android:value="backtrace"/>或者通过adb命令动态开启：
adb shell setprop libc.debug.malloc.options backtrace
adb shell setprop libc.debug.malloc.program 你的包名开启后，抓取heap dump文件：
adb shell am dumpheap -n 包名 /data/local/tmp/heap.dump然后用Python脚本分析：
# 使用Android提供的native_heapdump_viewer.py
python native_heapdump_viewer.py --format=pdf heap.dump我曾经用这套工具定位过一个非常隐蔽的问题：某个第三方SDK在后台线程频繁分配小内存块，但释放不及时，导致Native Heap持续增长。从heap dump里能看到大量相同调用栈的未释放内存，一眼就锁定了问题模块。
C++智能指针：Native层的“GC”
Java有GC，C++有什么？智能指针。说白了就是RAII（资源获取即初始化）思想的具体实现。智能指针在构造时获取资源，析构时自动释放，从根本上杜绝了忘记释放的问题。
Android源码里大量使用智能指针，尤其是：
- std::unique_ptr：独占所有权，不能拷贝，只能移动。适合明确所有权的场景。
- std::shared_ptr：共享所有权，引用计数管理。适合多个对象共享同一资源。
- std::weak_ptr：弱引用，不增加引用计数。用于解决循环引用问题。
#include <memory>
// unique_ptr示例：所有权明确
std::unique_ptr<Buffer> createBuffer(size_t size) {
return std::make_unique<Buffer>(size);
}
// shared_ptr示例：共享资源
class ImageProcessor {
std::shared_ptr<ImageData> mData;
public:
void process() {
// mData会被自动管理，最后一个引用释放时自动删除
}
};
// weak_ptr示例：避免循环引用
class Node {
std::shared_ptr<Node> next;
std::weak_ptr<Node> prev; // 用weak_ptr打破循环
};我个人的建议是：优先使用unique_ptr，除非确实需要共享所有权才用shared_ptr。unique_ptr性能更好，语义也更清晰。
跨层内存协调：Java与Native的“握手”
Java层和Native层各自管理自己的内存，但实际业务中它们经常需要交互。比如：Java层分配一个Bitmap，传给Native层做处理；或者Native层分配一个数据缓冲区，传给Java层使用。
跨层内存协调的核心原则：谁分配，谁释放。但实际执行起来往往没那么简单。
我常用的几种协调策略：
| 策略 | 适用场景 | 优缺点 |
|---|---|---|
| Java分配，Java释放 | 数据从Java流向Native，Native只读不写 | 简单安全，但需要数据拷贝 |
| Native分配，Native释放 | 数据从Native流向Java，Java只读不写 | 性能好，但需要JNI管理生命周期 |
| Direct ByteBuffer | 需要频繁跨层读写的大数据块 | 零拷贝，但管理复杂 |
| MemoryFile/SharedMemory | 跨进程共享内存 | 适合多进程场景，但需要同步机制 |
// Java层分配DirectBuffer
ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024);
// 传给Native层
nativeProcess(buffer, buffer.capacity());
// Native层接收
JNIEXPORT void JNICALL
Java_com_example_NativeBridge_nativeProcess(JNIEnv* env, jobject thiz,
jobject buffer, jint capacity) {
void* data = env->GetDirectBufferAddress(buffer);
// 直接读写data，零拷贝
}嗯，Native内存管理这块内容确实不少。从JNI引用管理，到Malloc Debug分析工具，再到智能指针和跨层协调，每一步都有坑。但只要你掌握了这些核心方法，Native内存问题就不再是玄学，而是可以系统化排查和解决的工程问题。