Android BLE切换直连重连后特征自动订阅异常问题

我之前也碰到过一模一样的情况：用BluetoothGatt.connect()重连虽然稳，但速度慢，换成device.connectGatt(this, false, mGattCallback)后重连飞起，结果自动订阅特征的逻辑直接罢工。本质原因是两种连接方式的BluetoothGatt实例生命周期、服务发现流程完全不同，下面是我亲测有效的几个解决方案：

1. 强制刷新服务缓存，避免复用旧数据 #

直接连接模式下，系统默认会复用之前的服务缓存，但有时候缓存的数据和设备当前的服务状态不匹配，导致找不到特征或者订阅失败。我们可以通过反射调用隐藏的refresh()方法强制刷新缓存，再重新发现服务：

private boolean refreshGattCache(BluetoothGatt gatt) {
    try {
        Method refreshMethod = BluetoothGatt.class.getMethod("refresh");
        return (boolean) refreshMethod.invoke(gatt);
    } catch (NoSuchMethodException | IllegalAccessException | InvocationTargetException e) {
        Log.e(TAG, "刷新GATT缓存失败: " + e.getMessage());
    }
    return false;
}

然后在连接成功的回调里先刷新缓存，再发起服务发现：

@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
    if (newState == BluetoothProfile.STATE_CONNECTED) {
        // 先刷新缓存，再发现服务
        boolean isRefreshed = refreshGattCache(gatt);
        Log.d(TAG, "GATT缓存刷新状态: " + isRefreshed);
        // 立即发起服务发现
        gatt.discoverServices();
    }
}

2. 确保订阅操作在服务完全就绪后执行 #

有时候onServicesDiscovered返回GATT_SUCCESS，但设备端的特征还没完全初始化，导致订阅请求被拒绝。我们可以在订阅前做双重检查：

@Override
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
    if (status != BluetoothGatt.GATT_SUCCESS) {
        Log.e(TAG, "服务发现失败，状态码: " + status);
        // 重试服务发现，间隔2秒
        new Handler(Looper.getMainLooper()).postDelayed(() -> gatt.discoverServices(), 2000);
        return;
    }

    // 找到目标特征
    BluetoothGattCharacteristic targetChar = findTargetCharacteristic(gatt);
    if (targetChar == null) {
        Log.e(TAG, "未找到目标特征");
        return;
    }

    // 检查特征是否支持订阅（NOTIFY/INDICATE）
    int properties = targetChar.getProperties();
    if ((properties & BluetoothGattCharacteristic.PROPERTY_NOTIFY) == 0 
        && (properties & BluetoothGattCharacteristic.PROPERTY_INDICATE) == 0) {
        Log.w(TAG, "当前特征不支持订阅，重试服务发现");
        new Handler(Looper.getMainLooper()).postDelayed(() -> gatt.discoverServices(), 1000);
        return;
    }

    // 先取消旧订阅（新GATT实例可能残留无效订阅）
    gatt.setCharacteristicNotification(targetChar, false);
    // 获取客户端配置描述符（固定UUID: 00002902-0000-1000-8000-00805f9b34fb）
    BluetoothGattDescriptor descriptor = targetChar.getDescriptor(
        UUID.fromString("00002902-0000-1000-8000-00805f9b34fb")
    );
    if (descriptor != null) {
        // 设置订阅参数（通知用ENABLE_NOTIFICATION_VALUE，指示用ENABLE_INDICATION_VALUE）
        descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
        // 写入描述符完成订阅
        boolean writeSuccess = gatt.writeDescriptor(descriptor);
        if (!writeSuccess) {
            Log.e(TAG, "写入订阅描述符失败，重试");
            new Handler(Looper.getMainLooper()).postDelayed(() -> gatt.writeDescriptor(descriptor), 500);
        }
    }
}

// 辅助方法：根据UUID查找目标特征
private BluetoothGattCharacteristic findTargetCharacteristic(BluetoothGatt gatt) {
    UUID serviceUuid = UUID.fromString("你的服务UUID");
    UUID charUuid = UUID.fromString("你的特征UUID");
    BluetoothGattService service = gatt.getService(serviceUuid);
    if (service != null) {
        return service.getCharacteristic(charUuid);
    }
    return null;
}

3. 严格管理GATT实例的生命周期 #

直接连接会创建全新的BluetoothGatt实例，如果旧实例没有被正确关闭，会导致多个实例同时连接同一个设备，引发各种异常。所以每次发起新连接前，一定要关闭旧实例：

// 发起新连接的方法
private void connectToDevice(BluetoothDevice device) {
    // 关闭旧的GATT实例
    if (mGatt != null) {
        mGatt.close();
        mGatt = null;
    }
    // 创建新的GATT实例并连接
    mGatt = device.connectGatt(this, false, mGattCallback);
}

4. 调整服务发现的时序，给设备留足准备时间 #

直接连接成功后，设备可能还在初始化BLE服务，此时立即调用discoverServices()容易失败。可以延迟几百毫秒再发起服务发现：

@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
    if (newState == BluetoothProfile.STATE_CONNECTED) {
        // 延迟500ms再发起服务发现，给设备留初始化时间
        new Handler(Looper.getMainLooper()).postDelayed(() -> {
            boolean discoverSuccess = gatt.discoverServices();
            if (!discoverSuccess) {
                Log.e(TAG, "发起服务发现失败，重试");
                new Handler(Looper.getMainLooper()).postDelayed(() -> gatt.discoverServices(), 1000);
            }
        }, 500);
    }
}

总结 #

这些方案都是针对直接连接模式的特性设计的：核心就是解决缓存不一致、服务就绪时序、实例冲突这三个问题。一般先尝试方案3（管理实例）+方案4（调整时序），如果还不行再加上方案1（刷新缓存），基本就能解决订阅异常的问题了。

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