10、多设备连接管理：同时连接多个BLE设备、连接池设计、连接优先级管理、断线重连策略

多设备连接管理，说白了就是让你的手机能同时跟好几个BLE设备“聊天”，而且聊得有条不紊。我刚开始做这块的时候，以为只要把每个设备的连接请求发出去就行了，结果发现根本不是那么回事——设备一多，连接就乱套了。

为什么会这样？因为Android的BLE底层对并发连接数有限制，而且蓝牙芯片的资源就那么点。你想想看，如果同时连了手环、体脂秤、温度计、门锁……每个设备都在收发数据，系统很容易就扛不住了。

10.1 同时连接多个BLE设备的核心挑战

先说说我踩过的坑。有一次做智能家居项目，需要同时连接6个传感器。我天真地以为每个设备独立连接就行，结果连到第4个的时候，系统直接抛了个GATT_ERROR，后面两个死活连不上。

核心问题有三个：

  • 连接数限制：Android系统对BLE并发连接数有限制，通常是4-7个，具体看芯片和厂商实现。我遇到过某款手机只能连3个。
  • 资源竞争：每个连接都要占用蓝牙协议栈的资源，包括GATT实例、回调线程、数据缓冲区。资源不够就会丢包或断连。
  • 调度混乱：多个设备同时请求数据，如果没有合理的调度机制，就会出现“谁喊得响谁先得”的局面，低优先级设备可能永远得不到响应。

关键认知：多设备连接不是简单的“开多个连接”，而是要在有限的资源下，保证每个设备都能稳定、有序地通信。

10.2 连接池设计：管好你的连接资源

连接池这个概念，其实是从数据库连接池借鉴过来的。我个人的习惯是，把每个BLE连接看作一个“资源单元”，统一管理它们的创建、复用和销毁。

下面是我在项目中用过的连接池设计思路：

public class BleConnectionPool {
    private static final int MAX_CONNECTIONS = 5;
    private final Map<String, BleDeviceConnection> activeConnections = new ConcurrentHashMap<>();
    private final Queue<BleDeviceConnection> idlePool = new LinkedBlockingQueue<>();

    public synchronized BleDeviceConnection acquireConnection(String deviceAddress) {
        // 先从活跃连接里找
        BleDeviceConnection conn = activeConnections.get(deviceAddress);
        if (conn != null && conn.isConnected()) {
            return conn;
        }
        // 再从空闲池里取
        conn = idlePool.poll();
        if (conn != null) {
            activeConnections.put(deviceAddress, conn);
            return conn;
        }
        // 都没找到，创建新的
        if (activeConnections.size() >= MAX_CONNECTIONS) {
            // 连接池满了，需要释放一个低优先级的
            evictLowPriorityConnection();
        }
        conn = new BleDeviceConnection(deviceAddress);
        activeConnections.put(deviceAddress, conn);
        return conn;
    }

    public synchronized void releaseConnection(String deviceAddress) {
        BleDeviceConnection conn = activeConnections.remove(deviceAddress);
        if (conn != null) {
            conn.reset(); // 重置状态，不关闭物理连接
            idlePool.offer(conn);
        }
    }
}

这个设计有几个好处：

  • 复用连接对象：避免频繁创建和销毁GATT实例，减少内存碎片。
  • 控制并发数：通过MAX_CONNECTIONS硬限制，防止系统过载。
  • 资源回收：连接池满了就踢掉低优先级的，保证高优先级设备能连上。

我的经验：连接池的大小不要设得太死。我一般会根据设备类型动态调整——比如手环这种常驻设备给固定名额，传感器这种临时设备用完后立刻释放。

10.3 连接优先级管理：谁先谁后得有规矩

连接优先级，说白了就是决定“哪个设备更重要”。我曾经遇到过一个场景：用户正在用手环测心率，这时候门锁突然要上报开锁记录，结果手环的数据就断了。你说气不气人？

我一般把设备分成三个优先级：

优先级 典型设备 行为策略
高（HIGH） 健康监测设备、门锁 抢占式连接，低优先级设备必须让路
中（MEDIUM） 传感器、遥控器 公平调度，不抢占但也不被轻易打断
低（LOW） 信标、广告推送设备 空闲时连接，随时可能被释放

实现上，我习惯用PriorityBlockingQueue来管理连接请求：

public class ConnectionPriorityManager {
    private final PriorityBlockingQueue<ConnectionRequest> requestQueue = 
        new PriorityBlockingQueue<>(11, Comparator.comparingInt(ConnectionRequest::getPriority));

    public void enqueueRequest(String deviceAddress, int priority) {
        requestQueue.offer(new ConnectionRequest(deviceAddress, priority));
        processNextRequest();
    }

    private void processNextRequest() {
        ConnectionRequest request = requestQueue.poll();
        if (request != null) {
            // 检查当前连接数，如果满了就踢掉最低优先级的
            if (connectionPool.isFull()) {
                connectionPool.evictLowestPriority(request.getPriority());
            }
            connectionPool.acquireConnection(request.getDeviceAddress());
        }
    }
}

注意：优先级不是一成不变的。比如一个低优先级的信标，如果它正在传输关键数据（比如固件升级包），就应该临时提升优先级。我一般会在连接对象里加一个dynamicPriority字段，根据当前任务动态调整。

10.4 断线重连策略：别让设备“失联”

断线重连，这是BLE开发里最让人头疼的问题之一。我记得有一次做运动手环项目，用户跑步时手环频繁断连，重连策略又没写好，结果用户跑了5公里，数据只记录了2公里……

断线重连的核心是“什么时候重连”和“怎么重连”。我总结了一套策略：

  • 立即重连：对于高优先级设备（如健康监测），断线后立刻尝试重连，间隔1秒、2秒、4秒……指数退避，最多重试5次。
  • 延迟重连：对于中优先级设备，断线后等待10秒再重连，避免频繁重连浪费资源。
  • 被动重连：对于低优先级设备，不主动重连，等设备再次广播时再连接。

代码实现大概是这样的：

public class ReconnectionManager {
    private final ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
    private final Map<String, ReconnectTask> taskMap = new ConcurrentHashMap<>();

    public void scheduleReconnect(String deviceAddress, int priority) {
        ReconnectTask task = new ReconnectTask(deviceAddress, priority);
        taskMap.put(deviceAddress, task);
        // 根据优先级决定初始延迟
        long initialDelay = (priority == PRIORITY_HIGH) ? 1 : 10;
        scheduler.schedule(task, initialDelay, TimeUnit.SECONDS);
    }

    private class ReconnectTask implements Runnable {
        private int retryCount = 0;
        private static final int MAX_RETRIES = 5;

        @Override
        public void run() {
            if (retryCount >= MAX_RETRIES) {
                taskMap.remove(deviceAddress);
                return;
            }
            boolean success = attemptReconnect(deviceAddress);
            if (!success) {
                retryCount++;
                long delay = (long) Math.pow(2, retryCount); // 指数退避
                scheduler.schedule(this, delay, TimeUnit.SECONDS);
            } else {
                taskMap.remove(deviceAddress);
            }
        }
    }
}

避坑指南：我曾经犯过一个错误——断线后立刻重连，结果设备还没准备好，重连失败后又触发新的断线回调，形成了“断连-重连-断连”的死循环。后来我加了cooldownPeriod（冷却期），断线后至少等500ms再处理，才解决了这个问题。

10.5 整体架构图

下面这张图展示了多设备连接管理的整体流程，从连接请求到资源调度，再到断线重连，一目了然：

多设备连接管理架构图 连接请求 优先级队列 高优先级优先处理，低优先级排队等待 连接池（最大5个连接） 高优先级：手环 中优先级：传感器 低优先级：信标 正常数据通信 断线重连策略 连接稳定 重连中（指数退避）

从这张图可以看出，整个流程是环环相扣的：连接请求先进入优先级队列排队，然后从连接池里分配资源，连接成功后正常通信，如果断线了就触发重连策略。每个环节都有对应的管理机制，缺一不可。

10.6 实战中的几个建议

最后，分享几个我在项目中积累的经验：

  • 别把所有设备都放在一个篮子里：如果设备数量超过10个，建议分多个连接池管理，比如按设备类型分池。
  • 监控连接状态：我习惯在连接池里加一个心跳检测，每隔30秒检查一次所有连接的健康状态，发现异常就主动重连。
  • 日志一定要打全：多设备连接的问题最难排查，我每次都会把连接、断连、重连、优先级变更等事件全部打日志，方便事后分析。
  • 测试要覆盖边界：比如连接池满了、所有设备同时断线、优先级反转等场景，这些在线上最容易出问题。

一个小技巧：如果你发现某个设备频繁断连，不要急着改重连策略。先看看是不是信号问题，或者设备端的蓝牙芯片有bug。我曾经花了两天调重连参数，最后发现是设备固件的问题……

好了，多设备连接管理这块就讲到这里。说白了，核心就是“管好资源、排好队、断线了别慌”。你只要把连接池、优先级和重连策略这三个东西设计好了，大部分场景都能应付。

← 上一章 📖 返回目录 下一章 →