Android中处理BLE大二进制数据的优化方案咨询

算力阿峰

2026-5-14

嘿，这个问题我之前做BLE大文件传输的时候也碰到过，结合实践经验，给你拆解下问题根源和可行的优化方案：

先搞清楚内存占用飙升的潜在原因

你用data += received累加ByteArray的时候，每次都会生成全新的大ByteArray（比如之前是6MB，加一个包就变成6MB+N字节的新数组），这种频繁的大对象分配必然会触发频繁GC，导致内存占比暴跌。哪怕换了ByteBuffer，如果你的用法不对，比如每次都重新分配或者复制数据，本质上和ByteArray没区别。另外还有几个容易忽略的点：

RxAndroidBle的订阅链里如果用了不合适的操作符（比如scan累加数组），会产生大量中间临时对象；
如果没有设置合适的MTU，小数据包会成倍增加，每个数据包都是一个小ByteArray，积累起来也会给GC添负担；
要是你在主线程处理数据，GC触发的时机和频率会更苛刻，直观上内存波动就更明显。

优化数据存储的核心方案

1. 直接边收边写磁盘（最优解）

既然数据最大才16MB，完全没必要把所有数据都存在内存里。直接用文件流边接收边写入，内存占用基本就是单个BLE数据包的大小（哪怕MTU拉满到512字节，也只有几百KB），彻底解决内存压力：

val outputStream = FileOutputStream(File(getExternalFilesDir(null), "ble_data.bin"))
bleDevice.establishConnection(false)
    .flatMap { connection ->
        connection.requestMtu(512) // 先把MTU调到最大，减少数据包数量
            .andThen(connection.setupNotification(characteristicUuid))
            .flatMap { it }
    }
    .observeOn(Schedulers.io()) // 切换到IO线程写文件，别卡主线程
    .subscribe(
        { received ->
            outputStream.write(received)
            outputStream.flush() // 可选，按需刷新
        },
        { error ->
            outputStream.close()
            // 处理错误
        },
        {
            outputStream.close()
            // 传输完成，处理文件
        }
    )

2. 预分配直接内存缓冲区

如果一定要把数据存在内存里，用直接内存ByteBuffer（不在Java堆中，不会触发频繁GC），预分配好最大容量的缓冲区，直接写入数据，避免每次生成新数组：

val maxSize = 16 * 1024 * 1024 // 16MB
val directBuffer = ByteBuffer.allocateDirect(maxSize)
bleDevice.establishConnection(false)
    .flatMap { connection ->
        connection.requestMtu(512)
            .andThen(connection.setupNotification(characteristicUuid))
            .flatMap { it }
    }
    .subscribe(
        { received ->
            if (directBuffer.remaining() >= received.size) {
                directBuffer.put(received)
            } else {
                // 处理超出容量的情况
            }
        },
        { error -> /* 处理错误 */ },
        {
            directBuffer.flip() // 切换到读模式，后续可以读取数据
            // 处理缓冲区里的数据
        }
    )

注意：直接内存需要手动管理，用完后可以调用Cleaner相关方法释放（避免内存泄漏），不过Android 10+之后系统会自动回收，不用太担心。

3. 优化Rx链的对象复用

如果之前用了scan这类操作符累加数组，赶紧换掉——改用在doOnNext里直接写入预分配的容器，避免每次生成新对象。比如用ByteArrayOutputStream（虽然在堆内存，但比每次生成大数组好），但还是不如直接写磁盘或者用直接内存。

额外的排查和优化细节

用Android Profiler抓内存快照：打开Android Studio的Profiler，看看内存里到底是哪些对象占了大头——是大量的小ByteArray，还是Rx的中间对象，或者是其他泄漏的引用。精准定位才能对症下药；
强制设置MTU：默认MTU可能只有23字节，改成512可以把数据包数量减少到原来的1/20，大幅减少临时对象的生成；
避免主线程处理：把数据写入/处理的操作放到IO线程，减少主线程的GC压力，同时避免UI卡顿。

内容的提问来源于stack exchange，提问作者fonix232