問題背景

客戶使用 BlueNRG-345MC 開發(fā)了一個(gè) BLE 外設(shè)，和手機(jī)連接。在測(cè)試中發(fā)現(xiàn)，手機(jī)連接上外設(shè)之后，不斷地在手機(jī)上點(diǎn)擊藍(lán)牙的開關(guān)按鈕，造成設(shè)備不斷地?cái)嚅_、重連；少則幾次，多則幾十次。點(diǎn)擊之后，必然出現(xiàn) BLE 外設(shè)無廣播信號(hào)的現(xiàn)象。該問題已經(jīng)得到了解決。本文將展開聊聊該問題的解決過程和思路，并就該問題總結(jié)、分享一些 BLE 連接過程的處理經(jīng)驗(yàn)。

定位問題

拿到該反饋描述后，第一時(shí)間和客戶溝通了幾個(gè)問題，明確了大概的方向。溝通的思路按照：硬件問題、軟件問題？硬件問題是和設(shè)備相關(guān)，板子相關(guān)、還是芯片相關(guān)？軟件問題根據(jù)設(shè)備類型，是和 APP 相關(guān)、手機(jī)系統(tǒng)相關(guān)、BLE 主機(jī)固件相關(guān)、還是 BLE 外設(shè)固件相關(guān)這樣的思路進(jìn)行排查。通過以下問題，粗略地進(jìn)行問題的定位：

“對(duì)端設(shè)備是什么，如果是手機(jī)的話，是否有 APP？“——對(duì)端是手機(jī)，并且有配套的APP。該問題確定了設(shè)備類型，和軟件類型。

“該問題是否必現(xiàn)，且穩(wěn)定復(fù)現(xiàn)，問題出現(xiàn)后，狀態(tài)是否能保持？“——問題穩(wěn)定復(fù)現(xiàn)且必現(xiàn)，而且狀態(tài)能保持，這是一個(gè)重要的依據(jù)，由此依據(jù)，我們可以進(jìn)一步發(fā)問：

“殺死配套 APP 的后臺(tái)，用其它手機(jī)、第三方 APP（BLE 調(diào)試助手等）是否能搜到設(shè)備的廣播信號(hào)“——?dú)⑺琅涮?APP 的后臺(tái)，確保設(shè)備斷連、處于廣播狀態(tài)，然后通過第三方的手機(jī)、APP 搜索設(shè)備的廣播，確定當(dāng)問題出現(xiàn)后，出現(xiàn)異常的是主機(jī)方、還是從機(jī)方?？蛻舴答伒谌?APP 搜索不到該設(shè)備，說明此時(shí)從機(jī)方出現(xiàn)了異常且保持在異常狀態(tài)中。

“問題出現(xiàn)后，設(shè)備是否還能正常運(yùn)行“——確定了從機(jī)方出現(xiàn)異常后，我們需要進(jìn)一步定位該異常。該問題可確認(rèn)問題是局部問題，還是系統(tǒng)問題。如果此時(shí)系統(tǒng)還能正常運(yùn)行（比如，有 LOG 輸出，有 LED 閃爍，有按鍵反應(yīng)等），就說明是局部問題，系統(tǒng)還沒死機(jī)。客戶反饋系統(tǒng)還正常，這真是一個(gè)好消息！藍(lán)牙問題最怕是系統(tǒng)性的問題，即因?yàn)橄到y(tǒng)奔潰，導(dǎo)致的藍(lán)牙奔潰，如果是系統(tǒng)性的問題，那可能性就多很多了，丟給客戶的問題就可能包括：

“是否和低功耗管理有關(guān)，關(guān)掉低功耗試試？”

“是否和特定板子有關(guān)，換塊板試試？”

“是否和供電穩(wěn)定性有關(guān)，用直流電源試試？電量低是否更容易復(fù)現(xiàn)？”……

既已確定了是局部藍(lán)牙的問題，那么，如果對(duì)藍(lán)牙的 LL 狀態(tài)機(jī)和基本的 GAP 流程熟悉的話，那基本就可以通過這個(gè)問題來定位該問題了：

“請(qǐng)仔細(xì)檢查下用戶層的操作邏輯，是否能確保藍(lán)牙斷連時(shí)，必能調(diào)用使能廣播的 API，且拿到成功的狀態(tài)返回？”——客戶拿到該問題后，不知道從何下手，于是，現(xiàn)場(chǎng)支持。

BLE 背景知識(shí)

話接上文，解決該問題需要對(duì) LL 狀態(tài)機(jī)和 GAP 流程有一定的了解。本章節(jié)便先對(duì)相關(guān)背景知識(shí)先做一個(gè)補(bǔ)充陳述。

藍(lán)牙鏈路層（Link Layer）的運(yùn)轉(zhuǎn)過程可通過一個(gè)狀態(tài)機(jī)進(jìn)行描述。

對(duì)于該狀態(tài)機(jī)的理解，需要注意以下幾點(diǎn)：

• 設(shè)備斷開連接之后，LL 層進(jìn)入的是 Standby 狀態(tài)，而不會(huì)自動(dòng)重新發(fā)起廣播，此時(shí)必須由 Host 主動(dòng)啟動(dòng)廣播才能讓設(shè)備被主機(jī)搜索到。

• 設(shè)備處于 Standby 狀態(tài)時(shí)，必須先進(jìn)入廣播狀態(tài)，才能由此進(jìn)入連接狀態(tài)。對(duì)于從機(jī)，如果設(shè)備不進(jìn)入廣播狀態(tài)，即使主機(jī)發(fā)起回連，也不可能被連接成功。

• 廣播中的設(shè)備，當(dāng)它被上層停止廣播、或者被主機(jī)連接時(shí)，便會(huì)退出廣播狀態(tài)。此處需要注意的是，當(dāng)鏈路建立，協(xié)議棧會(huì)將鏈路建立事件層層上傳，其中，就包括 GAP層 。GAP 層在接收到鏈路建立事件之后，便會(huì)開始執(zhí)行一系列的流程……

這些流程包括，特性交換流程，MTU 交換流程，連接參數(shù)更新流程，安全流程（配對(duì)流程、綁定流程、加密流程），GATT 服務(wù)發(fā)現(xiàn)流程等。剛連上那會(huì)的幾秒鐘，是 BLE 外設(shè)最繁忙的時(shí)間段，也是最容易出現(xiàn)問題的時(shí)間段。有經(jīng)驗(yàn)的工程師，一般都會(huì)將一些時(shí)間敏感的任務(wù)的處理，和這段時(shí)間段進(jìn)行錯(cuò)開。

解決問題

相信通過 BLE 背景知識(shí)的介紹，部分人已經(jīng)大概了解了問題的原因了。到達(dá)客戶現(xiàn)場(chǎng)調(diào)試時(shí)，通過藍(lán)牙抓包器、并讓客戶當(dāng)場(chǎng)復(fù)現(xiàn)問題，我把藍(lán)牙主、從機(jī)的空中交互過程記錄下來。仔細(xì)觀察抓包器的記錄過程，發(fā)現(xiàn)當(dāng)問題發(fā)生時(shí)，斷開連接的事件出現(xiàn)得非常早期：在鏈路建立、特性交換流程剛執(zhí)行完后，即發(fā)生了斷連。

小結(jié)

藍(lán)牙協(xié)議棧是個(gè)分層的協(xié)議，當(dāng)我們說藍(lán)牙已連接時(shí)，想表達(dá)的意思應(yīng)該是鏈路層鏈路建立，而現(xiàn)實(shí)中，很多工程師都把藍(lán)牙已連接理解成了可以收、發(fā)數(shù)據(jù)了。實(shí)際上，從藍(lán)牙鏈路建立，到協(xié)議?？梢詾橛脩魧邮?、發(fā)數(shù)據(jù)，中間還差了十萬八千里?？偠灾瑥谋疚牡慕忸}思路出發(fā)，我總結(jié)以下幾點(diǎn)經(jīng)驗(yàn)：

• 用戶程序應(yīng)該深刻理解“藍(lán)牙已連接”的概念， 做好狀態(tài)管理。
• 鏈路建立后是藍(lán)牙最繁忙的時(shí)刻，用戶任務(wù)處理應(yīng)盡可能避開該時(shí)間段。
• 加快鏈路建立繁忙時(shí)間段的方法包括：

o 鏈路建立后，使用較快的連接間隔，并在之后調(diào)慢以平衡功耗

o 使用 GATT CACHING 特性