最近在开发ios平台的一款app过程中，遇到蓝牙固件升级这样的一个需求场景,从固件的线上版本比对、固件下载管理再到固件的安装写入步骤都要在app端完成。由于是第一次接触固件升级处理,所以在过程中也遇到了一些未知的坑,好在整个流程中,有丰富的三方框架支持，相对来说降低了一些难度以及省了不少的处理步骤,但还是忍不住来记录及分享几点内容,包括开发前期所要了解的蓝牙相关基础内容以及过程中所要注意的地方。
1.整个升级功能的流程简介
进入蓝牙模块的时候需要通过(A591)指令获取蓝牙设备的当前固件版本信息并和自己app服务器存储的最新的固件版本号对比,如果有新版本则下载，如果固件占用体积比较大并考虑到交互的话,下载模块中则需要支持断点下载,毕竟用户可能不是每次都有充足的的时间等待固件下载完成,如果每次进入app都要重新下载好像不太合适,所以在下载之前可以通过文件名判断本地是否已经存在文件而且还未安装,再通过（A590）指令让设备进入升级模式,再来将固件文件写入设备。
2.升级过程中需要注意的地方
A591命令在发送之后会获取到版本信息,这时候会发现一些奇怪的现象,设备的其它基础数据好像在返回上出了问题，比如数据明显少了很多,这时候需要A592指令对设备进行恢复;
A590指令在发送之后，设备会自行断开并且蓝牙名称以及mac地址都会改变,过程中获取电量信号等信息都可能为空,这都是正常现象,这时候需要用户app再次主动连接当前处于待升级的设备,由于设备名称和mac地址已经改变，那么如果找到这个设备呢,你会发现待升级的设备名临时固定变成(FirmWare)，所以可以通过此标记扫描连接设备;
待升级的设备会有一个比较长的状态持续时间，30s-2分钟都有可能,过了这个时间如果一直没等到文件写入，设备将会恢复到正常状态；我们的设备表现为红灯常亮;
固件文件写入并等到升级完成状态返回之后,设备将会再次自行断开,此时可以按照正常扫描连接流程处理;
固件文件写入我们用到一个比较常用的三方 IOS-Pods-DFU-Library ,可以通过pod导入或者本地导入,由于我的工程在使用过程中出了一点问题而选择了本地导入,只需要引入Classes内的文件即可,这个库依赖一个zip解压库,我选择了（pod 'ZIPFoundation', '~> 0.9'），注意DFU-Library这个库只是单纯用于固件写入的库，其它的处理都需要我们另外处理,比如说A590这个指令需要我们先发送再来使用这个库写入固件,我曾就在这个地方懵逼了半天,还以为这个库把所有的步骤都涵盖了呢,由于最后没出效果甚至怀疑这个库有问题，囧囧囧......;
一般比较提倡的做法是在固件写入之前校验一般完整性,因为可能在下载过程中被损坏，如果不校验就进行写入最终一般都会失败，虽然不至于导致固件被升坏但是这个流程我们控制得更合理一点, 这个地方的确可以作为我们优化的空间 ;
以上提到的A590 - A592等协议都是通用的协议,如果自家设备用的是自定义协议请忽略;
最后分享一下 DFU-Library 4.5.0版本的调用代码
网友评论