簡介面向Android開發(fā)者的BLE4.0通信示例工程完整演示低功耗藍(lán)牙從設(shè)備掃描、連接、服務(wù)發(fā)現(xiàn)到數(shù)據(jù)讀寫與通知訂閱的閉環(huán)流程。代碼基于Android 4.3官方API編寫覆蓋BluetoothLeScanner、BluetoothGatt、BluetoothGattCharacteristic等核心類并針對掃描參數(shù)配置、連接狀態(tài)回調(diào)、特征值讀寫等關(guān)鍵環(huán)節(jié)給出可直接落地的寫法資源描述對設(shè)備掃描、連接、服務(wù)發(fā)現(xiàn)、數(shù)據(jù)交互、通知訂閱、斷開連接六大流程均有細(xì)致拆解適合需要快速集成藍(lán)牙通信或入門IoT設(shè)備互聯(lián)的開發(fā)者。壓縮包共56個文件包含Java源碼、XML布局與配置、PNG圖片資源以及可直接安裝的APK包整體僅208KB結(jié)構(gòu)緊湊便于逐文件對照學(xué)習(xí)和二次開發(fā)。已有303人學(xué)習(xí)下載。通過這個Demo可直觀理解BLE通信狀態(tài)機(jī)與常見異常處理同時結(jié)合源碼梳理服務(wù)發(fā)現(xiàn)、通知訂閱等完整流程為可穿戴設(shè)備、傳感器數(shù)據(jù)采集等場景提供可復(fù)用的參考實現(xiàn)。 做嵌入式這些年陸陸續(xù)續(xù)點過不少燈、調(diào)過不少協(xié)議棧。坦白說真正讓我覺得“模塊間能說話”這事變得有實用價值的不是串口也不是CAN而是BLE。BLE 4.0這個版本的Demo到今天依然是很多物聯(lián)網(wǎng)產(chǎn)品驗證原型的第一站。這篇就圍繞一個典型的“BLE4.0Demo”把從方案選型、GATT結(jié)構(gòu)設(shè)計、連接參數(shù)配置到實際調(diào)試踩坑的完整路徑捋一遍。適合剛接觸藍(lán)牙低功耗的硬件工程師、嵌入式軟件開發(fā)者以及被WiFi功耗折磨得沒脾氣、想轉(zhuǎn)BLE做產(chǎn)品原型的朋友。1. 項目概述與方案選型1.1 為什么到現(xiàn)在還在聊BLE 4.0每次提到BLE總有人第一時間想到BLE 5.0甚至5.4覺得4.0是過時產(chǎn)物。但很多實際產(chǎn)品設(shè)計里BLE 4.0仍然占據(jù)一席之地。原因并不復(fù)雜BLE 4.0定義了低功耗藍(lán)牙的基礎(chǔ)框架廣播、掃描、連接、GATT服務(wù)、配對綁定這一套核心機(jī)制從4.0到現(xiàn)在幾乎沒有顛覆性變化。而BLE 5.0增加的2Mbps物理層速率、Coded PHY長距離模式、擴(kuò)展廣播都是在4.0的地基上新增的可選項。從需求出發(fā)如果一個Demo只需要傳輸溫濕度、計步數(shù)據(jù)、開關(guān)狀態(tài)這類小包數(shù)據(jù)BLE 4.0的1Mbps有效吞吐量已經(jīng)足夠。而且4.0的協(xié)議棧更精簡對MCU的Flash和RAM占用更小在很多成本敏感的芯片上比如CC2541、nRF51822時期的老平臺跑4.0的協(xié)議棧比跑5.x更輕松。更重要的是BLE 4.0對Android 4.3以上、iOS 5以上系統(tǒng)有良好的兼容性做產(chǎn)品驗證時不需要擔(dān)心老設(shè)備的兼容性問題。1.2 硬件平臺與開發(fā)板選型做BLE4.0Demo硬件選型幾乎決定了后面開發(fā)的順暢程度。我列幾個常用的平臺方便你對著自己的需求挑nRF52832雖然是BLE 5.0芯片但完全兼容4.0協(xié)議SDK成熟文檔豐富適合做原型驗證。缺點是管腳較少外設(shè)擴(kuò)展需要細(xì)心安排。CC2541TI的經(jīng)典BLE 4.0 SoC51內(nèi)核跑協(xié)議棧后剩余資源有限但勝在成本低、資料多適合量產(chǎn)的簡單場景。ESP32樂鑫的芯片支持BLE 4.2編程模型簡單用ESP-IDF或Arduino都能快速上手。我遇到過不少開發(fā)者用它做Demo再根據(jù)需求換到更專用芯片。AT32 / AP6256 等模塊方案直接用透傳模塊發(fā)送AT指令控制省去協(xié)議棧開發(fā)適合硬件工程師快速出原型。如果你是第一次做BLE項目我的建議是別一上來就啃協(xié)議棧源碼先用成熟的SDK和開發(fā)板把一個最簡單的“從機(jī)廣播、主機(jī)掃描連接、收發(fā)數(shù)據(jù)”跑通再慢慢往里加?xùn)|西。這個思路和學(xué)單片機(jī)先點燈、學(xué)Linux先跑hello world是一回事。選型時重點看三點① 是否有現(xiàn)成的SDK和示例工程② 芯片是否滿足功耗目標(biāo)睡眠電流、峰值電流③ 是否有足夠的Flash一個帶OTA的BLE 4.0工程通常需要128KB以上FlashRAM至少8-16KB。2. GATT結(jié)構(gòu)與連接參數(shù)設(shè)計2.1 GATT服務(wù)結(jié)構(gòu)怎么定BLE通信繞不開GATT。簡單說GATT定義了一個“屬性(Attribute)”的表格服務(wù)(Service)是一組屬性的集合特征(Characteristic)是服務(wù)里的具體數(shù)據(jù)項屬性(Property)決定這個特征可讀、可寫還是可通知。設(shè)計Demo時很多人上來就隨便起UUID結(jié)果真機(jī)調(diào)試時被自己坑了——有些手機(jī)系統(tǒng)對標(biāo)準(zhǔn)服務(wù)有特殊處理自定義服務(wù)建議使用自定義的128位UUID避免和Bluetooth SIG定義的16位UUID比如電池服務(wù)0x180F、設(shè)備信息服務(wù)0x180A沖突。我常用的做法是用一個自定義服務(wù)比如0xFFF0承載業(yè)務(wù)數(shù)據(jù)把數(shù)據(jù)分成兩個特征Write特征0xFFF1手機(jī)端給設(shè)備下發(fā)命令。Notify特征0xFFF2設(shè)備主動上報數(shù)據(jù)比如傳感器采集結(jié)果、狀態(tài)變化。為什么這樣拆因為BLE的規(guī)范中Write和Notify分別對應(yīng)下行控制與上行數(shù)據(jù)上報拆開后主從兩端邏輯清晰調(diào)試時也能通過屬性權(quán)限快速判斷是哪一步出了問題。另外如果后續(xù)要支持“讀”操作可以再加一個Read特征但注意一個特征不建議同時掛太多屬性否則部分手機(jī)在枚舉服務(wù)時會表現(xiàn)異常。2.2 連接參數(shù)規(guī)范與功耗的權(quán)衡連接參數(shù)是BLE4.0Demo中最容易被忽略、但又最影響體驗和功耗的部分。連接參數(shù)主要由四個值決定Connection Interval兩個連接事件之間的時間間隔單位是1.25ms的整數(shù)倍。范圍7.5ms到4s。Slave Latency從機(jī)可以跳過多少個連接事件不監(jiān)聽。跳過的次數(shù)越多從機(jī)越省電但數(shù)據(jù)延遲也會變大。Supervision Timeout超過這個時間沒收到連接事件鏈路就斷開。范圍100ms到32s。實際發(fā)送數(shù)據(jù)時有效吞吐量 每個連接事件可發(fā)送的數(shù)據(jù)包數(shù) / (Connection Interval × (1 Slave Latency))。這里有一個關(guān)鍵矛盾間隔越短數(shù)據(jù)收發(fā)越及時但主機(jī)和從機(jī)都要頻繁醒來功耗越高。間隔越長整體越省電但發(fā)一個包可能要等幾百毫秒。iOS系統(tǒng)對連接參數(shù)有一整套審核邏輯如果App請求的Connection Interval不在系統(tǒng)允許的范圍內(nèi)通常是15ms到30ms系統(tǒng)會忽略請求并使用默認(rèn)參數(shù)。如果你在做iOS配套App務(wù)必在請求連接參數(shù)之前查一下當(dāng)前系統(tǒng)版本對參數(shù)的限制。我在實際項目里一般這樣配需要低延遲控制時Connection Interval設(shè)為15msSlave Latency設(shè)為0如果只是周期性上報傳感器數(shù)據(jù)則把Connection Interval設(shè)為100ms左右Slave Latency設(shè)為4這樣從機(jī)大部分時間可以睡大覺。實測下來前者單次通信延遲大約在10-20ms后者能把平均電流從幾十毫安降到幾毫安視具體外設(shè)而定。提示連接參數(shù)的修改時機(jī)有講究。主機(jī)可以在連接穩(wěn)定后發(fā)起參數(shù)更新請求從機(jī)也可以通過L2CAP層主動請求更新。但不要一連接上就立刻改參數(shù)部分協(xié)議棧會報錯。穩(wěn)妥的做法是建立連接后等1秒左右再發(fā)起參數(shù)更新。3. 實操從零搭一個可用的BLE4.0Demo3.1 廣播包設(shè)計與ADV配置廣播是BLE設(shè)備的身份名片。設(shè)計廣播包時核心問題不是“我要廣播什么”而是“我要讓對端在掃描時一眼認(rèn)出我且不被系統(tǒng)過濾掉”。廣播包的結(jié)構(gòu)是多個AD Structure的組合每個Structure由Length、Type、Data組成。常用字段包括Flags0x01聲明設(shè)備是LE Limited Discoverable Mode還是General Discoverable Mode通常設(shè)為0x06同時支持BR/EDR和LE。Complete Local Name0x09設(shè)備名稱比如“MyBLEDemo”或產(chǎn)品的品牌名。Service UUID0x02/0x03/0x06/0x07服務(wù)UUID按128位還是16位、是否完整列表選擇對應(yīng)的Type值。Manufacturer Specific Data0xFF廠商自定義數(shù)據(jù)可以塞一些簡單狀態(tài)標(biāo)志比如固件版本號、設(shè)備ID方便App掃描時直接識別。廣播間隔建議設(shè)置在100ms到500ms之間。間隔越短被發(fā)現(xiàn)越迅速但廣播期間的電流消耗也會增加。做低功耗產(chǎn)品時廣播間隔拉長到1s以上也常見代價是連接體驗變差用戶拿手機(jī)掃半天掃不到設(shè)備就會想卸載你的App。這里分享一個調(diào)試技巧用nRF Connect的“Scanner”頁面掃到設(shè)備后不要只看名字點進(jìn)去看廣播包的具體字節(jié)。你會發(fā)現(xiàn)有些手機(jī)系統(tǒng)會對廣播包做緩存或過濾比如Android系統(tǒng)在部分版本上會緩存廣播包導(dǎo)致掃描不到新增的Service UUID。真機(jī)調(diào)試時只要發(fā)現(xiàn)廣播內(nèi)容和你配置的不一致優(yōu)先懷疑緩存問題而不是協(xié)議棧配置。3.2 主從通信流程與數(shù)據(jù)收發(fā)一個完整的BLE4.0Demo通信流程可以抽象成這個鏈路設(shè)備上電 初始化協(xié)議棧和GATT服務(wù) 開始廣播 手機(jī)主機(jī)掃描到設(shè)備 發(fā)起連接 連接成功后雙方交換MTU大小 手機(jī)寫入命令Write 設(shè)備處理并返回結(jié)果Notify 斷開連接或進(jìn)入睡眠。MTU交換是個值得留意的細(xì)節(jié)。BLE 4.0默認(rèn)MTU是23字節(jié)其中包含3字節(jié)的L2CAP頭意味著單包用戶數(shù)據(jù)只有20字節(jié)。如果你的業(yè)務(wù)字段稍長比如一次要傳50字節(jié)的日志或傳感器批量數(shù)據(jù)就必須在連接成功后主動請求MTU交換把MTU提到247字節(jié)常見值部分協(xié)議棧支持更高。這個操作一旦漏掉你會發(fā)現(xiàn)明明協(xié)議棧支持長包但數(shù)據(jù)就是發(fā)不出去或者被系統(tǒng)自動分包接收端拼接順序錯亂。我在Demo里實現(xiàn)數(shù)據(jù)幀格式時習(xí)慣用最簡的“幀頭長度命令字?jǐn)?shù)據(jù)CRC”0xAA 0x55 | Length(2B) | Cmd(1B) | Data(N) | CRC16(2B)為什么加CRCBLE底層雖然有CRC校驗但GATT層的傳輸是“每包確認(rèn)”的底層丟包重傳并不代表上層業(yè)務(wù)封裝完整。尤其當(dāng)App和固件不是同一撥人開發(fā)時一個清晰的幀格式能減少大量“數(shù)據(jù)對不上”的扯皮。CRC算法不用自造選CRC-16/CCITT或CRC-32都行我習(xí)慣用CRC32雖然多兩個字節(jié)但碰撞概率更低調(diào)試時內(nèi)心更踏實。3.3 與GPIO聯(lián)動的外設(shè)控制場景很多Demo的價值不僅在于“能收發(fā)字符串”更在于“收到命令后真的能控制硬件”。我在做BLE4.0Demo時最喜歡加的一個示例就是通過BLE控制LED燈或繼電器的通斷這個看似簡單的功能把BLE從“數(shù)據(jù)通道”變成了“控制通道”正好銜接到不少熱詞里提到的“ble主從模塊gpio”場景。實現(xiàn)思路很簡單在Notify/Write特征的回調(diào)里解析命令比如收到{0xAA 0x55, 0x00 0x03, 0x01, 0x01, CRC}就把GPIO1置高收到0x00就把GPIO1置低。但這里有個坑BLE回調(diào)函數(shù)的執(zhí)行上下文往往是在協(xié)議棧的任務(wù)/線程中如果直接在回調(diào)里做delay或復(fù)雜運算會把協(xié)議?？ㄋ郎踔劣|發(fā)看門狗。正確做法是回調(diào)里只做消息記錄和標(biāo)志位設(shè)置真正的GPIO操作放到主循環(huán)或單獨的任務(wù)里去執(zhí)行。另外要注意GPIO的電平匹配和驅(qū)動能力。BLE開發(fā)板的GPIO通常只支持幾毫安的驅(qū)動電流直接驅(qū)動繼電器線圈或功率LED很容易燒管腳。我一般會在中間加一個三極管或MOS管做開關(guān)或者用ULN2003這類達(dá)林頓驅(qū)動芯片。這不是BLE特有的問題但實際做Demo時十個里總有兩個人會在這上面燒掉幾個IO口。4. 調(diào)試、踩坑與常見問題速查4.1 Linux下用bluetoothctl調(diào)試的實用姿勢做BLE調(diào)試手機(jī)端有nRF Connect電腦端我推薦Linux下的bluetoothctl配合bluez協(xié)議棧使用。很多人用它只執(zhí)行scan on和connect其實它能做的事遠(yuǎn)不止這些。常用調(diào)試流程打開一個終端運行bluetoothctl然后按順序執(zhí)行power on agent on default-agent scan on # 等幾秒看到目標(biāo)設(shè)備MAC地址記下來 scan off connect MAC地址連接成功后不需要退出bluetoothctl直接敲menu gatt進(jìn)入GATT子菜單然后list-attributes查看服務(wù)列表select-attribute UUID選到目標(biāo)特征后用read或write操作特征值。這些操作能幫你在不寫一行代碼的情況下驗證從機(jī)端GATT結(jié)構(gòu)和讀寫屬性是否正確。這里還有個小技巧如果你只想開BLE、不想讓系統(tǒng)在掃描時同時處理傳統(tǒng)的BR/EDR即藍(lán)牙經(jīng)典模式可以通過bluetoothctl或配置文件把BR/EDR關(guān)掉。這在調(diào)試時會減少很多干擾。具體命令為power off adapter set-privacy on adapter set-adv-data ...需要注意不同bluez版本命令格式有差異實際操作時先執(zhí)行help看當(dāng)前版本支持的命令再操作。調(diào)試時如果發(fā)現(xiàn)設(shè)備掃描不到先檢查廣播是否真的在發(fā)用另一臺設(shè)備或邏輯分析儀抓包再看systemctl status bluetooth確認(rèn)服務(wù)狀態(tài)不要一開始就懷疑射頻參數(shù)。4.2 跨平臺調(diào)試的典型差異BLE4.0Demo驗收的時候至少要在iOS和Android兩個平臺上各跑一遍因為兩邊的行為差異很大。在iOS端主要是連接參數(shù)的審核問題。App通過CoreBluetooth發(fā)起連接后調(diào)setDesiredConnectionInterval請求期望參數(shù)但最終生效的參數(shù)由系統(tǒng)決定。如果你的設(shè)備需要低延遲但系統(tǒng)給了你100ms的間隔延遲體驗會明顯變差。這種情況要么調(diào)低設(shè)備的通信頻率要么檢查自己請求的參數(shù)是否在系統(tǒng)允許的合理范圍內(nèi)。在Android端最大的坑是掃描過濾和動態(tài)權(quán)限。從Android 6.0開始應(yīng)用掃描BLE設(shè)備需要定位權(quán)限而Android 12及以上進(jìn)一步收緊了對附近設(shè)備NEARBY_WIFI_DEVICES的權(quán)限要求。不少人寫完App在手機(jī)上跑掃不到設(shè)備第一反應(yīng)是模塊壞了實際上是沒授權(quán)或者權(quán)限策略把掃描結(jié)果攔了。另一個Android的老毛病是掃描回調(diào)在某些手機(jī)上會被系統(tǒng)批量延遲觸發(fā)處理時不要把每次掃描回調(diào)都當(dāng)成實時事件去刷新UI對結(jié)果做去重和過濾會穩(wěn)妥很多。如果你在Windows上用WinForms.NET Framework 4.7.2做上位機(jī)想和BLE 4.0設(shè)備通信可用的第三方庫不算太多。我目前用下來比較順的是32feet.NET老牌藍(lán)牙庫對經(jīng)典藍(lán)牙RFCOMM支持好但BLE支持一般某些場景需要擴(kuò)展。Windows.Devices.BluetoothWinRT API這是系統(tǒng)自帶的API在.NET Framework 4.7.2中通過包引用也能調(diào)用功能完整但UWP/WinRT的異步API和WinForms的同步模型有沖突需要用AsTask()等機(jī)制橋接。InTheHand.Net.Bluetooth這是32feet.NET的新版本支持UWP API的調(diào)用方式同時兼容.NET Framework。我的經(jīng)驗是在.NET Framework 4.7.2項目里優(yōu)先用Windows.Devices.Bluetooth那套API雖然寫起來繁瑣但功能最完整也別想著省事老老實實處理好async/await的線程切換否則UI會卡到懷疑人生。4.3 常見問題速查表把我在Debug過程中遇到的高頻問題匯總成一個表格方便你開發(fā)時隨時翻查現(xiàn)象可能原因解決思路手機(jī)掃描不到設(shè)備廣播沒開啟或廣播包被緩存確認(rèn)advertising已啟動清藍(lán)牙緩存或用新MAC測試能掃描到但連接不上設(shè)備已與其他主機(jī)連接檢查從機(jī)是否只有單連接能力斷開舊連接或開啟多連接支持連接后發(fā)送無響應(yīng)MTU未交換或特征權(quán)限不對確認(rèn)特征屬性是Write/Notify檢查MTU協(xié)商結(jié)果數(shù)據(jù)收發(fā)亂碼/截斷單包數(shù)據(jù)超長或封包錯誤啟用長包支持使用自定義幀格式長度字段iOS下延遲明顯高連接參數(shù)被系統(tǒng)覆蓋調(diào)整請求參數(shù)的優(yōu)先級優(yōu)先適配iOS系統(tǒng)推薦區(qū)間Android上首次連接后收到重復(fù)數(shù)據(jù)系統(tǒng)通知回調(diào)機(jī)制在固件側(cè)處理去重或App端記錄并過濾重復(fù)seq/包號電流異常偏高廣播間隔太短或GPIO拉高功耗加大廣播間隔檢查外設(shè)供電和GPIO狀態(tài)這些問題的共同點是初期看起來像“硬件壞了”或“協(xié)議棧崩了”最終排查下來80%都是配置和時序問題。遇到問題別急著換硬件先把日志打開看協(xié)議棧事件流轉(zhuǎn)確認(rèn)連接是否建立、特征是否枚舉成功、數(shù)據(jù)通路是否閉合再動手改代碼。5. 從Demo走向產(chǎn)品幾個實用擴(kuò)展建議如果這個BLE4.0Demo只是為了學(xué)習(xí)跑到“能收發(fā)數(shù)據(jù)”就可以收工了。但如果你想往產(chǎn)品方向走還有幾個點值得提前考慮。第一個是安全性與配對綁定。BLE 4.0的“Just Works”配對方式雖然能加密鏈路但無法防中間人攻擊。如果產(chǎn)品涉及門鎖、支付、醫(yī)療數(shù)據(jù)等場景必須升級到MITM保護(hù)模式Passkey Entry或Numeric Comparison并實現(xiàn)長期密鑰存儲LTK。很多人在Demo階段圖省事不綁定量產(chǎn)時發(fā)現(xiàn)安全問題再來改成本會成倍增加。第二個是OTA升級。做過一次你就知道沒有OTA的BLE設(shè)備就是一塊磚。Demo階段可以把固件升級接口預(yù)留出來比如用額外的Service和Characteristic承載升級數(shù)據(jù)或者選擇支持bootloader的芯片。哪怕先不做升級邏輯也建議在協(xié)議棧里預(yù)留好Flash分區(qū)別等產(chǎn)品賣出去了才想著改。第三個是功耗的精細(xì)優(yōu)化。BLE4.0Demo跑通了之后用萬用表量一下整機(jī)電流廣播狀態(tài) vs 連接狀態(tài) vs 深睡眠狀態(tài)三者的電流差別可能是一百倍。這時候再去優(yōu)化廣播間隔、連接參數(shù)、外設(shè)供電才是真正的低功耗設(shè)計。我見過不少項目Demo階段沒關(guān)注功耗后面發(fā)現(xiàn)電池續(xù)航遠(yuǎn)低于預(yù)期最后只能換個兩倍大的電池純屬給自己挖坑。我在實際調(diào)這些項目的時候一個比較深的體會是BLE本身只是個管道真正決定產(chǎn)品好壞的是管道兩端的數(shù)據(jù)設(shè)計和狀態(tài)管理。你把GATT服務(wù)定義清楚、連接參數(shù)配合理、狀態(tài)機(jī)梳理明白哪怕用的是老掉牙的BLE 4.0芯片體驗也不會差。而一旦這些細(xì)節(jié)沒想清楚換再新的藍(lán)牙版本也一樣會翻車。以后做新的Demo也不妨拿這個項目當(dāng)模板先通后精再逐步往BLE 5.x的擴(kuò)展廣播、Coded PHY、Mesh這些方向遷移。本文還有配套的精品資源點擊獲取