第24章蓝牙性能优化

课程目录第24章蓝牙性能优化

24、蓝牙性能优化：扫描功耗优化（Duty Cycle）、连接延迟优化、数据吞吐量提升（DLE/MTU扩展）、内存泄漏排查

各位同学，今天我们来聊聊蓝牙开发中最“接地气”的话题——性能优化。

说实话，蓝牙开发入门不难，调通一个连接、收发几包数据，照着官方Demo抄一抄，半天就能跑起来。但真正到了产品阶段，你会发现：扫描太费电、连接响应慢、传个大文件卡死、跑两天就闪退……这些问题才是真正让人头秃的地方。

我自己带过好几个项目，从智能手表到IoT网关，几乎每个项目都会踩一遍这些坑。今天我把这些经验整理出来，希望能帮你少走弯路。

核心要点：蓝牙性能优化不是单一维度的，它涉及功耗、延迟、吞吐量、稳定性四个维度。这四个维度往往互相制约——你追求低功耗，延迟就可能升高；你追求高吞吐量，功耗就会上去。所以优化的本质是“权衡”。

一、扫描功耗优化：Duty Cycle 的精打细算

先聊聊扫描功耗。你想想看，手机蓝牙一直在空中“监听”广播包，这本身就是个耗电大户。我见过不少项目，扫描一开，设备续航直接砍半。

核心参数就两个：扫描窗口（Scan Window）和扫描间隔（Scan Interval）。它们的比值就是 Duty Cycle，说白了就是“监听时间占比”。

参数	说明	典型值	功耗影响
扫描窗口	每次扫描持续的时间	10ms ~ 100ms	窗口越大，功耗越高
扫描间隔	两次扫描开始之间的时间	100ms ~ 1000ms	间隔越小，功耗越高
Duty Cycle	窗口 / 间隔 × 100%	10% ~ 100%	百分比越高，功耗越高

我的经验：如果只是做设备发现（比如扫描周围有哪些蓝牙设备），把 Duty Cycle 控制在 10%~20% 就足够了。我曾经在一个智能门锁项目里，把扫描间隔从 100ms 调到 500ms，设备待机时间从 2 天延长到了 7 天——而发现新设备的速度只慢了不到 1 秒。

代码实现上，Android 的 BluetoothLeScanner 提供了 ScanSettings 来配置这些参数：

// 低功耗扫描模式
ScanSettings settings = new ScanSettings.Builder()
    .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER)
    .setReportDelay(0)  // 实时回调
    .build();

// 如果你需要更精细的控制，可以手动设置窗口和间隔
// 注意：Android 10+ 支持 setLegacy(false) 来使用更精确的参数
ScanSettings customSettings = new ScanSettings.Builder()
    .setScanMode(ScanSettings.SCAN_MODE_OPPORTUNISTIC)
    .setLegacy(false)
    .build();

注意：Android 12 以后，扫描权限收得很紧。如果你在后台做持续扫描，系统可能会直接杀掉你的扫描请求。我曾经有一个项目，在 Android 13 上测试，后台扫描不到 30 秒就被系统强制停止了——后来改成了前台服务 + 周期性扫描才解决。

二、连接延迟优化：别让设备“睡过头”

连接延迟，说白了就是设备之间的“响应速度”。BLE 的连接是基于“连接事件（Connection Event）”的，主设备和从设备约定好每隔一段时间交换一次数据。这个时间间隔就是 Connection Interval。

我习惯把 Connection Interval 比作“闹钟”——主设备每隔 N 毫秒“叫醒”从设备一次。间隔越短，响应越快，但功耗越高；间隔越长，省电，但响应慢。

Android 端可以通过 BluetoothGatt 的 requestConnectionPriority 方法来调整：

// 请求高优先级连接（低延迟）
// 对应 Connection Interval 约 11.25ms - 15ms
bluetoothGatt.requestConnectionPriority(
    BluetoothGatt.CONNECTION_PRIORITY_HIGH
);

// 请求低功耗连接（高延迟）
// 对应 Connection Interval 约 30ms - 50ms
bluetoothGatt.requestConnectionPriority(
    BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER
);

// 平衡模式（默认）
bluetoothGatt.requestConnectionPriority(
    BluetoothGatt.CONNECTION_PRIORITY_BALANCED
);

关键点：这个请求只是“建议”，不是“命令”。蓝牙协议栈会根据当前链路质量、设备能力等因素做最终决定。我遇到过一些国产芯片，根本不理会 Android 端的优先级请求，这时候你就得去改固件了。

还有一个容易被忽略的参数——Slave Latency（从设备延迟）。它允许从设备跳过若干个连接事件而不响应，从而进一步省电。比如 Connection Interval 是 30ms，Slave Latency 设为 4，那么从设备最多可以 150ms 才响应一次。

避坑指南：我曾经在一个心率监测项目里，把 Slave Latency 设得太大，结果心率数据出现了明显的“断点”——因为设备跳过了太多连接事件，导致数据上报不及时。后来我把 Slave Latency 控制在 2 以内，既省电又保证了数据的连续性。

三、数据吞吐量提升：DLE 和 MTU 扩展

如果你需要传输大文件（比如 OTA 升级、图片传输），默认的 23 字节 MTU 会让你崩溃——传一个 100KB 的文件，需要拆成 4000 多个包，光握手开销就占了一大半。

这里有两个关键概念：

ATT MTU：应用层能发送的最大数据包大小。默认 23 字节（包含 3 字节 ATT 头），实际有效载荷只有 20 字节。
DLE（Data Length Extension）：链路层的数据包扩展。BLE 4.2 引入，可以把链路层数据包从 27 字节扩展到 251 字节。

说白了，MTU 决定了“应用层一次能发多少”，DLE 决定了“底层一次能传多少”。两者配合才能达到最大吞吐量。

Android 端协商 MTU 的代码很简单：

// 请求 MTU 为 512 字节（实际最大受限于设备能力）
bluetoothGatt.requestMtu(512);

// 在回调中获取协商后的 MTU 值
@Override
public void onMtuChanged(BluetoothGatt gatt, int mtu, int status) {
    if (status == BluetoothGatt.GATT_SUCCESS) {
        // mtu 就是协商后的值，通常 247 或 512
        Log.d("BLE", "MTU negotiated: " + mtu);
    }
}

实际效果：在我的测试中，MTU 从 23 扩展到 247，吞吐量从约 5KB/s 提升到了约 40KB/s。如果再配合 DLE（需要固件支持），可以跑到 80KB/s 以上。注意，这里说的是“实际有效吞吐量”，不是理论值——因为还要考虑连接间隔、丢包重传等因素。

关于 DLE，Android 端不需要显式调用——只要双方设备都支持 BLE 4.2+，协议栈会自动启用。但有个坑：有些国产芯片虽然声称支持 BLE 4.2，但 DLE 实现有 bug。我遇到过一款芯片，启用 DLE 后数据包会随机丢失，最后只能强制关闭 DLE 功能。

注意：MTU 协商是双向的。你请求 512，但对端可能只支持 247。协商结果以较小的值为准。另外，不要在 onServicesDiscovered 之前调用 requestMtu——我见过有人这么写，结果 MTU 协商永远失败。

四、内存泄漏排查：那些“看不见”的引用

蓝牙开发中的内存泄漏，可以说是“隐形杀手”。App 跑起来看起来正常，但用着用着就卡顿、闪退，打开 Profiler 一看——内存一直在涨。

我总结了几种最常见的泄漏场景：

Gatt 回调泄漏：注册了 BluetoothGattCallback 但没有在 onDestroy 或 onDisconnect 中清理。
Handler 泄漏：在匿名内部类中使用 Handler 发送延迟消息，Activity 销毁后 Handler 还在持有 Activity 引用。
Context 泄漏：把 Activity 的 Context 传给了蓝牙服务层，服务层长期持有导致 Activity 无法回收。
扫描回调泄漏：调了 startScan 但忘了调 stopScan，导致 ScanCallback 一直被持有。

来看一个典型的泄漏代码：

// ❌ 错误写法：匿名内部类持有 Activity 引用
bluetoothGatt.connect();
bluetoothGatt.setGattCallback(new BluetoothGattCallback() {
    @Override
    public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
        // 这里隐式持有外部 Activity 的引用
        updateUI(newState);
    }
});

// ✅ 正确写法：使用静态内部类 + 弱引用
private static class MyGattCallback extends BluetoothGattCallback {
    private WeakReference<MainActivity> activityRef;
    
    MyGattCallback(MainActivity activity) {
        this.activityRef = new WeakReference<>(activity);
    }
    
    @Override
    public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
        MainActivity activity = activityRef.get();
        if (activity != null) {
            activity.updateUI(newState);
        }
    }
}

我的排查工具链：我习惯用 Android Studio 自带的 Memory Profiler 配合 LeakCanary。先跑一遍功能，然后强制 GC，再 dump 一份 heap。重点看 BluetoothGatt、BluetoothDevice、BluetoothAdapter 这些类的实例数量——正常情况下应该只有一个，如果出现多个，大概率是泄漏了。

还有一个容易被忽略的点：蓝牙广播接收器（BroadcastReceiver）的注册与注销。很多人在 onResume 里注册了 BluetoothDevice.ACTION_ACL_CONNECTED 等广播，但忘了在 onPause 里注销。这会导致 Activity 销毁后，系统还在往你的 Receiver 发广播——而 Receiver 又持有 Activity 引用，GC 就永远回收不了。

曾经踩过的坑：有一个项目，蓝牙连接断开后，我调了 close() 和 disconnect()，但忘了把 BluetoothGattCallback 置为 null。结果 BluetoothGatt 对象虽然被释放了，但回调对象还在被系统底层的 Binder 线程持有——内存泄漏了整整 3MB，排查了两天才找到原因。

最后，分享一个我自己的“防泄漏清单”：

每次 startScan 必须对应一个 stopScan（建议在 onPause 中停止）
每个 connectGatt 必须对应一个 close（在 onDestroy 或断开连接后调用）
所有回调使用静态内部类 + 弱引用
所有 Handler 使用静态内部类，或者使用 Handler.removeCallbacksAndMessages(null) 清理
广播接收器在 onPause 中注销

嗯，以上就是蓝牙性能优化的四个核心方向。每个方向展开都能讲一整天，但今天先把骨架搭好。你如果在实际项目中遇到了具体问题，欢迎随时交流——毕竟蓝牙开发这东西，纸上谈兵容易，真动手了才知道坑有多深。

📚 课程目录

24、蓝牙性能优化：扫描功耗优化（Duty Cycle）、连接延迟优化、数据吞吐量提升（DLE/MTU扩展）、内存泄漏排查

一、扫描功耗优化：Duty Cycle 的精打细算

二、连接延迟优化：别让设备“睡过头”

三、数据吞吐量提升：DLE 和 MTU 扩展

四、内存泄漏排查：那些“看不见”的引用