Biu~哈喽大家好，续上回剧情，Earbud拥有良好的同步机制，两只耳机之前会同步诸多状态，很多动作也依赖这些同步的状态，所以同步直接的通讯尤其重要。很多客官在开发的时，想必也想利用这种通讯机制完成自定义的通讯控制，简单的方法就是在原有同步状态的函数中加入自己定义的数据同步过去，是可以的，冇问题。但不觉得同步的数据多吗？数据获取和解析需要时间，有的数据还要触发动作，也需要时间，这样不太好用。认真看看代码，其实还有别的用法。
发送同步时会调用appPeerSigMsgChannelTxRequest去将数据发出去，里面的参数中，有一个peerSigMsgChannel枚举的参数，这里枚举了三个参数，实际用了两个，而同步就是用了其中的PEER_SIG_MSG_CHANNEL_PEER_SYNC，还有一个PEER_SIG_MSG_CHANNEL_SCOFWD用来干嘛呢？身为问题少年的小编，绝不放过任何一个可疑数据，可疑就要问为什么，就要去找原因。顺藤摸瓜，一层层往上找时，发现另外一种枚举类型av_headset_scofwd_ota_messages
因缺思厅，都是些控制消息，这些信息都是通过OTA（不是升级的OTA哈，是Over The Air）发送给对耳处理，可以只是个消息，也可以带上参数，amazing~这不是跟即时通讯差不多吗？方便，实用。下面认真分析一下整个逻辑。
- peerSigMsgChannel中申明的是用于区分发送个peer消息的
类型，每个channel都会注册自己的task来处理各自channel的消息（用appPeerSigMsgChannelTaskRegister注册）
- appPeerSigMsgChannelTxRequest里面带上该channel，对方就按该channel的方式处理
- 然后发送的指令数据什么的，都是这个channel上流通的一个个数据而已
- 在接收方，因为已经注册了channel的task，接受消息后识别，分派给对应的task
- appScoFwdHandlePeerSignallingMessage将数据解析出指令部分和数据部分
了解完整个流程，就可以发各种自定义消息，是在原有的OTA channel加还是自定义一个新的channel，都无所谓。建议是新建一个，这个样好管理自己的消息。默认SFWD OTA channel别看他有很多函数，其实就只要的那一两个而已，其他都是封装再封装，形成简单的API，方便使用而已。不多说了，好好玩玩吧，See you~~
多看文档，多上官网
多看文档，多上官网
多看文档，多上官网
评论