企业官网建设流程全解析

最近被好几个人问到同一个问题：BLE到底该用notify还是indicate，读写又和通知有什么区别，为什么有些项目传大文件卡成狗，有些项目明明连着却总丢数据。说实话，蓝牙低功耗（BLE）数据传输模式这个概念，新手一查文档就是GATT、ATT、Characteristic、CCCD一堆术语，很容易看懵。这篇文章准备把BLE开发里常见的数据传输模式全部放到一起做一次横向比较，讲清楚它们各自的原理、优缺点、适用场景和参数配置，最后附上我在实际项目中反复踩过的坑。无论你是刚接触低功耗蓝牙的嵌入式开发，还是做iOS/Android蓝牙应用的技术人员，这篇文章应该都能帮你少走不少弯路。

1. 看传输模式之前，先把BLE的通信底子捋顺

1.1 连接与非连接：两条完全不同的通信路线

很多人以为蓝牙低功耗就是“另一套蓝牙协议”，其实它的通信逻辑和经典蓝牙差别非常大。BLE的链路层有两大状态：一类是非连接的广播/扫描，另一类是建立连接后的双向通信。你可以把广播想象成收音机里的电台广播，发射端只管把数据放出来，谁要听谁自己去收，不需要“接通电话”；而连接模式就像两个人打电话，接通之后可以一来一回地说。

这两条路线的数据表现完全不一样。非连接方式的优势是功耗极低、不需要配对流程，但缺点是传输不稳定、不保证送达，而且数据量非常小；连接方式则能提供更高的吞吐量和更可靠的双向数据通道，但维持连接本身要耗电，也有连接间隔、超时这些参数需要处理。理解这一点，再看各种数据传输模式就不会晕：有的模式跑在非连接场景下，有的模式必须在连接状态下才存在，两者的设计目标从一开始就不同。

1.2 GATT才是各种传输模式真正落地的舞台

平时我们说的“BLE的read、write、notify、indicate”，其实并不属于链路层，而是GATT层的东西。链路层只负责把你的蓝牙数据包从一个设备搬到另一个设备，而GATT定义了一套“属性表”的规则：一个服务（Service）下面挂着多个特征（Characteristic），每个特征有属性（Properties）、值（Value）和一些描述符（Descriptor）。

一个Characteristic的Properties位，就决定了它支持哪种数据传输模式。比如属性值里配了NOTIFY，那这个特征就能主动给对端发通知；配了WRITE，那对端就能往这个特征写入数据。这里还有一个非常关键的描述符叫CCCD（Client Characteristic Configuration Descriptor），它专门用来开关notify和indicate。也就是说，即使你的设备把NOTIFY属性位打开了，客户端端如果不先把CCCD设成0x0001，设备主动发通知时客户端也收不到。这一点很多新手会忽略，以为把特征属性设成notify就万事大吉，结果手机端一直收不到上报数据。

ATT层还有一个绕不开的限制叫MTU。BLE默认的ATT MTU只有23字节，其中还要去掉3字节的ATT头，所以一个普通notification包最多只能带20字节用户数据。这也是为什么很多人第一次用BLE做固件升级、图片传输时会非常痛苦——一个包只能传20字节，不协商MTU的话，传个小文件都要跑半天。这些基础机制都理解之后，我们才能谈哪种模式适合什么场景。

1.3 选模式的四个判断维度：连接、可靠、吞吐、功耗

我在实际做项目时，判断一个数据传输模式是否合适，一般就看四个维度：是否依赖连接、是否保证可靠、能提供多高的吞吐、整体功耗是多少。这几个维度基本上决定了模式适合干什么活。

• 连接依赖：广播类模式不需要连接，适合信标广播、设备唤醒；GATT下的read/write/notify/indicate都需要连接。
• 可靠性：链路层在连接模式下其实有自动重传机制，但应用层是否确认是另外一回事。indicate有应用层ACK，notify没有，广播更谈不上可靠。
• 吞吐/时延：MTU大小、连接间隔、PHY速率、是否等待确认，这些都会直接影响单位时间能传多少数据。
• 功耗：功耗和连接间隔、广播频率、是否保持连接直接相关。为了省电而增加间隔，往往意味着时延变大、吞吐下降。

这四个维度放在一起，就能编织出一个选择框架。下面先用一张表快速对比一下主要的数据传输模式：

这张表只是个引子，具体到每种模式的细节，下一章逐个拆开讲。

2. 七个BLE传输模式逐个拆解：该什么时候用它们

2.1 Read 与 Write：一问一答的老实人

先看最常规的模式：Read和Write。它们的逻辑很直白——客户端请求读某个Characteristic，设备端返回当前值；客户端Write某个值，设备端收到后处理。适合做配置读取、状态查询、参数下发这类低频交互。

Write有两种形式：Write Request和Write Command。前者写完之后，设备必须回复一个Write Response，客户端收到响应才知道这次写成功；后者写完即焚，设备不需要回复，客户端也不确定设备到底收到没有。从GATT层看，Write Command更像后来notify的反向版本——数据单向丢过去，但不保证应用层确认。实际开发里，如果你需要“可靠地下发一条控制指令”，优先用Write Request；如果只是周期同步一个状态、且丢一次不影响大局，可以用Write Command省掉等待响应的时间。

Read还有一个隐藏机制叫Read Blob，用于读取长属性。一个Characteristic的值如果超过了ATT MTU能返回的长度，普通的Read请求会失败或只能返回前20字节，必须用Read Blob带偏移量继续读。这在对OTA参数、大段日志的读取场景里很常见。Write长数据也类似，可以用Prepare Write + Execute Write把一大段数据拆成多块连续写入，最后统一执行。很多系统协议栈会把超过MTU的写操作自动拆分，但建议开发者还是要对MTU有概念，别全指望协议栈。

2.2 Notify 与 Indicate：主动上报的两种姿势

大部分低功耗蓝牙项目里，最常用的其实是Notify和Indicate，因为设备通常是数据生产者，传感器一刻不停地采样，总不可能让手机每秒钟都来Read一次，那样既费电又浪费带宽。所以BLE设计了一个很巧妙的机制：设备端主动把数据推给客户端。

Notify叫通知，应用层不要求确认。设备端发出一个Notification，客户端收到了就收到了，不回复任何ACK。它的优点是吞吐高、时延低，很适合高频传感器数据流，比如心率、加速度、温度这类周期性上报。缺点也很明显：不保证送达，如果接收端当时处理不过来、缓冲区满，应用层就可能丢弃。要注意的是，BLE连接模式下链路层本身其实是有ACK和重传的，所以射频传输阶段的随机错误一般会被控制器重传掉；最常见的丢包其实是接收端没来得及读，队列溢出，或者连接参数不合理导致数据堆积。

Indicate则是带确认的通知。设备端发完之后，客户端必须回一个Confirm，设备端收到Confirm才会继续发下一条。这就让数据传输变得可控：每一条都确认，可靠性明显提升，适合设备主动上报的“关键事件”，比如跌倒报警、低电量提醒、门锁被异常打开这类需要确保送达的数据。代价是吞吐大幅下降，我在实测里用同一条链路，indicate的有效吞吐常常只有notify的一半左右，因为每个包都在等确认，等于把吞吐上限卡在了“一个来回的耗时”上。

所以选notify还是indicate，本质上是选“速度”还是“可靠”。我个人的习惯是：周期性数据一律notify，事情特别重要才用indicate，如果业务强度很大且都要保，再考虑把重要数据塞进indicate、把次要数据放notify，拆成多个Characteristic各走各的通道。

2.3 广播、周期广播和ISO同步信道：非连接传输的升级打法

很多人以为BLE就必须“先配对再连上再发数据”，其实非连接模式在很多场景里更香。普通广播Advertising，广播包最常用的是传统广播PDU，单包最多放31字节用户数据，你可以通过扫描请求返回额外的Scan Response数据，加起来最多62字节。智能灯泡、ibeacon、资产标签这类场景，本质上就是“定时把那一点点状态扔到空气里”，手机路过扫一眼就拿到了，不用连接，甚至不用配对。

BLE 5.0之后广播能力被拉大了很多，扩展广播（Extended Advertising）把每个PDU的数据上限扩大，理论上组合数据量上限大幅提升。更强的玩法是周期性广播（Periodic Advertising）：发射端在固定的时间点用固定间隔发送广播序列，扫描端可以先通过一个包含同步信息的广播包拿到同步参数，然后只在广播时刻醒来接收数据，其它时间继续睡觉，扫描端功耗能降得很低。这套机制很适合某些“N对1”场景，比如运动手表把心率数据周期性播给附近多个设备看。

再往上是BLE 5.2引入的同步信道ISO（Isochronous Channel）。ISO信道专为“时间敏感数据”设计，它能把数据包安排到固定的事件时序里，保证低抖动，支持无连接的广播同步流（BIS）和面向连接的同步流（CIS），LE Audio用的就是这套东西。如果你要传音频、实时操控数据，并且对时延抖动非常敏感，GATT那套轮询/通知模型往往不够看，ISO才是正道。不过ISO带来的是控制器和协议栈要求同步升高，不是所有老蓝牙芯片都支持，选型前一定先确认芯片和SDK的规格。

3. 实战选型：不同场景到底该用哪种模式

3.1 先排序业务需求，再谈选型

传输模式没有严格的好与坏，只有合不合适。我每次做方案都先列三件事：第一，数据能不能容忍偶尔丢失；第二，数据包平均多大、发送频率多高；第三，对时延的要求是秒级、毫秒级还是微秒级。这三项定了，模式基本就浮出来了。

如果数据丢了也没关系，且频率很高，那就notify；如果每条数据都要确认，数据量不大但重要，那就indicate；如果数据是请求后才有，比如用户点一下“读取当前档位”，那就read；如果是从手机主动下发控制指令，那就write request；如果想根本不用连接，就几个人看一眼数据，那就广播；如果是音频/高精度同步流，那就看芯片是否支持ISO。

这里有一个容易忽略的问题：业务需求可能混合出现。一个手环可能要同时上报心率数据（高频、可丢）和通知手机“手环找到了”（低频、重要）。这时候不要硬塞到一个Characteristic里，正确做法是拆成多个Characteristic，分别配不同的模式，比如一个带notify属性、一个带indicate属性，手机端开两个特征分开订阅。我见过很多项目为了省代码把所有数据走同一个notify特征，结果关键事件也在丢包里消失了，这个习惯很危险。

3.2 连接参数与PHY对模式效果的影响有多大

选对了模式还不够，参数配错了，模式效果照样拉胯。这里有一组最常见的参数，直接影响传输表现：

MTU是最先要协商的。默认23字节意味着每包只能传20字节用户数据。连接建立后主动发起MTU协商，能让单包数据传输量提升数倍。Android上requestMtu(247)很常见，iPhone上maximumWriteValueLength我测到的大概是182字节左右（对应ATT MTU 185）。如果你不做MTU协商，后面所有大包逻辑都绑手绑脚。

**连接间隔（Connection Interval）**决定两个连接事件之间隔多久。BLE允许7.5ms到4s之间，但很多手机协议栈会限制最小值。间隔越小，单位时间内两设备“碰面”次数越多，吞吐越高，但功耗也高；间隔越大，越省电，但数据时延越大。

**Slave Latency（从机延迟）**允许从设备跳过若干个连接事件，跳过期间不用醒来，对省电意义很大。但要注意，它也会显著增加实际时延，不适合高频上报。

**PHY（物理层速率）**方面，普通1M PHY是标配套路；如果传输量大，协商到2M PHY能让吞吐几乎翻倍；如果是为了穿墙和远距离，可以用Coded PHY，速率降到125kbps或500kbps，但接收灵敏度提升明显。很多开发者总是抱怨吞吐不够，查来查去发现用的是Coded PHY做大数据传输，那自然快不起来。

算一笔简单的吞吐账：假设MTU协商到了247字节，有效用户数据每包244字节，连接间隔30ms，每个连接事件内能挤4个包，忽略各种开销，理论吞吐大概是 4×244字节÷0.03秒，约等于32.5KB/s，换算成Kbps约260kbps，再乘8大概对得上。如果换成2M PHY，或者把连接间隔压到15ms、每个事件多塞几个包，吞吐立马就上去了。

3.3 五种典型场景的传输模式选型参考

参数只是起点，实际项目里要以芯片SDK和手机平台的支持范围为准，两端协商出双方都同意的值，而不是单方面硬设。以下一节要聊的问题，大都是参数没协调好造成的。

4. 故障排查与调优实录：这些坑我都替你踩过

4.1 通知丢包严重，问题出在连接参数和缓冲区

最典型的故障就是“notify明明在发，手机收到一半就没了”。我排查时会先看连接参数：连接间隔是不是被某个系统设得特别大，比如30ms以上或50ms；slave latency是不是被设成了大于0的值；从设备是不是还开着Coded PHY，125kbps根本背不动大量数据。把连接间隔调到合理范围、slave latency设为0、换成1M或2M PHY之后，丢包率往往马上降下来。

第二个排查点是接收端处理速度。很多手机端开发在蓝牙回调里做UI刷新、数据库写入，一个包还没处理完，下一个包就已经到了，系统队列一满就开始丢。正确做法是收到数据后立刻拷出来放到缓冲区，由后台线程统一处理，不要在接收回调里碰耗时的操作。从设备端也要注意，发通知之前要确认上一次大数据传输已经完成，不要一股脑塞给控制器。

还有一个隐蔽问题：部分系统会做流控，比如iOS在后台模式下通知频率会被限制，Android部分手机在Doze模式下也会拖慢蓝牙调度。遇到这种场景，要么在系统层面申请后台运行权限，要么把上报频率降下来，否则你就算把所有蓝牙参数调到最优，系统还是会悄悄地丢包。

4.2 MTU协商失败，大包传输直接卡死

大包传输失败，十有八九是MTU没协商好。我见过很多开发者写代码时假设“包大小就是20字节”，写一个小透明协议，结果一个128字节的数据被切成一堆20字节的小包，调试日志刷得飞起，交互慢到没法看。另一类相反，开发者直接发一个超长包，完全没协商MTU，结果对端一直收不到完整数据，又不知道问题在哪。

正确做法很简单：连接建立并完成服务发现后，先发起MTU协商，等双方确认新MTU之后再开始业务。Android端可以主动调用requestMtu并等待回调；iOS端通常会在内部自动协商，你可以通过maximumWriteValueLength(for:)来获取当前可写长度，再据此分包。如果不协商，就默认按最保守的20字节用户数据来写分包逻辑，这样才能保证尽量兼容老设备。

如果是做固件升级这种海量数据下发，建议直接用长属性写入或分块写入，并且每次写完一块都要等确认再写下一块。配合2M PHY和大MTU，OTA速度能从“龟速”提升到可用状态。记得在设备端和App端都把超时时间留够，控制器操作太多时，整批事务很容易被系统判定超时中断。

4.3 广播内容不全、参数请求被拒、连接被系统挂起

广播包内容不全也是常见坑。传统广播PDU只有31字节的广播数据，而这31字节里还要放flags、设备名称、服务UUID等一堆东西。很多开发者在里面塞了名称又塞了一堆自定义数据，结果广播出来的内容永远“少一截”。解决思路是：广播数据里只放关键的标志性数据，设备名称放进扫描响应里，或者干脆在广播包里不放名称，等手机连接后再通过GATT读取设备名。用扩展广播也可以，但前提是手机端和广播端都支持BLE 5.0的扩展广播特性。

连接参数请求被拒，多发生在连接刚建立不久就立刻请求一个特别激进的值。iOS、Android对连接参数都有各自的容忍范围，尤其是iOS，不符合其Acceptable Ranges的参数会被打回。我之前遇到一个项目，从设备把自己的连接参数设成7.5ms，Android连上后直接拒绝，iOS更是连参数协商都不给过。建议请求连接参数时，先在项目初期用主流手机实测一轮，挑一个兼容面最广的值，而不是一味追求最极端的性能。

连接被系统挂起又是另一类问题。移动端的省电机制会强行暂停无活动的蓝牙连接，如果设备端长时间不发数据也不响应用户操作，连接可能会在系统层面被挂起，看起来就是“连上了但是数据不来”。设备端可以定期发心跳或者让业务数据保持一定频率的流动；应用端则需要合理配置后台运行模式，别指望app退到后台还指望蓝牙全程满速。设备端还要注意supervision timeout的设置，必须满足大于2倍(连接间隔×(从机延迟+1))这个约束，否则短促的链路波动就可能让连接彻底断掉。

最后分享一个我自己的习惯：每次项目开始前，先把业务数据分类，重要事件哪怕用indicate慢一点也要保，周期数据用notify刷，大块数据传输单独开一个特征并用2M PHY去跑，广播只用来做设备发现和快速连接。做过几个低功耗项目之后我越发觉得，BLE的数据传输模式并不是互相替代的关系，而是一套组合拳，老老实实按业务需求去拆分它们，后面调优和排障都会省很多心思。