395
問題背景
客戶使用 BlueNRG-345MC 開發(fā)了一個 BLE 外設(shè)，和手機連接。在測試中發(fā)現(xiàn)，手機連接上外設(shè)之后，不斷地在手機上點擊藍牙的開關(guān)按鈕，造成設(shè)備不斷地斷開、重連；少則幾次，多則幾十次。點擊之后，必然出現(xiàn) BLE 外設(shè)無廣播信號的現(xiàn)象。該問題已經(jīng)得到了解決。本文將展開聊聊該問題的解決過程和思路，并就該問題總結(jié)、分享一些 BLE 連接過程的處理經(jīng)驗。
定位問題
拿到該反饋描述后，第一時間和客戶溝通了幾個問題，明確了大概的方向。溝通的思路按照：硬件問題、軟件問題？硬件問題是和設(shè)備相關(guān)，板子相關(guān)、還是芯片相關(guān)？軟件問題根據(jù)設(shè)備類型，是和 APP 相關(guān)、手機系統(tǒng)相關(guān)、BLE 主機固件相關(guān)、還是 BLE 外設(shè)固件相關(guān)這樣的思路進行排查。通過以下問題，粗略地進行問題的定位：
“對端設(shè)備是什么，如果是手機的話，是否有 APP？“——對端是手機，并且有配套的APP。該問題確定了設(shè)備類型，和軟件類型。
“該問題是否必現(xiàn)，且穩(wěn)定復(fù)現(xiàn)，問題出現(xiàn)后，狀態(tài)是否能保持？“——問題穩(wěn)定復(fù)現(xiàn)且必現(xiàn)，而且狀態(tài)能保持，這是一個重要的依據(jù)，由此依據(jù)，我們可以進一步發(fā)問：
“殺死配套 APP 的后臺，用其它手機、第三方 APP（BLE 調(diào)試助手等）是否能搜到設(shè)備的廣播信號“——殺死配套 APP 的后臺，確保設(shè)備斷連、處于廣播狀態(tài)，然后通過第三方的手機、APP 搜索設(shè)備的廣播，確定當問題出現(xiàn)后，出現(xiàn)異常的是主機方、還是從機方?？蛻舴答伒谌?APP 搜索不到該設(shè)備，說明此時從機方出現(xiàn)了異常且保持在異常狀態(tài)中。
“問題出現(xiàn)后，設(shè)備是否還能正常運行“——確定了從機方出現(xiàn)異常后，我們需要進一步定位該異常。該問題可確認問題是局部問題，還是系統(tǒng)問題。如果此時系統(tǒng)還能正常運行（比如，有 LOG 輸出，有 LED 閃爍，有按鍵反應(yīng)等），就說明是局部問題，系統(tǒng)還沒死機。客戶反饋系統(tǒng)還正常，這真是一個好消息！藍牙問題最怕是系統(tǒng)性的問題，即因為系統(tǒng)奔潰，導致的藍牙奔潰，如果是系統(tǒng)性的問題，那可能性就多很多了，丟給客戶的問題就可能包括：
“是否和低功耗管理有關(guān)，關(guān)掉低功耗試試？”
“是否和特定板子有關(guān)，換塊板試試？”
“是否和供電穩(wěn)定性有關(guān)，用直流電源試試？電量低是否更容易復(fù)現(xiàn)？”……
既已確定了是局部藍牙的問題，那么，如果對藍牙的 LL 狀態(tài)機和基本的 GAP 流程熟悉的話，那基本就可以通過這個問題來定位該問題了：
“請仔細檢查下用戶層的操作邏輯，是否能確保藍牙斷連時，必能調(diào)用使能廣播的 API，且拿到成功的狀態(tài)返回？”——客戶拿到該問題后，不知道從何下手，于是，現(xiàn)場支持。
BLE 背景知識
話接上文，解決該問題需要對 LL 狀態(tài)機和 GAP 流程有一定的了解。本章節(jié)便先對相關(guān)背景知識先做一個補充陳述。
藍牙鏈路層（Link Layer）的運轉(zhuǎn)過程可通過一個狀態(tài)機進行描述。
對于該狀態(tài)機的理解，需要注意以下幾點：
- 設(shè)備斷開連接之后，LL 層進入的是 Standby 狀態(tài)，而不會自動重新發(fā)起廣播，此時必須由 Host 主動啟動廣播才能讓設(shè)備被主機搜索到。
- 設(shè)備處于 Standby 狀態(tài)時，必須先進入廣播狀態(tài)，才能由此進入連接狀態(tài)。對于從機，如果設(shè)備不進入廣播狀態(tài)，即使主機發(fā)起回連，也不可能被連接成功。
- 廣播中的設(shè)備，當它被上層停止廣播、或者被主機連接時，便會退出廣播狀態(tài)。此處需要注意的是，當鏈路建立，協(xié)議棧會將鏈路建立事件層層上傳，其中，就包括 GAP層 。GAP 層在接收到鏈路建立事件之后，便會開始執(zhí)行一系列的流程……
這些流程包括，特性交換流程，MTU 交換流程，連接參數(shù)更新流程，安全流程（配對流程、綁定流程、加密流程），GATT 服務(wù)發(fā)現(xiàn)流程等。剛連上那會的幾秒鐘，是 BLE 外設(shè)最繁忙的時間段，也是最容易出現(xiàn)問題的時間段。有經(jīng)驗的工程師，一般都會將一些時間敏感的任務(wù)的處理，和這段時間段進行錯開。
解決問題
相信通過 BLE 背景知識的介紹，部分人已經(jīng)大概了解了問題的原因了。到達客戶現(xiàn)場調(diào)試時，通過藍牙抓包器、并讓客戶當場復(fù)現(xiàn)問題，我把藍牙主、從機的空中交互過程記錄下來。仔細觀察抓包器的記錄過程，發(fā)現(xiàn)當問題發(fā)生時，斷開連接的事件出現(xiàn)得非常早期：在鏈路建立、特性交換流程剛執(zhí)行完后，即發(fā)生了斷連。
小結(jié)
藍牙協(xié)議棧是個分層的協(xié)議，當我們說藍牙已連接時，想表達的意思應(yīng)該是鏈路層鏈路建立，而現(xiàn)實中，很多工程師都把藍牙已連接理解成了可以收、發(fā)數(shù)據(jù)了。實際上，從藍牙鏈路建立，到協(xié)議?？梢詾橛脩魧邮铡l(fā)數(shù)據(jù)，中間還差了十萬八千里?？偠灾?，從本文的解題思路出發(fā)，我總結(jié)以下幾點經(jīng)驗：
- 用戶程序應(yīng)該深刻理解“藍牙已連接”的概念， 做好狀態(tài)管理。
- 鏈路建立后是藍牙最繁忙的時刻，用戶任務(wù)處理應(yīng)盡可能避開該時間段。
- 加快鏈路建立繁忙時間段的方法包括：
o 鏈路建立后，使用較快的連接間隔，并在之后調(diào)慢以平衡功耗
o 使用 GATT CACHING 特性
