1. 一次数据拷贝的代价：为什么非要搞内存共享

做Android开发做到一定阶段，很多人的性能瓶颈都会卡在同一个地方：Java层和Native层之间的数据传递。尤其是做音视频处理、图像算法、传感器数据采集这类需要高频大批量交换数据的场景，如果每次传数据都靠拷贝，性能开销会非常难看。

举一个我实际遇到的例子。当时做一个实时滤镜项目，每帧图像数据是1920x1080的RGBA格式，一帧大概8MB左右。算下来每秒30帧，就是240MB的数据量。如果走最原始的JNI方式，用GetByteArrayElements把byte[]传到Native层，JVM要先把数据从Java堆拷到Native堆，处理完再拷回来。一帧数据来回两次拷贝，每秒就是480MB的纯内存拷贝量。光这一项就能吃掉不少CPU时间片，帧率很难稳住。

那ByteBuffer解决的是什么问题？它的核心思路是绕开拷贝，让Java层和Native层共享同一块物理内存。Java侧得到一个ByteBuffer对象，Native侧拿到这块内存的原始地址，两边操作的是同一块内存区域。写入方写完，读取方立刻能看到，不需要任何中间搬运。

这就像两个人合租一个书桌。以前的方案是A写完笔记放进抽屉，B拿出来抄一遍再放回去；共享内存的方案是A和B直接在同一个桌面上写，省掉了所有抄写动作。

本文围绕Android开发中Java与Native内存共享这条主线，把ByteBuffer的使用经验完整梳理一遍，包括DirectByteBuffer的创建、JNI传递、地址获取、生命周期管理、字节序陷阱，以及在真实项目中的性能表现和选型建议。适合正在做NDK开发、音视频处理、高性能计算，或者在JNI层反复被数据拷贝折磨的Android工程师参考。

我尽量只讲实际操作中验证过的东西，不堆理论术语。有些细节网上资料不太讲，但真能帮你在项目里少踩几个坑。

2. ByteBuffer的底细：堆内Buffer与直接Buffer的本质差异

2.1 两种Buffer的内存布局究竟差在哪

Java NIO里的ByteBuffer有两种典型形态：一种是ByteBuffer.allocate()创建的堆内Buffer，底层数组在Java堆里；另一种是ByteBuffer.allocateDirect()创建的直接Buffer，内存分配在Java堆之外，由JVM统一管理，这块内存的地址可以直接通过JNI暴露给Native层。

堆内Buffer的底层其实就是一个byte[]数组，JVM的GC可以随意移动它。Native层拿到的指针只是一次性快照，JVM一旦做了堆整理，指针就失效了，所以用GetByteArrayElements拿到的数组指针在Release之前是受限状态，本质还是使用拷贝或者锁页来保证安全。DirectByteBuffer则完全不同，它的内存是JVM对外分配的，GC不会移动它，Native层可以长期持有它的地址，随时读写。

这就是为什么JNI专门提供了GetDirectBufferAddress这个函数来获取直接Buffer的地址。这个函数在Android NDK里稳定可用，从底层给你返回一个void*指针，指向DirectByteBuffer在Native内存中的起始位置。

需要注意的一点是：allocateDirect创建的直接Buffer，字节序默认是BIG_ENDIAN，也就是大端。很多人在多字节数据读写时遇到乱码和数值错乱，十有八九是字节序没对上，后面我会单独展开讲。

2.2 position、limit、capacity三个游标的配合逻辑

ByteBuffer里有三个核心状态位：capacity表示缓冲区总容量，创建后固定不变；limit表示可读写的边界；position表示当前读写位置。理解这三个游标，是正确使用ByteBuffer的前提。

刚创建出来的Buffer，position是0，limit等于capacity，处于写模式。当你往里写数据，position会一路往后移。写完后要想把数据交给读取方，必须先调用flip()，把limit设成当前的position，再把position归零，这样就能从开头读到刚才写入的末尾。

相反，读完数据想重新写入，就用clear()把position归零、limit设回capacity，但注意clear并不会清空底层数据，只是把游标重置。还有一个rewind()，只把position归零、不改limit，适合重复读取同一段数据。

这几个操作我在项目里每天都会用到，说它们决定ByteBuffer的正确性一点不过分。一开始不太熟练的开发者普遍容易犯的错是：写完数据忘记flip，直接去读，读出来全是空值，或者position走过头导致读写越界。社区里不少新人求助帖，最后查出来都是这一个原因。

2.3 容量选择与扩容机制

DirectByteBuffer分配内存的代价比堆内Buffer高不少。每次allocateDirect，JVM底层要调用系统接口分配一整块连续内存，耗时可能达到毫秒级，因此在循环里频繁创建直接Buffer是非常糟糕的做法。

更合理的策略是复用：在初始化阶段按最大数据量创建一块Buffer，整条链路共用。比如音频采样，每帧数据量一般是固定的，最好在开始采集时就分配一块足够容纳最大帧的DirectByteBuffer，后续每一帧都往同一块Buffer里写，通过position管理当前帧边界，处理完重置游标。

如果确实需要动态扩容，只能重新分配一块更大的Buffer，然后把旧数据拷过去。这块没有捷径可走，所以宁可在初始化时多分一些容量，也不要频繁扩。

3. Java层到Native层的完整传递链路：从创建到回收

3.1 Java侧创建DirectByteBuffer并持有

使用共享内存的第一步，是在Java层创建DirectByteBuffer。最常见的做法是用ByteBuffer.allocateDirect(capacity)创建，然后通过一个成员变量长期持有它，避免被GC回收。

需要注意的是，DirectByteBuffer一旦在Java侧失去强引用，GC在回收它的同时会触发底层内存释放。如果Native层还在拿着那个地址乱写，轻则数据错乱，重则直接导致内存访问违例崩溃。所以Java侧必须对这个Buffer保持强引用，这个原则我在项目里反复强调过多次。

还有一种更隐蔽的坑：不要在方法内部创建DirectByteBuffer就直接传给Native使用，方法执行完局部变量就被释放了。哪怕Native层当时没崩溃，后续某个GC发生后再去用那个地址，概率性野指针，非常难查。

正确姿势是把它放到类成员变量里，或者用一个专门的管理类持有。Android里常见的做法是在某个生命周期对象初始化时创建，销毁时再调用回收逻辑。

3.2 JNI方法注册与Native方法声明

Java侧声明Native方法时，参数类型直接用java.nio.ByteBuffer即可。比如：

public native int processFrame(ByteBuffer buffer, int size);

Native侧对应的函数签名参数类型是JNIEnv*, jobject, jobject。其中那个jobject就是Java层传下来的ByteBuffer对象。在Native代码里，首先要做的事情就是从这个jobject中提取出真正的内存地址。

3.3 Native侧获取共享内存地址并操作

Native侧拿地址，核心是调用JNI函数GetDirectBufferAddress。典型的代码结构如下：

#include <jni.h> #include <android/log.h> extern "C" JNIEXPORT jint JNICALL Java_com_example_nativebridge_NativeBridge_processFrame( JNIEnv* env, jobject thiz, jobject byteBuffer, jint size) { // 获取DirectBuffer的内存地址 unsigned char* data = static_cast<unsigned char*>( env->GetDirectBufferAddress(byteBuffer)); if (data == nullptr) { // 说明传入的不是DirectByteBuffer，或底层不支持 return -1; } // 执行图像处理或音视频处理逻辑 // 直接读写data指针指向的内存区域 process(data, size); return 0; }

拿到地址后，后面的操作就和普通的C/C++内存操作完全一致。你可以用memcpy批量拷贝，也可以把指针强转成结构体指针逐字段访问，甚至可以传给第三方C库。这个指针指向的内存就是Java层ByteBuffer对应的那块内存，两边数据天然同步。

还需要提醒一个细节：GetDirectBufferAddress对HeapByteBuffer会返回NULL。也就是说，如果你传了一个ByteBuffer.allocate()创建的Buffer，Native层拿不到地址。所以Java侧必须创建DirectByteBuffer才能走共享内存这条路。这在设计和代码注释里最好写清楚，防止团队其他成员在调用时传错Buffer类型。

3.4 生命周期管理的几个关键动作

跨语言内存共享里，最难受的就是两边的生命周期不同步。Java层的DirectByteBuffer由GC管理，Native层却是手动管理。Android开发里我通常会遵循以下几条规则：

第一，Buffer的创建和释放控制在Java侧，Native层只负责读写，不负责分配和释放。原因很简单，Java侧对GC时机有统一管理能力，Native层直接调free有风险。

第二，如果DirectByteBuffer需要长期存活，用全局引用把它钉住。JNI的局部引用在Native方法返回后可能失效，但如果你的Native代码在后台线程里缓存了这个Buffer引用，就必须用NewGlobalRef转成全局引用，否则会有悬空引用风险。

第三，确定不再使用Buffer时，在Java侧解除引用并显式触发回收。Android上可以对DirectByteBuffer调用sun.misc.Cleaner相关的clean方法，但反射机制在Android高版本上并不完全稳定，我的建议还是保持成员变量引用，让GC按正常节奏接管，不要过度依赖强制回收。

补充一点对FileChannel.hmap()的介绍：FileChannel.map()返回的也是DirectByteBuffer，它背后映射的是文件而不是匿名内存，不过在JNI层同样可以使用GetDirectBufferAddress获取地址，所以如果你要做文件读写和内存映射，这条链路是完全通用的。

4. 共享内存的实战读写：状态位管理与批量数据操作

4.1 Java侧写入、Native侧读取的实战流程

最典型的使用场景是Java层准备好数据，交给Native层处理。拿音频采集来说，Java侧从AudioRecord读出一帧PCM数据，写进共享Buffer，然后调Native方法做降噪或编码。

Java侧大致的流程是：

// 初始化时创建 mSharedBuffer = ByteBuffer.allocateDirect(4096); // 每帧写入数据 mSharedBuffer.clear(); short[] pcmData = readFrame(); for (int i = 0; i < pcmData.length; i++) { mSharedBuffer.putShort(pcmData[i]); } // 调用Native处理 nativeProcess(mSharedBuffer, pcmData.length * 2);

这里有一个非常容易踩的坑：写完数据给Native之前，要么调用flip()把position重置到0，要么在Native侧根本不依赖position，只用自己算好的字节长度来读取。很多开发者习惯Native侧直接用position作为读取边界，但Java侧写完数据忘了flip，Native读到的就是错位的数据。

我的习惯是：Java侧写入完成后不flip，而是在调用Native时把有效的字节长度作为参数显式传过去。Native侧从Buffer起始地址读指定长度即可，不依赖position。这样代码可读性和容错性都更高。如果Java侧确实用了flip，那Native侧就要用GetDirectBufferCapacity来读取limit边界，两种方式必须保持一致，混用必出事。

4.2 Native侧写入、Java侧读取的注意事项

反向流程同样常见。Native层处理完数据，把结果写进共享Buffer，Java侧再读出来使用。此时的坑在于Java侧读取时position和limit的维护。

Native侧写入时，它会直接往data指针指向的地址写字节，写完后Java侧的ByteBuffer里的position其实没有自动变化。因为对JVM来说，这块内存被外部改了内容，Buffer对象本身的状态位并没有感知。

所以Java侧读取Native写入的数据时，一般要手动调用flip()或者自己设置position和limit。如果不做这一步，直接get()，位置还是创建时或上次使用后的位置，读出来的数据完全是乱的。

// Native处理完成后 mSharedBuffer.position(0); mSharedBuffer.limit(nativeResultSize); // 现在可以读取了 byte[] result = new byte[nativeResultSize]; mSharedBuffer.get(result);

这个逻辑很简单，但实际项目里翻车的频率极高。尤其是处理流程一长，多个模块共用一个Buffer，状态位被搞乱，排查起来很头疼。后来我在团队的代码规范里加了硬性要求：每个模块在使用共享Buffer前，必须显式设置position和limit，不允许依赖上一个模块留下的状态。

4.3 slice、duplicate与只读视图的正确用法

ByteBuffer还提供了几个视图相关的操作：slice()会创建一个从当前位置到limit之间的新Buffer，与原Buffer共享底层内存；duplicate()创建的是整个Buffer的副本视图，同样共享内存；asReadOnlyBuffer()是在共享内存的基础上禁止写入。

表面看这些方法很简单，但和Native结合时有一个细节值得注意：slice出来的Buffer也是DirectByteBuffer，Native层一样可以GetDirectBufferAddress拿到地址，但拿到的地址不是原Buffer的起始地址，而是slice起始位置的地址。这个在写代码时很容易忽略，误以为还要在Native代码里处理偏移量，结果就是数据错位。

我的建议是：能避免视图操作就尽量避免。如果确实需要只读保护，用asReadOnlyBuffer在Java层做访问控制，Native层还是传原始Buffer。如果必须传slice给Native，那Java侧和Native侧一定要约定好，地址已经是偏移后的，不要再叠加offset。

4.4 批量读写与双重缓冲机制

预处理大批量数据时，别用get()和put()一个个操作，那是灾难级的性能问题。用批量接口：

byte[] temp = new byte[1024]; mSharedBuffer.get(temp, 0, 1024); // 一次性读取 // 或 mSharedBuffer.put(temp, 0, 1024); // 一次性写入

从Native层看，GetDirectBufferAddress拿到的是连续内存，Java侧byte[]本质上也是连续内存，两者之间的批量拷贝用memcpy就能达到很高带宽。Android设备上实测，非批量逐字节操作和memcpy之间的差距，在几MB数据量上就能拉开几十倍的耗时差距。

生产环境下，我还比较推崇双缓冲策略。一块Buffer用于当前帧写入，另一块Buffer用于上一帧Native处理，两块轮流交替。Java侧写入A时，Native侧处理B上的数据，互不阻塞。这个模式和图形渲染里的双缓冲是同一个道理，能比较有效地掩盖处理延迟。实现也不复杂：创建两个DirectByteBuffer，用序号轮流分配即可。

5. 实测中容易翻车的细节：字节序、对齐、生命周期

5.1 字节序：大端小端不一致的乱码惨案

字节序这个问题我是在一个传感器数据接入项目里踩实的。当时传感器输出的每个采样值是两字节的short类型。Java侧ByteBuffer默认的字节序是BIG_ENDIAN，而底层传感器模块和Native处理库使用的是小端序。

因为两边对同一块内存区域的字节解释顺序不统一，读出来的数值和原始值完全对不上。调试了半天才定位到问题：不是数据采样错了，而是同一个short类型的数据在两边被按不同的字节序解析了。

解决方案很简单，创建DirectByteBuffer时统一指定字节序：

mSharedBuffer = ByteBuffer.allocateDirect(4096).order(ByteOrder.nativeOrder());

这里有个建议：只要Buffer最终要交给Native的C/C++代码处理，一律在创建时调用order(ByteOrder.nativeOrder())，让Java侧的解析方式和Native侧保持一致。在ARM和x86平台上，nativeOrder基本都是LITTLE_ENDIAN。

如果项目里有历史Buffer没有设置字节序，你可以在Java侧单独用order(ByteOrder.LITTLE_ENDIAN)控制读写时的字节解析，但Native侧不受这个设置影响，因为Native拿到的是原始内存字节。这一点要理解透彻：Java的order方法控制的是putInt/getInt这类多字节操作的字节组装顺序，Native侧完全按字节地址直接解析。

5.2 64位设备上的地址宽度问题

Android从64位架构普及之后，内存地址宽度从32位变到了64位。JNI的GetDirectBufferAddress返回的是void*，在C++里直接用指针类型保存没有问题。但如果你为了调试把地址转成jlong输出，或者在一个老的代码库里用int存储指针，地址就会被截断，访问时直接崩或者非法访问。

我在一个旧项目中就遇到过类似问题，那是因为之前某个团队把指针强转成int存进了日志或缓存结构，在新设备上地址被截断了一半，后续访问全部落到错误的地址空间。排查这类问题往往非常耗时。

现在的推荐做法是：Native层一律使用uintptr_t或void*来保存DirectBuffer地址，不要使用int、long去存。涉及到日志打印，用%p格式化打印指针值。Java层如果需要在多次调用间传递地址信息，不要把指针值传到Java层再传回来，而是让Native层自己缓存地址，用对象身份或句柄关联。

5.3 DirectByteBuffer的回收与内存泄漏

DirectByteBuffer的内存开销比堆内Buffer大得多，但还算安全。真正麻烦的是你反复创建DirectByteBuffer又不释放，导致Native内存被大量占用。在Android上，底层的内存压力最终会换算成整机内存压力，严重时触发系统杀进程。

正常情况下，DirectByteBuffer被GC回收时，JVM会通过内部Cleaner机制释放对外内存，无需手动处理。但有两个场景值得注意：

一是如果DirectByteBuffer被Native代码持有了全局引用（NewGlobalRef），那么Java侧对象永远不会被GC回收，内存也就不会释放。这时候如果每次创建新Buffer没有释放旧引用，内存曲线就会一路向上。解决方式是：在不使用后，用DeleteGlobalRef释放全局引用。二是Native侧用NewDirectByteBuffer创建了Buffer并返回给Java，这块内存的释放同样要交给Java侧的GC，不能在Native侧随意free。

我的实践建议：创建DirectByteBuffer统一走Java侧封装管理类，类里记录Buffer列表和对应的全局引用状态，结合生命周期回调统一释放，不要分散在各业务模块。

5.4 性能实测：共享内存到底比拷贝快多少

为了把收益量化，我在项目里做了一次对比测试。测试的条件是某设备上处理一帧8MB的RGBA图像数据，分别用GetByteArrayElements拷贝方案和DirectByteBuffer共享方案各跑100帧，取平均耗时。

结果是：拷贝方案单帧平均耗时约为3.78ms，共享方案单帧平均耗时约为1.62ms，差距超过两倍。这个差距会随着数据量增大进一步拉开，数据量翻倍时拷贝方案的耗时近似翻倍，共享方案的增长幅度几乎可以忽略，因为处理管线已经被优化为内存原地操作。

需要说明的是，这个测试结果不包含业务处理本身的时间，纯粹是数据进出JNI边界的开销。如果你的业务逻辑很重，两者差距在总耗时里占比可能不大；但如果是轻量计算、高频数据流应用，共享内存的优势会非常直观。

6. 方案选型：ByteBuffer之外还有哪些路可以走

6.1 不同内存共享方案的对比

围绕Java层和Native层内存共享，ByteBuffer不是唯一方案。要根据数据规模、传输频率和硬件条件来选。

HeapByteBuffer方案的优势是无需额外的Buffer管理，Java侧用起来最简单，但数据还是要通过拷贝方式交给Native。如果你的数据量不大、频率不高，完全没必要为了追求共享内存而增加复杂度。

SharedMemory是Android在API 27引入的跨进程共享内存封装，与ByteBuffer思路不同，它基于文件描述符实现，特别适合多个进程之间传递大块数据。但它不能直接当ByteBuffer用，需要结合ParcelFileDescriptor和MemoryFile来处理。

6.2 日常开发中的选型建议

我的实际选择习惯可以概括为三条：

数据量小于几十KB、低频调用的，直接用byte[] + GetByteArrayElements，省心省力。

数据量达到百KB以上、调用频率在几十毫秒一次的，用DirectByteBuffer共享内存方案。这是绝大多数NDK音视频和图像处理场景的普适选型。

需要跨进程共享数据的，优先考虑SharedMemory或匿名共享内存，而不是单纯追求ByteBuffer。

最后再说点实在的。如果你还在纠结使用ByteBuffer的复杂性，可以先写一个最小Demo验证：Java层创建DirectByteBuffer，写几个字节，Native层读出来再写回去，Java层读回来比对。把这条链路跑通，后面所有高并发场景的底子都稳了。数据拷贝那点隐性的性能成本，在系统复杂度和数据量上去之后会被无限放大，现在花一天时间把共享内存搞清楚，后面能帮你省下一个又一个周末的排查时间。