企业官网建设流程全解析

搞BLE开发这几年，说起“Default Connection Interval”这个默认连接间隔，真的是让我又爱又恨。有一回我调一款基于BLE的心率臂带，设备连上手机之后，测量端电流怎么都压不下去，续航直接砍半。抓包一看，连接间隔死死停在30ms，跟固件里写的默认值完全不是一回事。后来折腾了好几天才搞明白，这个“默认值”根本不是外设自己说了算，中间隔着一整套连接参数协商的逻辑。

这篇文章就把连接间隔这个事从头到尾讲透。你会搞清楚它到底是怎么定义的、由谁决定、对功耗和延迟影响有多大，以及在不同平台上该怎么查看和调整。不管是刚接触BLE的嵌入式新手，还是被Android/iOS连接参数折磨过的老开发，都应该能从里面找到能直接落地的经验。

1. 连接间隔到底是个什么东西

1.1 一次让人抓狂的调试经历

先说我开头提的那个臂带项目。那款产品用的是一颗Nordic nRF52832芯片，固件里初始化GAP连接参数时，我按经验把最小连接间隔设成15ms，最大设成30ms，从设备延迟设成0，监督超时设成2000ms。按理说这个配置不算激进，属于很常规的范围。

可是设备连上手机之后，我用nRF Connect一查实际连接参数，发现连接间隔是30ms，从设备延迟是0，监督超时是2000ms。最让我困惑的是，不管我怎么改固件里的默认值，实测都纹丝不动。后来我才反应过来，问题出在手机这个Central端：它发起连接时用的是它自己期望的一组参数，而我外设固件里的“默认值”只是被动接受，得靠主动发连接参数更新请求才能改过来。

这个案例特别典型，几乎所有BLE开发者都会撞上类似的问题。核心原因就是对“连接间隔”这个概念的理解还停留在表面：以为它只是GAP初始化配置里的几个数值，实际上它在连接建立的过程中经历过一次双向协商，真实值不一定等于你配置的默认值。

1.2 连接事件的运作机制

要理解连接间隔，得先知道BLE连接是怎么运作的。BLE虽然叫“低功耗蓝牙”，但两个设备连上之后并不是一直在传输数据，而是在时间轴上切成了一个个“连接事件”。

打个比方，假设你和朋友约好每30秒通一次电话，每次通话持续3秒。在这3秒里你们可以连续说好几句话，说完就挂断，然后各自该干嘛干嘛去。BLE的连接事件就是这个“通话时间”，连接间隔就是两次通话开始之间的间隔，比如30ms。

一个连接事件里，Central和Peripheral可以来回传多个数据包，不需要每次都重新建立连接。连接间隔的单位是1.25ms的整数倍，规范上允许的范围是7.5ms到4s。比如你要设置30ms的间隔，那对应的参数值就是30 / 1.25 = 24个时间单位。

这里还有两个容易混淆的参数：从设备延迟（Slave Latency）和监督超时（Supervision Timeout）。从设备延迟表示Peripheral在多少个连接事件里可以“偷懒”不回应。比如Slave Latency=4，意味着Peripheral可以连续跳过4个连接事件不回复，等第5个事件再响应。如果设备只是周期性地传点传感器数据，适当拉大这个值能大大省电。监督超时则是双方判断连接是否还活着的看门狗时间，如果超过这个时间没收到任何有效数据包，连接就被判定为断开。

三者之间还有个硬性约束：监督超时必须大于有效连接间隔的2倍。其中有效连接间隔等于 (1 + Slave Latency) × 连接间隔。这个关系式后面讲问题排查时还会用到。

1.3 默认值的“坑”在哪

聊回“Default Connection Interval”。在BLE协议栈里，开发者通常会在初始化代码里配置一个期望的连接间隔范围，这就是很多人理解的“默认值”。但这里有两个关键点容易被忽略。

第一，这个值只是“期望值”，实际连接参数要等连接建立后，由Central端和Peripheral端协商确定。Central发起连接时会带一组自己期望的参数，Peripheral如果觉得不合适，可以发起参数更新请求，但最终决定权在Central手里。

第二，不同协议栈的默认行为差异很大。有的协议栈在连接建立后会自动发送一次参数更新请求，把外设配置的默认值推给手机；有的则完全不做这件事，外设只能默默接受手机给的参数。这就解释了为什么很多开发者改了默认值却感觉“没生效”——实际上参数更新请求压根没发出去。

所以，想真正掌握连接间隔的控制权，光会配置还不够，还得理解协商流程和各个平台的脾性。

2. 从连接到协商：连接参数是怎么定下来的

2.1 连接建立时的那场“谈判”

BLE连接建立的流程大概是这样的：Peripheral在广播，Central扫描到之后发一个连接请求（CONNECT_IND），这个请求里就带着Central期望的连接参数，包括连接间隔的最小值、最大值、从设备延迟、监督超时。

此时Peripheral有两种选择。一种是直接接受这些参数，连接进入稳定状态；另一种是觉得参数不合适，在连接建立后发一个“连接参数更新请求”（Connection Parameter Update Request），请Central把参数调整到Peripheral期望的范围。这个请求走的是LL Control Procedure或者L2CAP层的Connection Parameter Update Request，具体路径取决于协议栈实现。

我在实际开发里的体会是，很多外设固件默认选择“直接接受”，因为这样代码最简单。但如果你做的是低功耗产品，或者需要高频数据交互，就必须主动发起参数协商，否则就只能被手机的默认策略牵着走。

2.2 参数更新请求：外设的一次主动出击

以Nordic SDK为例，发起连接参数更新请求的接口是sd_ble_gap_conn_param_update，传入一个结构体，里面包含最小间隔、最大间隔、从设备延迟和监督超时。

ble_gap_conn_params_t conn_params = {0}; conn_params.min_conn_interval = MSEC_TO_UNITS(15, UNIT_1_25_MS); // 15ms conn_params.max_conn_interval = MSEC_TO_UNITS(30, UNIT_1_25_MS); // 30ms conn_params.slave_latency = 0; conn_params.supervision_timeout = MSEC_TO_UNITS(4000, UNIT_10_MS); // 4000ms uint32_t err_code = sd_ble_gap_conn_param_update(m_conn_handle, &conn_params);

需要特别注意的是调用时机。连接刚建立的头几百毫秒里，链路还在稳定阶段，此时立刻发参数更新请求，有些Central端会选择忽略，甚至直接拒绝。我个人的经验是延迟1到2秒再发，成功率会高很多，尤其是对接Android手机时。

另外，连接参数更新请求不是发一次就能一劳永逸。在连接生命周期内，如果业务模式发生变化——比如从低功耗待机切换到高速数据传输——可以再发起一次更新。但要注意频率，频繁请求容易被系统判定为异常行为，Android端尤其敏感。

2.3 常见协议栈和平台的默认参数参考值

我在调试中积累了一些常见平台/协议栈的默认表现，整理成了一张表，信息仅供参考。实测值会因设备型号、协议栈版本和OEM修改而有所不同。

从表格可以看出来，Android和iOS的系统行为几乎是绕不开的坎。后面我会单独讲怎么在应用层尽量争取到理想的参数。

3. 在真实设备上查看和调整连接间隔

3.1 用nRF Connect快速检查当前连接参数

排查连接间隔问题，第一步永远是“眼见为实”，先看看设备当前的实际连接参数。我常用的工具是nRF Connect，不管是Android版还是桌面版都行。

操作步骤很简单：打开nRF Connect，扫描到目标设备，点击连接。连接成功后，在设备信息页面通常能看到当前连接的参数，包括Connection Interval、Slave Latency和Supervision Timeout。如果软件版本显示不全，可以尝试断开重连，或者在设备刚连接的几秒里快速查看。

如果手头有nRF Sniffer配合Wireshark，还能看到更完整的空口数据包。比如Central发送的CONNECT_IND里带的初始参数、后续的连接参数更新请求和响应。这种抓包方式能帮你确认“外设到底有没有发请求”“手机有没有拒绝”，是定位问题的终极手段。

3.2 Android开发中如何主动请求期望的连接间隔

Android应用作为Central时，可以通过BluetoothGatt.requestConnectionPriority向远端外设请求特定优先级的连接参数。这个方法有三个预定义值：

// 高优先级：连接间隔约7.5ms~15ms，适合低延迟交互 gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH); // 平衡优先级：连接间隔约30ms~50ms，系统默认水平 gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_BALANCED); // 低功耗优先级：连接间隔约100ms~125ms，适合后台低频率通信 gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER);

注意，这只是“请求”。远端外设如果不同意，实际参数是不会变的。我遇到过一些外设固件写得不规范，收到请求后不响应，结果Android端怎么请求都没用。

另外，Android 13之后requestConnectionPriority的调用频率和时机也受系统限制。连续多次调用会被忽略，甚至触发系统的“BLE滥用检测”。所以不要在对端没响应时反复重试，最好先确认对端确实支持参数更新。

3.3 iOS为什么“不让你改”

iOS的CoreBluetooth框架中，开发者基本没办法直接指定Central端的连接间隔。你用CBCentralManager连接外设时，系统会根据外设的广播类型、特征交互频率、应用在前台还是后台等因素，自动选择一个合适的连接参数。

这对开发者来说挺憋屈的，因为你无法在代码里像Android那样写一行requestConnectionPriority。但实际测试中我发现，iOS系统通常能把连接间隔维持在15ms~30ms这个区间，对于大多数交互场景够用。如果非要追求更低的延迟，一个偏方是让外设通过GATT特征主动多传数据，系统检测到数据频度高，可能会自动缩短连接间隔。

从Peripheral端反向操作也有用。iOS设备作为外设时，CBPeripheralManager同样没有公开API去调整连接参数。所以，如果你是被iOS连接的一方，不要指望能主动改参数，只能从自己的广播间隔、连接事件内数据包数量上做文章。

3.4 固件侧如何设置一个靠谱的默认值

固件侧才是真正能“掌控命运”的地方。还是以Nordic为例，通常在gap_params_init阶段配置连接参数。这里有一个很容易踩的坑：你配置的只是一个范围，系统会在这个范围内选择一个值发给Central。如果Central不同意，实际值可能完全不在这个范围内。

static void gap_params_init(void) { ble_gap_conn_params_t gap_conn_params = {0}; gap_conn_params.min_conn_interval = MSEC_TO_UNITS(15, UNIT_1_25_MS); gap_conn_params.max_conn_interval = MSEC_TO_UNITS(30, UNIT_1_25_MS); gap_conn_params.slave_latency = 0; gap_conn_params.supervision_timeout = MSEC_TO_UNITS(4000, UNIT_10_MS); sd_ble_gap_conn_param_update(m_conn_handle, &gap_conn_params); }

对于ESP32，可以用esp_ble_gap_update_conn_params接口，传入一个esp_ble_conn_update_params_t结构体：

esp_ble_conn_update_params_t param = {0}; param.latency = 0; param.min_int = 12; // 15ms (12 * 1.25ms) param.max_int = 24; // 30ms (24 * 1.25ms) param.timeout = 400; // 4000ms (400 * 10ms) esp_ble_gap_update_conn_params(&param);

这里有个小提示：ESP32的min_int和max_int单位就是1.25ms，而timeout单位是10ms。不同协议栈的单位不一样，写代码前一定要看清楚头文件注释，别把30当30ms传进去，实际成了37.5ms。

我自己的习惯是：在产品固件里把期望连接间隔范围写成一个全局可配置的结构体，默认值根据产品形态来定。实时交互类设备用7.5ms~15ms，周期性数据上报设备用50ms~100ms加从设备延迟，纯待机唤醒型设备用200ms以上。这样后续调参只需要改一个结构体，不用满工程翻宏定义。

4. 连接间隔的“三角取舍”：功耗、延迟、吞吐量

4.1 功耗计算：不要小看每次唤醒的代价

连接间隔直接影响设备的平均功耗。BLE能省电，靠的是大部分时间深度睡眠，只在连接事件到来时短暂唤醒收发数据。唤醒次数越少，平均电流就越低。

举个粗略的例子。假设一个连接事件里实际收发数据的时间为3ms，事件期间平均电流15mA，睡眠电流2uA。如果连接间隔是30ms，那每秒约有33个连接事件，平均电流大概是 15mA × (3ms/30ms) + 0.002mA ≈ 1.5mA。如果把连接间隔拉到100ms，平均电流就只有 15mA × (3ms/100ms) + 0.002mA ≈ 0.45mA。两者相差3倍多。

如果把从设备延迟也利用起来，比如Slave Latency=9，设备每10个连接事件才醒一次，等效唤醒间隔变成300ms，平均电流能进一步降到0.15mA左右。对于CR2032纽扣电池供电的产品，这个差距可能就是“能用一个月”和“能用半年”的区别。

4.2 延迟：为什么按了按钮没反应

连接间隔还直接影响数据上报的延迟。假设外设采集到一个数据，要推给手机，最坏情况是多长时间？答案是约等于当前连接间隔的时长，因为外设要等到下一个连接事件才能把数据发出去。如果连接间隔是100ms，那么一次按键事件最多可能要等100ms才被手机收到，体感上就有“迟钝”的感觉。

交互式应用，比如遥控器、游戏手柄、空中鼠标，连接间隔尽量保持在15ms以内，或者至少30ms以内。传感器周期性上报类应用，比如温湿度计、心率带，延迟要求不高，反而可以拉大间隔加从设备延迟，在省电和时效之间找平衡。

4.3 吞吐量：一个连接事件能塞多少数据

连接间隔也决定了数据吞吐能力。BLE 4.0/4.1时单个数据包的有效载荷只有27字节，BLE 4.2引入数据长度扩展后最大能到251字节。一次连接事件里可以传多个包，但总时长受限于连接事件长度。

简化估算一下：假设一次连接事件能传6个包，每包有效载荷243字节（含LL层开销略少），连接间隔7.5ms，理论最大吞吐约为 6 × 243 × (1000/7.5) ≈ 194KB/s，约1.55Mbps。如果把连接间隔拉到30ms，同样的事件内包数，吞吐就掉到约48.6KB/s。当然这没有考虑空包、错误重传和调度开销，实际会低不少，但足以说明连接间隔对吞吐的影响之大。

需要说明的是，这个表是粗略参考，实际吞吐还受连接事件长度、蓝牙版本、双方协议栈实现、射频环境干扰等因素影响。

4.4 根据产品形态选择参数

结合上面的分析，我一般会按产品形态来做初始参数选择：

• 实时控制类（遥控器、游戏手柄、鼠标）：连接间隔7.5ms~15ms，Slave Latency=0，监督超时2000ms左右。这类产品对延迟敏感，功耗可以适当牺牲。
• 数据采集类（心率、血氧、环境监测）：连接间隔30ms~50ms，Slave Latency=3~9，监督超时3000ms以上。既能保证数据基本实时，又能省不少电。
• 低频上报类（智能标签、门磁、ibeacon类）：连接间隔100ms以上，Slave Latency尽量大，监督超时相应调大。这类产品大部分时间在睡觉，醒来才上报一次。

这个表不是标准答案，但它提供了一个思考框架：不要从代码里随便拷贝一组参数，而是从产品的功耗目标和延迟需求出发，反推应该配置什么。

5. 调试连接参数时踩过的那些坑

5.1 连接参数更新请求被无视或拒绝

这是最常见的坑。你固件里发了sd_ble_gap_conn_param_update，但手机端就是不响应，或者返回了“拒绝”。常见原因有几个。

第一，请求发太早了。连接刚建立，链路还没稳定，此时请求容易丢。我的习惯是收到BLE_GAP_EVT_CONNECTED之后，延迟1秒再发。第二，请求的参数范围违反了BLE规范。比如连接间隔设置成了非1.25ms整数倍，或者监督超时小于有效连接间隔的2倍，这种请求协议栈直接拒绝。第三，Central端策略限制。iOS比较典型，它会根据系统策略决定是否接受，很多时候压根不跟外设商量。

如果是固件是Peripheral，遇到请求被拒，可以尝试换个时机重发。但不要死循环重试，比如每100ms发一次这种操作，会把手机搞出兼容性问题。我一般是重试3次，每次间隔1秒，还不成功就接受当前参数。

5.2 从设备延迟设太大导致掉线

这是另一个高频问题，尤其是做低功耗产品的开发者容易踩。从设备延迟能省电，但它是把双刃剑。如果Slave Latency加得太大，而监督超时没有同步调大，设备很容易在睡眠中被判定为“失联”而掉线。

根据规范，监督超时时间必须大于 (1 + Slave Latency) × 连接间隔 × 2。比如连接间隔100ms，Slave Latency=9，那么有效连接间隔是(1+9)×100ms=1000ms，监督超时至少得设成2000ms以上。我在实际项目里一般会留1.5到2倍余量。比如上面这个例子，我会把监督超时设成4000ms或者6000ms，防止时钟漂移和射频干扰导致误判。

5.3 手机兼容性差异：同一套参数，不同手机表现不一样

BLE的参数协商非常依赖手机端协议栈实现。同样是Android手机，用某款旗舰机测试时，外设请求15ms连接间隔能被接受；换一台千元机，系统直接忽略请求，实际值变成30ms甚至90ms。这不是你的代码写错了，而是手机厂商对BLE协议栈做了自己的调度优化。

应对办法就是“尽早做兼容性测试”。手上有几台手机就测几台，至少覆盖高通、MTK、三星、华为/荣耀等主流SoC平台。我习惯做一个测试记录表，把每台手机实测得到的连接间隔、从设备延迟、是否接受参数更新请求、OTA吞吐量等记下来，作为调优依据。

5.4 排查思路：四步定位连接间隔问题

如果产品出现“功耗异常”“按键迟钝”“数据吞吐上不去”这类问题，怀疑和连接间隔有关，我通常按下面这个顺序排查。

第一步，先用nRF Connect连接设备看当前实际连接参数，确认和预期差多少。第二步，用Sniffer抓空口包，看连接建立时Central填了什么参数，外设有没有发参数更新请求，有没有收到响应。第三步，换不同手机重测，确定是平台问题还是固件问题。第四步，查协议栈日志，确认外设有没有进入连接事件、有没有抛异常事件。

这套流程看起来简单，但能覆盖大多数连接参数类问题。很多“玄学问题”到最后其实都是参数协商失败或者从设备延迟配置不合理。

6. 我个人最后想说的话

做BLE开发这么多年，连接间隔这个看似基础的概念，可以说是“水最深”的地方之一。它牵扯到BLE协议栈的底层机制、手机系统的调度策略、产品功耗和体感延迟的权衡，任何一个环节没考虑周全，都会让设备在用户手里变得难用或者耗电。

我自己的经验是，不要盲目信任协议栈的默认值，也不要把一套参数套用到所有产品上。连接间隔一定要结合产品形态来定，并且在固件里留出可配置的接口，方便后续OTA调参。在硬件的RF性能、协议栈SDK版本、手机兼容性之间做好平衡之后，BLE产品才能真正做到“低功耗”和“体验好”兼得。

最后再分享一个小技巧。如果你发现某个外设连接手机后参数一直不理想，可以试试在产品固件里做成“连接成功后延迟1~2秒发起参数更新请求，连续尝试3次，如果被拒就放弃”的策略。这个方案在我经手的十几个项目里都表现稳定，既能提升成功率，又不会因为频繁请求引发手机系统的兼容性问题。欢迎大家在评论区聊聊你们遇到的连接间隔怪事，也许你的经验正好能帮到另一个人。