像所有的網(wǎng)絡(luò)傳輸協(xié)議一樣，應(yīng)用層能感知到的丟包有可能產(chǎn)生于應(yīng)用層之下的所有層。

對于藍(lán)牙BLE而言，進(jìn)一步細(xì)化從機(jī)到主機(jī)的數(shù)據(jù)傳輸場景(假設(shè)使用的是Notify方式傳輸)，其數(shù)據(jù)傳輸路徑為：

1、從機(jī)的應(yīng)用層產(chǎn)生數(shù)據(jù)。

2、從機(jī)將數(shù)據(jù)從Host上位機(jī)轉(zhuǎn)交給Controller下位機(jī)。

3、從機(jī)Controller通過調(diào)制器，將數(shù)據(jù)在連接事件的射頻Tx階段發(fā)出。

4、主機(jī)Controller同時開啟射頻Rx階段，接收無線電波并通過解調(diào)器還原數(shù)字信號。

5、主機(jī)將數(shù)據(jù)從Controller下位機(jī)轉(zhuǎn)交給Host上位機(jī)。

6、主機(jī)的應(yīng)用層接收數(shù)據(jù)。

根據(jù)上面的流程，進(jìn)一步分析一下可能產(chǎn)生數(shù)據(jù)丟包的環(huán)節(jié)。

在步驟2中，Host調(diào)用HCI函數(shù)將數(shù)據(jù)提交給Controller發(fā)送之前，會先將數(shù)據(jù)存放在Controller的數(shù)據(jù)緩沖區(qū)中，不同的藍(lán)牙芯片這個緩沖區(qū)的大小不同，比如Ti CC2541的射頻緩沖區(qū)只有4個PDU(4*20字節(jié))的大小。在緩沖區(qū)存滿后繼續(xù)調(diào)用HCI的Notify等函數(shù)會返回緩存區(qū)滿狀態(tài)位標(biāo)識。這是第一個有可能產(chǎn)生丟包的位置，若緩沖區(qū)滿且開發(fā)者沒有對此狀態(tài)位進(jìn)行校驗，則應(yīng)用層產(chǎn)生的數(shù)據(jù)會在傳遞給鏈路層之前丟失。

在步驟3、4中，從機(jī)的Controller在連接事件的Tx階段，會通過射頻依次發(fā)送緩沖區(qū)數(shù)據(jù)，并在下一個Rx階段根據(jù)捕獲和解析對端主機(jī)的數(shù)據(jù)包，從其鏈路層報頭中讀取NESN來確認(rèn)其在上一個Tx階段發(fā)送的數(shù)據(jù)包是否被對端主機(jī)鏈路層正確接收。由于鏈路層數(shù)據(jù)包序列號校驗機(jī)制(SN和NESN)和重傳機(jī)制的存在，基本可以保證數(shù)據(jù)在物理層和鏈路層階段不會產(chǎn)生丟包，這跟互聯(lián)網(wǎng)的傳輸層TCP協(xié)議校驗數(shù)據(jù)包序列和完整性基本類似。

之所以上面用“基本”二字，是因為這里還是存在第二個有可能產(chǎn)生丟包的位置。由于BLE中使用的CRC校驗是弱CRC，其只能保障傳輸字節(jié)的全部偶數(shù)位和部分奇數(shù)位不產(chǎn)生錯誤，并無法保證所有數(shù)據(jù)在傳輸過程中不出錯。那么一個可能性極小的場景是：CRC弱校驗通過，但實際上NESN出現(xiàn)了錯誤，而將本來應(yīng)該是0的位識別成了1，或者相反。而這個位差錯讓本來應(yīng)該是錯誤的序列號交替變成了正確的。

在步驟5中，主機(jī)將數(shù)據(jù)從Controller向上派發(fā)到Host，并轉(zhuǎn)到應(yīng)用層觸發(fā)回調(diào)通知。這里是第三個可能產(chǎn)生丟包的地方。原因同步驟2，但這里還有一點小區(qū)別，就是notify跟indicate的區(qū)別(反向傳輸中的write with/without response也是同理)，其本質(zhì)區(qū)別是數(shù)據(jù)接收成功的判斷標(biāo)志是以鏈路層確認(rèn)為準(zhǔn)還是以應(yīng)用層確認(rèn)為準(zhǔn)。前者是notify采用的方式，而后者是indicate采用的方式。可見如果采用notify做數(shù)據(jù)傳輸，鏈路層到應(yīng)用層這一步依然是有丟包的可能，比如鏈路層的數(shù)據(jù)傳輸速率大于應(yīng)用層的回調(diào)函數(shù)中對數(shù)據(jù)處理的速率，導(dǎo)致Host中數(shù)據(jù)緩沖區(qū)持續(xù)增長，當(dāng)緩沖區(qū)滿后，主機(jī)的Controller將丟棄無法繼續(xù)保存的數(shù)據(jù)，并不會通知對端設(shè)備重傳。

而indicate方式下，每一個數(shù)據(jù)包的成功確認(rèn)都是以應(yīng)用層回調(diào)處理執(zhí)行完成為標(biāo)志，而通常數(shù)據(jù)的邏輯處理是一個耗時的操作，并且由于數(shù)據(jù)是在連接事件內(nèi)接受到，但同一個連接事件在開始的時候主從機(jī)兩端的數(shù)據(jù)就已經(jīng)準(zhǔn)備好，由于連接事件的持續(xù)事件極短，在這段時間內(nèi)Controller的所有工作都集中在射頻的發(fā)射上，而不會從Host上位機(jī)接受數(shù)據(jù)和響應(yīng)，甚至有的藍(lán)牙芯片會有選項在這段時間內(nèi)直接掛起CPU，以防止其他中斷信號同步到達(dá)，干擾到射頻數(shù)據(jù)的發(fā)送效率。所以在indicate方式下，一個數(shù)據(jù)包至少要橫跨兩個甚至更多的連接事件時長才可以確認(rèn)到達(dá)，從而發(fā)送下一個數(shù)據(jù)包，這就是有響應(yīng)的數(shù)據(jù)發(fā)送方式比無響應(yīng)要慢的原因。

最后一點，由于Android操作系統(tǒng)封裝了藍(lán)牙低層驅(qū)動和實現(xiàn)，以上的6個步驟即使都正確完成，也只是意味著Bluez或者Bluedroid這一層正確拿到了數(shù)據(jù)，但App要接收到這些數(shù)據(jù)還存在一個從操作系統(tǒng)到App的數(shù)據(jù)派發(fā)過程，indicate的數(shù)據(jù)確認(rèn)是在App得到數(shù)據(jù)派發(fā)并執(zhí)行完成回調(diào)后確認(rèn)，但notify會在Bluedroid接受到數(shù)據(jù)后即完成鏈路層確認(rèn)。而Bluedroid向App的數(shù)據(jù)派發(fā)又存在一個緩沖區(qū)，當(dāng)藍(lán)牙連接而App沒有運行的情況下緩沖區(qū)滿依然會產(chǎn)生丟包。(Android好像很難模擬這種情況，iOS在通過調(diào)試器終止App進(jìn)程的時候經(jīng)常會造成藍(lán)牙連接鏈路不同步斷開)