4. iOS CoreBluetooth的多设备连接管理：CBCentralManager多实例与共享策略

4.1 原理概述

在iOS蓝牙开发中，CBCentralManager是管理BLE中央设备的单例代理对象。然而，实际业务常需要同时连接多个不同服务特征的外设，或按模块隔离不同蓝牙依赖。CoreBluetooth框架允许创建多个CBCentralManager实例，每个实例拥有独立的中央队列和代理回调，从而实现多路连接与职责分离。

多实例架构的核心优势：

• 模块隔离：不同业务模块（如心率监控、环境传感、设备固件升级）各自持有独立管理器，避免代理方法中的业务混杂。
• 连接状态独立：每个管理器维护自己的扫描、连接状态机，一个模块的重连失败不影响其他模块。
• 并发粒度可控：通过为每个管理器分配不同dispatch_queue_t，实现并行扫描或连接，提升多外设场景下的响应速度。

4.2 实现流程与API

4.2.1 创建多个CBCentralManager实例

每个实例需关联一个专用串行队列和可选的选项字典。推荐结构如下：

// 心率模块管理器
dispatch_queue_t heartQueue = dispatch_queue_create("com.ble.heart", DISPATCH_QUEUE_SERIAL);
NSDictionary *options = @{
    CBCentralManagerOptionShowPowerAlertKey: @(NO),
    CBCentralManagerOptionRestoreIdentifierKey: @"HeartRestoreID"
};
CBCentralManager *heartManager = [[CBCentralManager alloc] initWithDelegate:self
                                                                      queue:heartQueue
                                                                    options:options];

// 固件升级模块管理器
dispatch_queue_t dfuQueue = dispatch_queue_create("com.ble.dfu", DISPATCH_QUEUE_SERIAL);
CBCentralManager *dfuManager = [[CBCentralManager alloc] initWithDelegate:self
                                                                   queue:dfuQueue
                                                                 options:nil];

4.2.2 代理分发策略

由于所有管理器代理指向同一delegate（通常是当前ViewController），需要在代理方法中通过central参数区分来源：

- (void)centralManagerDidUpdateState:(CBCentralManager *)central {
    if (central == heartManager) {
        // 心率管理器状态变化
    } else if (central == dfuManager) {
        // DFU管理器状态变化
    }
}

- (void)centralManager:(CBCentralManager *)central
 didDiscoverPeripheral:(CBPeripheral *)peripheral
     advertisementData:(NSDictionary *)advertisementData
                  RSSI:(NSNumber *)RSSI {
    if (central == heartManager) {
        // 过滤出心率设备
    } else if (central == dfuManager) {
        // 过滤出DFU设备
    }
}

4.2.3 并发连接控制

CoreBluetooth默认限制每个管理器同时最多连接3～4个外设（iOS版本和设备型号有差异）。多实例模式下，每个管理器独立计数，因此总并发连接数可以扩展至实例数 × 单实例限制。但需注意系统总连接上限（通常约7～20个，受BLE芯片资源约束）。

策略	适用场景	系统开销	推荐实例数
单实例共享	通用单业务场景	低	1
多实例按功能隔离	多模块独立蓝牙需求	中	2～4
多实例按设备类型划分	大量同类外设分片管理	较高	3～6

4.3 架构图：多实例连接管理核心关系

4.4 共享策略与状态恢复

多实例场景下，跨模块的外设共享需求（如同一个设备同时提供心率和温度数据）需引入共享对象容器：

// 全局外设缓存（使用NSMapTable弱引用防止retain cycle）
NSMapTable *sharedPeripheralCache = [NSMapTable weakToWeakObjectsMapTable];

- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral {
    if (![sharedPeripheralCache objectForKey:peripheral.identifier]) {
        [sharedPeripheralCache setObject:peripheral forKey:peripheral.identifier];
    }
    // 后续模块通过identifier获取已发现的peripheral对象
}

对于系统级状态恢复，每个管理器必须具有唯一的CBCentralManagerOptionRestoreIdentifierKey。当系统重启应用时，CoreBluetooth根据该标识恢复各自的管理器状态（包括已连接的外设、未完成的扫描等）。关键代码：

// 在AppDelegate中响应状态恢复回调
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // 恢复标识需与创建时一致
    NSDictionary *options = @{CBCentralManagerOptionRestoreIdentifierKey: @"HeartRestoreID"};
    if (!heartManager) {
        heartManager = [[CBCentralManager alloc] initWithDelegate:self
                                                            queue:heartQueue
                                                          options:options];
    }
    return YES;
}

4.5 调试与常见错误

4.5.1 调试要点

• 队列阻塞检测：在关键回调中打印当前线程标识，确保回调在对应的专用队列上执行。
• 状态跟踪：为每个管理器维护一个枚举状态（扫描中/已连接/等待重连），配合本地日志系统。
• 内存泄漏：使用Instruments观察多个管理器对象是否被正确释放，特别是当模块切换时。

4.5.2 常见错误与解决方案

错误现象	原因	解决方案
调用scanForPeripheralsWithServices:nil后无回调	管理器状态不为CBManagerStatePoweredOn	检查每个管理器的state，在更新状态后再启动扫描
代理回调混乱	多个管理器共享同一队列导致串行化	为每个管理器分配独立dispatch_queue
状态恢复后管理器无法工作	恢复标识重复或未在application:didFinishLaunchingWithOptions:中恢复	确保标识唯一且恢复代码在启动早期执行
外设连接失败频繁	系统连接资源耗尽	限制最大连接数，或使用cancelPeripheralConnection:及时释放不需要的连接

4.6 性能与稳定性优化

1. 按需创建管理器：不需要时释放管理器（置nil），减少后台驻留开销。
2. 扫描限制：避免多个管理器同时扫描，可设计一个扫描仲裁器，同一时刻只允许一个管理器调用scanForPeripheralsWithServices:。
3. 连接池管理：实现maxConnectedPeripherals逻辑，超出时断开最久未使用的连接。
4. 蓝牙电源管理：在applicationDidEnterBackground:时移除所有管理器代理，防止后台唤醒系统消耗电量。