CSR867x — 从“吃一堑”中说说我对老外做事的看法
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XX 作 者：ZHS（文化人）
XX 联系方式：点击置顶文章（或进群：471144274）
XX 版权声明：原创文章，欢迎评论和转载~转载时能告诉我一声就最好了
XX 要说的话：作者水平有限，难免有不足之处，恳请指正！
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
写在前面：笔者负责一个TWS音箱（CSR8670）的项目，需要通过BLE连接IOS版的APP。
在项目开发过程中，经历了你来我往，各种需求的添加，各种问题的解决~总算一步步走过来了，包括与项目的IOS版APP（国内开发）的调试对接也都非常顺畅。在项目接近尾声的时候，客户想把软件用到另外一个项目（称为项目B）中，于是直接对接了项目B的IOS版APP（老外开发），发现连接不了~咯咯了。
项目B的IOS版APP（老外开发）是跟旧版软件对接的，连接和通信都没有问题，于是笔者就拿到旧版软件，对比新旧软件的差异。结果发现：
1、广播包的数据不同：
因为笔者拿到的需求一直是APP要指定蓝牙名称进行连接，所以广播数据就只包含了“蓝牙名称”+其他信息，而旧版软件的广播数据是按照“蓝牙名称+服务UUID”的格式去设置的；
所以就重新改了新软件的广播数据，果然能够连接了，But数据收发还是有问题。
2、连接后的Primary服务顺序不同：
这一点是出乎笔者意料的，正常来说连接之后是可以获取所有服务的Handle，根据所需的服务就可以收发数据了。因为实在是想不出别的原因，只能尝试修改了Primary服务的显示顺序，结果一测果然OK。
3、贴一段客户跟老外的沟通内容
Not clear if this is supposed to be final implementation, but it causes me to violate Apple’s recommended practices:
When you do, the central manager returns only peripherals that advertise the services you specify (recommended).
If the serviceUUIDs parameter is null, all discovered peripherals are returned regardless of their supported services (not recommended).
In other words, instead of being handed (from CoreBluetooth) the precise ServiceId I want to connect to, I need to crawl through the devices, and query their services to find the one I want. As above, Apple recommends against this for performance and excessive battery use reasons.
老外遵从苹果公司出于性能和过度使用电池的原因而给出的建议。
苹果公司推荐的做法是扫描服务，他觉得我的软件使他违反了苹果的推荐实践。
当时就来了一句wtf~一个词语就出现在了我的脑海中，但同时又有另外一个声音说：不，这不是死板！这是严谨！！