用什么可以做網(wǎng)站,服務(wù)器租用大概多少錢,沈陽網(wǎng)站關(guān)鍵詞優(yōu)化做的好嗎,上市公司排名在做 手機(jī) / 前端 / 小程序 與 BLE 設(shè)備通信 時#xff0c;很多人都會遇到這些疑問#xff1a;為什么 BLE 一次只能傳 20 字節(jié)#xff1f;JSON 為什么一用就超限#xff1f;MTU 到底是什么#xff0c;調(diào)了有什么用#xff1f;ATT、GATT 老是一起出現(xiàn)#xff0c;它們到底…在做手機(jī) / 前端 / 小程序 與 BLE 設(shè)備通信時很多人都會遇到這些疑問為什么 BLE 一次只能傳20 字節(jié)JSON 為什么一用就超限MTU 到底是什么調(diào)了有什么用ATT、GATT 老是一起出現(xiàn)它們到底有什么區(qū)別如果你也被這些問題繞暈過這篇文章就是為你準(zhǔn)備的。本文會用盡量通俗、工程視角把這些概念一次講清楚。一、先給結(jié)論讓你心里有個數(shù)在不做任何額外配置的情況下BLE單次穩(wěn)定可傳輸數(shù)據(jù)20 字節(jié)原因不是手機(jī)、不是代碼而是底層協(xié)議限制在BLE 4.2 并成功協(xié)商 MTU的情況下單包常見最大有效數(shù)據(jù)244 字節(jié)但依然不適合大 JSON只是“緩解”不是“解決”這些限制都和 ATT、GATT、MTU 有關(guān)。二、BLE 為什么不能像 HTTP / Socket 那樣隨便傳因為 BLE 的設(shè)計目標(biāo)就不是“高速大數(shù)據(jù)傳輸”而是低功耗低速設(shè)備簡單所以 BLE 在協(xié)議設(shè)計上數(shù)據(jù)包很小規(guī)則很嚴(yán)格強調(diào)“短、快、結(jié)構(gòu)化”這也是為什么BLE 非常不適合直接傳 JSON 文本三、ATT 是什么真正限制你的東西1?? ATT 的全稱ATTAttribute Protocol中文一般叫屬性協(xié)議一句話理解ATT 規(guī)定了 BLE 里“數(shù)據(jù)怎么讀、怎么寫、一次能傳多少”2?? ATT 的核心思想一切都是 Attribute在 ATT 看來設(shè)備里的所有數(shù)據(jù)都是一條條Attribute屬性每條 Attribute 都有一個編號Handle一個類型UUID一個值Value以及訪問權(quán)限ATT 不關(guān)心你傳的是不是 JSON是不是字符串代表什么業(yè)務(wù)含義它只關(guān)心一件事這個包裝不裝得下3?? 為什么默認(rèn)只能傳 20 字節(jié)關(guān)鍵點來了 ATT 有一個概念A(yù)TT MTU默認(rèn)ATT MTU 23 字節(jié)其中3 字節(jié)是協(xié)議本身的開銷所以23 - 3 20 字節(jié) 這就是“BLE 單包 20 字節(jié)限制”的真正來源。四、MTU 是什么為什么能變成 244 字節(jié)1?? MTU 的含義MTUMaximum Transmission Unit一次數(shù)據(jù)包允許承載的最大字節(jié)數(shù)在 BLE 里說的通常是ATT MTU。2?? MTU 協(xié)商BLE 4.2從 BLE 4.2 開始手機(jī)和設(shè)備可以協(xié)商 MTU雙方各報一個最大值最終取兩者的最小值常見情況MTU實際可用數(shù)據(jù)23206461128125247244 所以大家常說BLE 常見最大單包有效數(shù)據(jù)是 244 字節(jié)但前提是手機(jī)支持設(shè)備支持協(xié)商成功五、GATT 是什么你真正“在用”的東西如果只有 ATT會有一個問題“我讀到一條數(shù)據(jù)但它代表什么”于是就有了GATT。1?? GATT 的全稱GATTGeneric Attribute Profile通用屬性規(guī)范它不是傳輸協(xié)議而是規(guī)定 Attribute 應(yīng)該如何組織、如何被使用2?? GATT 引入的核心概念GATT 在 ATT 之上定義了Service服務(wù)一組相關(guān)數(shù)據(jù)Characteristic特征真正存數(shù)據(jù)的地方Descriptor描述符對特征的補充說明你在代碼里操作的serviceIdcharacteristicId 都是GATT 概念。3?? 一個直觀對比同一條數(shù)據(jù)在ATT眼里一段二進(jìn)制值六、ATT 和 GATT 的核心區(qū)別一定要分清對比點ATTGATT層級底層上層作用怎么傳數(shù)據(jù)數(shù)據(jù)怎么組織是否限制 20 字節(jié)? 是? 否是否懂業(yè)務(wù)? 不懂? 懂你是否直接操作??一句話總結(jié)你操作的是 GATT但真正限制你的是 ATT。七、為什么 BLE 不推薦直接用 JSON1?? JSON 天生“占字節(jié)”{cmd:open,time:123456}字段名多字符多冗余高在 20 字節(jié)限制下非常容易超。2?? 必然帶來的問題拆包 / 分包包序號重組邏輯出錯處理 復(fù)雜度直線上升。3?? BLE 更推薦的做法二進(jìn)制協(xié)議命令字 參數(shù)固定長度或簡單結(jié)構(gòu)例如[0x01, 0x58]而不是 JSON 文本。八、把所有關(guān)系串起來很重要真實的數(shù)據(jù)流是這樣的你的業(yè)務(wù)數(shù)據(jù)↓GATT服務(wù) / 特征↓ATT讀 / 寫 / 通知受 MTU 限制↓底層藍(lán)牙鏈路所以20 字節(jié)問題 →ATT MTU服務(wù) / 特征 →GATTJSON 是否合適 →協(xié)議設(shè)計問題九、一句話終極總結(jié)ATT 是 BLE 的“運輸層”決定一次能傳多少、怎么傳GATT 是 BLE 的“數(shù)據(jù)使用規(guī)范”決定數(shù)據(jù)如何組織、如何被理解。默認(rèn) ATT MTU 為 23 字節(jié)導(dǎo)致單包有效數(shù)據(jù)只有 20 字節(jié)BLE 4.2 可通過 MTU 協(xié)商提升到常見的 244 字節(jié)但 BLE 依然更適合短小、結(jié)構(gòu)化的數(shù)據(jù)而不是直接傳 JSON。