在使用低功耗蓝牙（BLE）设备时，我们经常会遇到这些让人困惑的问题：

　　同一款手机，为什么能和某些设备正常连接，却连不上另外一些设备？

　　同一台BLE设备，为什么某些手机可以搜到并连接，另外一些手机却不行？

　　同样的手机和设备，为什么有时候连接很快，有时候又很慢？

　　Master、Slave到底是什么意思？

　　Connection event和Slave latency又该如何理解？

　　这篇文章将用清晰易懂的方式，完整讲解低功耗蓝牙设备连接的完整流程，帮你一次性解答所有疑问。

　　BLE连接示例

　　我们以一部安卓手机A，和一台名称为MS-BLE050F-L的低功耗蓝牙模块B为例，日常操作的连接步骤如下：

　　1.打开安卓手机的设置菜单

　　2.找到并进入“蓝牙”选项

　　3.打开蓝牙开关

　　4.等待系统扫描，设备“MS-BLE050F-L”会出现在搜索列表中

　　5.点击该设备名称，手机即可与设备建立蓝牙连接

　　我们在界面上看到的只是“点击连接”这个简单动作，但手机与设备MS-BLE050F之间，到底经历了怎样的通信过程？为什么能成功、又为什么会失败？下面我们一步步详细说明。

　　广播（Advertising）

　　在手机A（Observer，观察者）与设备B建立连接之前，设备B必须先持续广播。此时设备B作为广播方（Advertiser），会按照固定时间间隔t不断发送广播信号。每完成一次广播包发送，称为一次广播事件（Advertising Event），间隔t也被称为广播事件间隔。

　　虽然示意图中把广播事件画成一条线，但实际上广播事件有一定持续时间。蓝牙芯片只在广播事件期间打开射频电路，此时功耗相对较高，其余时间都处于空闲休眠状态，因此平均功耗非常低。以低功耗蓝牙模块MS-BLE050F（Nordic nRF52810）为例，每秒广播一次，平均功耗可以做到不到11μA。

　　上面只是简化示意图，按照蓝牙标准协议（spec），一次广播事件会在37、38、39三个射频信道上分别发送相同内容，真实的广播事件如下图所示：

　　设备B不断向外发送广播，但手机如果不开启扫描接收窗口，是无法收到广播的。只有同时满足两个条件，手机才能成功接收：

　　1.手机的接收窗口与设备的广播发送窗口在时间上刚好匹配

　　2.双方使用的射频信道完全一致（例如都在信道37）

　　也就是说，如果设备在信道37发广播，而手机正在扫描信道38，即使时间窗口对上，也无法通信。这种匹配是概率性的，所以手机搜到设备的速度时快时慢：可能只需要一个广播事件就搜到，也可能要等十几个广播事件才能成功。

　　建立连接（Connection Establishment）

　　蓝牙协议规定：广播方发送完一个广播包后，间隔150μs（T_IFS），必须打开一段射频接收窗口，用来接收观察者发来的数据包。手机就可以在这个窗口内发送连接请求。

　　如下图所示，手机在第三个广播事件时搜到设备B，并立即发送连接请求CONN_REQ（也叫CONNECT_IND）。

　　上面的流程比较简略，下图更完整地展示连接建立的详细过程：

　　图6：连接建立过程

　　注：图中M代表手机，S代表设备B；M→S表示手机发、设备收；S→M表示设备发、手机收。

　　手机收到广播包A1（ADV_IND）后，以这个时间点为初始参考，等待T_IFS后向设备发送连接请求包A2，告诉设备即将发起连接。CONN_REQ里包含几个关键参数：

　　Transmit window offset（发送窗口偏移）

　　Transmit window size（发送窗口大小）

　　CONN_REQ的作用，本质是通知设备：手机会在约定的发送窗口内发送第一个同步包P1，请设备在此期间打开射频接收。设备B收到P1后，会在T_IFS时间内回复ACK包P2。手机一旦收到P2，就代表连接正式建立成功。

　　实际使用中，手机可能收不到P2，这时手机会持续发送同步包，直到监控超时（Supervision Timeout）。只要在超时前收到一次ACK，连接就算成功。而Android和iOS系统有一个典型机制：只要手机发出P1，上层应用就会收到“连接成功”回调，并不等待设备回复P2。这就是界面显示已连接，但实际并未真正通联的原因。

　　连接建立后，BLE进入主从模式：

　　Master/Central：发起连接的一方（手机），负责主动发包、控制时序

　　Slave/Peripheral：被连接的一方（原广播设备），只能被动回复

　　连接后周期性传输的数据包，除了传输业务数据，还有两个关键作用：

　　1.同步主从设备时钟：设备每收到主机包，都会重置时序基准，保持同步

　　2.通知从机可以回传数据：从机不能主动发送，必须等主机发包后才能回复

　　连接失败的常见原因

　　1.从机未在约定窗口收到P1连接直接失败，优先排查主机（手机）的时序、发射或调度问题。

　　2.主机发出P1，但从机未回复P2设备收到同步包却没有应答，重点检查从机固件、硬件、时钟或电源稳定性。

　　3.收发正常仍提示连接失败多为主机或从机的协议栈、应用层逻辑异常，需要通过日志或抓包排查。

　　4.空中射频干扰过大2.4G干扰、遮挡、距离过远都会导致握手失败，可换到屏蔽室等干净环境复测。

　　Connection Events（连接事件）

　　连接成功后，主机和从机会以Connection Interval（连接间隔）为周期，进行固定交互。每一轮“主机发包→从机回复”的完整过程，称为一个Connection Event（也叫GAP Event）。

　　蓝牙芯片只在连接事件期间打开射频，其余时间休眠，因此功耗极低。以Nordic nRF52810为例，每秒交互一次，平均功耗约6μA。由于主机和从机并非时刻有数据要传，大部分交互都是空包（Empty Packet）。在一个连接事件内，主机也可以连续发送多个包，提高数据吞吐率。

　　图7：连接成功后通信时序（每个连接事件只发1个包）

　　图9：连接成功后通信时序（一个连接事件可发多个包）

　　图10：连接事件细节图

　　Slave Latency（从机延迟）

　　默认情况下，每个连接间隔到来时，主从都必须交互一次，哪怕只是空包。如果配置了Slave Latency，从机就可以跳过多个连接事件，只在指定次数后才醒来回复。

　　例如设置Slave Latency=9，从机可以在前8个连接间隔全程休眠，只在第9个间隔才回复主机，显著降低功耗、提升续航。如果从机有紧急数据需要上报，也可以不等待，直接在当前连接事件发送，兼顾低功耗与实时性。

　　GAP层角色总结

　　在BLE整个通信过程中，设备会根据状态切换不同角色，蓝牙GAP层定义如下：

　　Advertiser：发送广播的设备

　　Observer/Scanner：扫描广播的设备

　　Initiator：发起连接请求的设备

　　Master/Central：连接建立后的主机，主动发包

　　Slave/Peripheral：连接建立后的从机，被动回复

　　这些角色是相互独立的：一个设备可以只做广播、不接受连接；也可以只扫描、不发起连接。

　　图11：GAP层角色