做 TWS 应用开发，到底需不需要懂协议栈？
刚接触 TWS 应用开发时，我一直有一个疑问：蓝牙协议栈大部分已经由芯片原厂封装好了，平时做功能主要是调用 SDK 接口、处理事件和编写产品逻辑，还有没有必要专门学习协议栈？
刚入行的时候，我也尝试过从头学习蓝牙协议。当时下载了一份 Bluetooth Core Specification 6.0，打开后看到整整 3815 页，心里压力一下就上来了。里面有大量英文术语、状态、命令和数据包格式，我硬着头皮看了几天，还是很难把规范里的内容和手上的代码对应起来，最后没有坚持下去。
工作两年左右，我对协议栈内部仍然谈不上有多深入的理解，平时接触最多的还是应用层代码。所以我现在的看法是：**需要了解一些，但没必要一开始钻得特别深。**这篇文章只是记录我目前在项目中用到的一些认识。
一、我目前主要关注什么
以我目前的工作内容来说，HCI、L2CAP 以及各个 Profile 的内部状态机，我其实没有深入研究。日常开发更常见的是调用 SDK 接口、接收事件，再根据产品状态处理业务。
为了不把不同问题混在一起，我会先记住几个和工作直接相关的区别：
- ACL 连接和 Profile 连接不是一回事。
- A2DP 负责音乐，AVRCP 负责播放控制和音量同步。
- HFP 负责通话控制，SCO/eSCO 承载通话语音。
- SPP 和 BLE GATT 常用于 App 数据通信。
- 接口调用成功，不一定代表异步操作已经完成，还要等待后续事件。
为了更直观地区分这些连接和业务，可参考蓝牙连接关系简化图：
图中把 GATT 单独放在 BLE 连接下。严格来说，协议内部的承载关系还要更细，这里只保留我在应用开发中经常接触到的部分。
我目前也就是先把这些常见概念分清。这样遇到异常时，至少知道先看哪一类状态，不至于一上来就把所有现象都归结成“蓝牙有问题”。
二、实际项目里，我能接触到什么
以我使用的中科蓝讯bt8910SDK 为例，工程里可以看到 A2DP、HFP、SPP 和 TWS 相关的配置及适配代码，但真正的核心实现主要由预编译的libbtstack.a提供。
应用层这边，A2DP 和 HFP 主要是调整部分参数、接收事件和处理业务回调；SPP 的 SDP Record 和数据收发回调可以看到并修改；GATT 可以添加 Service、Characteristic 和读写回调；TWS 这边则能做一些业务状态同步和主从切换处理。
所以按我目前的理解，这套 SDK 并没有把完整的 Profile 源码全部开放出来，而是提供配置、API 和回调，让应用层在上面实现产品功能。
实际排查时，我会先检查自己能看到的应用代码。如果接口已经调用，但一直没有后续事件，就把日志、版本和复现步骤整理出来，再请更熟悉协议栈的同事或芯片原厂继续确认。
三、不能只看手机上的“已连接”
我目前觉得最实用的一点，是不要把手机显示的“已连接”当成唯一状态。软件内部可能还要分别判断基础链路、A2DP 或 HFP、音频流、SCO、应用状态机以及 TWS 对耳状态。
这些模块内部怎样交互，我目前没有研究得很深。但先知道“连接成功”和“业务可用”不是一回事，对应用侧排查已经有帮助。
四、拿“连上但没声音”举个例子
如果手机显示耳机已经连接，但播放音乐没有声音，我会先从应用侧做几项比较基础的检查：
- 耳机是否处于入盒、通话、升级等不允许播放音乐的状态。
- 应用收到的是基础连接事件，还是已经收到 A2DP 连接和音频流启动事件。
- 收到事件以后，应用是否正确打开了音频资源，是否被提示音、ANC 或其他状态拦截。
- 单耳是否正常，问题是否只出现在双耳、特定手机或特定固件版本上。
如果音频流事件已经出现，但应用没有打开对应资源，我会优先检查应用逻辑；如果一直没有收到预期的 A2DP 事件，就只能结合更多日志或原厂信息继续确认。这只是应用侧的初步排除，还算不上完整的问题定位。
五、写在最后
以我目前接触到的内容来看，先把 SDK 接口用对、把应用状态理清，再了解与当前业务相关的 Profile 和事件流程，就已经比较实用。
协议栈更深层的原理，我目前仍在边做项目边补充。对现在的我来说，先弄懂用得到的部分，比试图一次读完整套规范更实际。