本人与2017年4月份从事蓝牙开发，加起来有半年时间，从零开始，独自封装CoreBluetooth到实现OTA，还是学到了不少东西的

当时公司项目是做心电监测的,实时采集心电数据.

项目是自己基于CoreBluetooth封装的, 没有采用第三方库， 这也是当时的Leader的要求.
原来没有做过蓝牙通信, 也是从头学起的, 好在iOS开发相对于简单一些, 接口封装的都比较简单实用, 不过这期间因为设备、高标准的需求, 也的确是遭遇了不少的挑战, 这一路走来也都逐个突破了.

最终查阅一堆资料, 最终是设备端采取的安全机制问题, 也因此查阅了蓝牙底层协议栈,对蓝牙进一步有所了解和掌握,虽然对于iOS开发上并无太大帮助,但对技术的积累，进一步的研究学习,相信今后还是有很大的帮助的,在学习过程中也发现很多从事蓝牙开发的iOS工程师,对蓝牙技术栈并不了解,或者了解; 也因此了解到, 虽然公司本质是做蓝牙硬件通信这方面的, 但是对蓝牙的技术储备还是存在遗漏的地方

这个也是棘手的问题, 从代码层又无从下手, iOS上又无法修改ATT_MTU_Size(或许底层上可以实现,但和很多从事这方面的人交流或者是查询很多资料后并未发现如何去实现),在最终无奈的情况下,邮件(芯片是板载的，板子是日本采购的，为什么是日本，因为公司CEO曾经在日留学，放弃了铁饭碗自己创业，其他一些高管和员工也都是跟CEO一起回国创业的)将我的疑问反馈给工厂那边, 那边又搪塞说啊啊啊你这个速度就已经很正常了...但是在最高波特率115200下的传输速度不稳这件事还是无法解决, 关于iPhone 7/plus新增的BLE extension功能有何提升,在速度上我也是没有看出明显变化, 总之这件事似乎也不了了之了

因为是做心电监测的, 时效性肯定是重中之重, 起初做项目的时候压根不知道要保证那么长的时间, 项目做出来了, 突然说出来这个需求,当时就有点冒冷汗了,自测一次最长时间是48h (原公司只有Android项目, 据说最早是外包的, 由于需要做iOS, Android自学后写出来的, 当时是蓝牙3.0, 因为MFI等一些原因被拒, 然后打算只做BLE 4.0,并专门招一个iOS), 算是达到了最低标准, 也松了口气, 而且项目内原来的一部分数据处理存在内存泄漏, 优化后还是有提升空间的

做蓝牙不得不提OTA, 也就是空中升级功能, 一开始并没有这个需求, 不过既然从事了蓝牙开发, 就在不断学习蓝牙中提早的了解了这方面的姿势, 在需求下来后, 因为硬件那边先要适配Android 3.0 , 所以我只能先按照规定下来的逻辑撸代码了, 最终在4.0设备适配好后, 在进行联调和优化, 好在准备充分,这块算是最顺利的, 我们的产品升级文件比较小,大概155KB的一个txt文件,这里要提一下,网上很多资料都说iOS发送文件长度超过20Byte就会丢掉,我分别按照20Byte、50Byte、70Byte和150Byte等调试过, 除了50、70Bye丢包率严重外,150Byte最为稳定, 并不像网上说的那样, 既然单个包的大小我定位了150Byte,这里面还会包含于硬件规定好的协议头、尾等8Byte, 这样数据部分是142Byte, 所以将原始文件每142Byte拆出来加上协议8Bye组成一个个150Byte的包, 一次完整的升级文件大概被分成1093个包左右, 2min中内完成, 而且在我连续几十次的不断测试下,才会出现几个丢包, 这主要与设备频繁的执行OTA过程,设备发热等原因有关, 如果只是一次或者几次的执行OTA过程, 基本上可以保证丢包率为0