低功耗蓝牙（BLE）在物联网中的应用场景与系统设计要点

很多物联网项目在选型阶段会自然想到低功耗蓝牙（BLE）。原因很直接：手机原生支持、模块便宜、协议栈成熟。但项目真正跑起来后，问题经常集中在这几处：设备连接不稳定、电池掉得比预想快、距离稍微拉开就断连。这些问题的根源往往不在BLE本身，而在系统设计阶段对BLE的边界和参数理解不到位。这篇文章会围绕BLE在物联网里的真实适用场景，以及几个容易被忽视的设计要点展开，希望给已经准备用BLE或正在调试BLE的团队一些参考。

BLE不是“低功耗版蓝牙”，边界要先搞清楚

BLE的全称是低功耗蓝牙，但它并不是通过简单降低Wi-Fi功率做出来的技术，而是从协议栈到射频都针对间歇性、短距离、小数据量的通信重新设计的。BLE的物理层数据速率最高2Mbps，但实际有效吞吐量通常在几百kbps量级，传输大文件并不合适。覆盖范围室内一般几十米，穿墙能力也比较一般。真正让BLE站住脚的，是它与手机生态的无缝配合，以及极低的平均功耗。

技术	典型速率	覆盖范围	功耗	适用场景
Wi-Fi	数百Mbps	室内50m	高	视频、日志、OTA
BLE	2Mbps PHY	10~50m	低	可穿戴、门锁、传感器
Zigbee	250kbps	10~100m	低	智能家居、工业传感
LoRa	0.3~50kbps	1~5km	低	远距离抄表、定位

对比之后会有一个很直接的结论：BLE适合的场景，是那些以电池供电、数据量小、交互距离短、且希望手机能直接参与的物联网设备。如果你的数据量大或者覆盖距离远，BLE就不该排在选项前面。

BLE在物联网里的三种“面孔”

根据通信模式，BLE应用场景大致可以分成三类。

广播模式：设备只发广播包，不建立连接。典型如信标、资产标签、传感器周期上报。广播模式功耗最低，但不可靠，系统设计上要允许丢包。
连接模式：设备和手机或中心节点建立一对一的连接，进行双向通信。典型如手环、智能门锁、体脂秤。连接模式可控制性更强，但需要一方处于可发现状态，功耗相对更高。
网络模式：设备通过蓝牙Mesh组成多跳网络。典型如楼宇灯控、环境监测。Mesh适合控制类消息，不适合高吞吐的数据采集。

这三类场景对应的系统设计重点完全不同。广播模式的核心是广播间隔和广播内容长度；连接模式的核心是连接参数和事件机制；Mesh模式的核心是节点密度和消息转发策略。

场景一：一个做室内定位的团队，信标上报间隔设成了100ms，电池寿命预估两年，实际八个月就报低电量。排查后发现，广播包不仅塞了接近最大长度的数据，还启用了扫描响应，芯片每次广播事件的总唤醒时间比数据手册里的典型值高出一倍。功耗不是算出来的平均值，而是每一个细节叠加出来的实际结果。

场景二：一个做智能门锁的团队，第一版方案让门锁保持广播，手机靠近后通过连接解锁。结果实测待机电流始终降不下去，因为蓝牙要保持接收窗口才能侦测连接请求。后来他们加了独立的低功耗唤醒源，比如触摸传感器或加速度计，平时让蓝牙完全关闭，需要解锁时再唤醒。这就把门锁的待机功耗从毫安级降到了微安级。

系统设计要抠的五个环节

功耗建模：预算要留给“意外”

BLE宣传的功耗优势很容易让人忽略一个事实：平均功耗完全由使用方式决定。同一个模块，广播间隔100ms和10ms，平均电流可以差一个数量级。下面的Python脚本可以快速估算广播节点的平均电流和电池寿命。

def avg_current(interval_ms, event_ms, peak_ma, sleep_ma):
    duty = event_ms / interval_ms
    return peak_ma * duty + sleep_ma * (1 - duty)

# 广播间隔1000ms，每次广播事件1ms，峰值电流15mA，睡眠电流1uA
avg = avg_current(1000, 1, 15, 0.001)
capacity_mah = 240 * 0.7  # CR2032可用容量按70%折算
life_years = capacity_mah / avg / 24 / 365
print(f'平均电流: {avg * 1000:.1f} uA，预估寿命: {life_years:.1f} 年')

这个例子说明，广播间隔从1000ms改成100ms，平均电流会从约16uA涨到约151uA，电池寿命也会从大约2.7年缩到不足两个月。这就是很多设备在Demo阶段感觉好用，实际部署后电池很快耗尽的原因。

连接参数：两个旋钮要配合

对于连接模式，BLE功耗与连接间隔、从机延迟密切相关。连接间隔指中心设备和从机之间的连接事件的周期。从机延迟允许从机跳过若干次事件，从而减少监听开销，但代价是数据延迟变长。

实践经验是：宁可把连接间隔设得稍大，也不要让设备始终以最密集的间隔监听。对于大多数传感器上报场景，连接间隔设在30ms到100ms之间，配合从机延迟2到4，就能在功耗和响应之间取得平衡。

拓扑选择：星型比Mesh更可靠，除非你需要组网

很多团队一听Mesh就觉得可以覆盖很大的范围，实际上了规模才发现，Mesh的数据包要多次转发，节点越多丢包和时延越明显。蓝牙Mesh的本质是managed flooding，用于控制指令广播和群组控制非常合适，但用在高频传感器数据采集上就不太合适。一个做楼宇路灯控制的团队曾遇到过类似问题：网络几十个节点时一切正常，扩展到两百个节点后，控制指令时延明显变大，偶尔还有灯具不响应。最后发现是几个处于金属围蔽环境中的中继节点导致泛洪不断重传，挤占了消息通道。如果你的网络规模在几十个设备以内，且可以接受手机或网关做中心节点，星型连接往往实现更简单，功耗也更容易优化。

安全：默认配置通常不安全

BLE的配对方式里，Just Works最常见也最不安全，因为没有用户交互来防止中间人攻击。对于门锁、支付设备，至少要支持Passkey Entry或Numeric Comparison。另外广播数据默认是明文的，不要把设备唯一标识、设备状态等敏感信息直接放在广播包里。很多产品把MAC地址原样发出来，这等于给跟踪者开了后门。

2.4GHz频段的生存法则

BLE和Wi-Fi、Zigbee、USB3.0都挤在2.4GHz。BLE的跳频机制能躲开一部分干扰，但在Wi-Fi占用大量信道时，重传率会上升。设计阶段可以考虑两个操作：一个是启用2Mbit PHY，虽然接收灵敏度略有下降，但可以缩短发包时间，降低碰撞概率；另一个是让节点广播启动时间随机化，避免所有设备在整点或上电后同时广播造成碰撞。

四个常见的“想当然”

“手机一定能够稳定扫描到广播包。”实际上Android和iOS对蓝牙扫描的后台限制很严格，尤其是Android 6之后定位权限和扫描时间限制，必须适配。
“BLE Mesh可以传输数据。”它更适合控制指令，数据吞吐能力非常有限，大量数据上报会让网络拥堵。
“连接建立后数据就是实时的。”BLE的重传机制和不同厂商协议栈的调度，可能导致几十毫秒甚至几百毫秒的抖动，不能用于硬实时控制。
“广播不可靠，所以只用连接。”对于周期性上报，广播配合重复发送往往比维护一个长连接更省电，也更简单。