嗷o嗷o

做 BLE，很多人前期都会觉得收发数据没那么复杂。连上设备，拿到 characteristic，调一下写入，回调也能进，事情看起来就差不多了。 这种感觉一般持续到你第一次发长数据。

做 BLE 项目，最烦的阶段往往不是“连不上”，而是已经连上了，数据也开始回来了，结果页面状态还是一塌糊涂。

BLE 里有一种情况特别烦。 设备能扫到，也能连上，onConnectionStateChange() 进了，discoverServices() 也成功了，日志一眼看过去甚至有种“都好了”的错觉。

做 BLE 的时候，很多人第一次看到 notify 和 indicate，会觉得它们看起来差不多。 表面上也确实差不多。两者都是设备主动往手机推数据，Android 端通常都会在 onCharacte

做高通耳机 App，如果只面对单一设备、单一协议版本，事情通常还没那么复杂。你知道设备支持什么命令，知道 characteristic 怎么收发，知道回包长什么样，按这套协议一路写下去，很多功能都能跑

很多人第一次做耳机类 App，最容易把问题想得太简单。 一开始看起来，事情好像就是这样：手机扫到耳机，连上，读几个状态，发几个控制命令，最多再加个 OTA。表面上看，这套东西和普通 BLE 项目差不多

Android BLE 断开重连为什么越来越不稳定 Android BLE 最容易让人误判的一件事，就是第一次连接通常还挺顺，真正开始崩的是断开之后。 第一次扫到设备，连上，发现服务，开通知，发一条命

很多人第一次写 Android BLE，最先关注的 usually 是扫描。能不能扫到设备，权限有没有配对，UUID 有没有写错。 但 BLE 真正写到项目里以后，问题往往不是出在扫描，而是出在连上之

BLE 这个东西，看文档的时候总觉得不复杂。扫描设备，连上，发现服务，读写特征值，完了。 但真写 Android BLE，大家最常见的感受一般不是“终于连上了”，而是“怎么又没扫到”“怎么又 133