最近在開發(fā)ios平臺的一款app過程中职辨，遇到藍牙固件升級這樣的一個需求場景,從固件的線上版本比對、固件下載管理再到固件的安裝寫入步驟都要在app端完成炕桨。由于是第一次接觸固件升級處理,所以在過程中也遇到了一些未知的坑,好在整個流程中,有豐富的三方框架支持秤朗，相對來說降低了一些難度以及省了不少的處理步驟,但還是忍不住來記錄及分享幾點內容,包括開發(fā)前期所要了解的藍牙相關基礎內容以及過程中所要注意的地方。
1.整個升級功能的流程簡介
進入藍牙模塊的時候需要通過(A591)指令獲取藍牙設備的當前固件版本信息并和自己app服務器存儲的最新的固件版本號對比,如果有新版本則下載光坝，如果固件占用體積比較大并考慮到交互的話,下載模塊中則需要支持斷點下載,畢竟用戶可能不是每次都有充足的的時間等待固件下載完成,如果每次進入app都要重新下載好像不太合適,所以在下載之前可以通過文件名判斷本地是否已經(jīng)存在文件而且還未安裝,再通過（A590）指令讓設備進入升級模式,再來將固件文件寫入設備。
2.升級過程中需要注意的地方
A591命令在發(fā)送之后會獲取到版本信息,這時候會發(fā)現(xiàn)一些奇怪的現(xiàn)象,設備的其它基礎數(shù)據(jù)好像在返回上出了問題甥材，比如數(shù)據(jù)明顯少了很多,這時候需要A592指令對設備進行恢復;
A590指令在發(fā)送之后盯另，設備會自行斷開并且藍牙名稱以及mac地址都會改變,過程中獲取電量信號等信息都可能為空,這都是正常現(xiàn)象,這時候需要用戶app再次主動連接當前處于待升級的設備,由于設備名稱和mac地址已經(jīng)改變洲赵，那么如果找到這個設備呢,你會發(fā)現(xiàn)待升級的設備名臨時固定變成(FirmWare)鸳惯，所以可以通過此標記掃描連接設備;
待升級的設備會有一個比較長的狀態(tài)持續(xù)時間商蕴，30s-2分鐘都有可能,過了這個時間如果一直沒等到文件寫入，設備將會恢復到正常狀態(tài)悲敷；我們的設備表現(xiàn)為紅燈常亮;
固件文件寫入并等到升級完成狀態(tài)返回之后,設備將會再次自行斷開,此時可以按照正常掃描連接流程處理;
固件文件寫入我們用到一個比較常用的三方?IOS-Pods-DFU-Library?,可以通過pod導入或者本地導入,由于我的工程在使用過程中出了一點問題而選擇了本地導入,只需要引入Classes內的文件即可,這個庫依賴一個zip解壓庫,我選擇了（pod 'ZIPFoundation', '~> 0.9'）究恤，注意DFU-Library這個庫只是單純用于固件寫入的庫俭令，其它的處理都需要我們另外處理,比如說A590這個指令需要我們先發(fā)送再來使用這個庫寫入固件,我曾就在這個地方懵逼了半天,還以為這個庫把所有的步驟都涵蓋了呢,由于最后沒出效果甚至懷疑這個庫有問題后德，囧囧囧......;
一般比較提倡的做法是在固件寫入之前校驗一般完整性,因為可能在下載過程中被損壞，如果不校驗就進行寫入最終一般都會失敗抄腔，雖然不至于導致固件被升壞但是這個流程我們控制得更合理一點, 這個地方的確可以作為我們優(yōu)化的空間 ;
以上提到的A590 - A592等協(xié)議都是通用的協(xié)議,如果自家設備用的是自定義協(xié)議請忽略;
最后分享一下?DFU-Library 4.5.0版本的調用代碼
