BLE傳統廣播避坑指南
前幾天和同事一起討論基於藍牙BLE實現的current time profile功能，發現不少安卓源碼問題。那這篇文章我們就來扒一扒安卓源碼中涉及BLE廣播的那些坑，爲藍牙開發者少走些彎路盡點綿薄之力。
對BLE傳統廣播還不瞭解的小夥伴建議提前瞭解相關知識，可以查看我前一篇文章《低功耗藍牙BLE傳統廣播總結》。
使能一個傳統BLE廣播，需要設置參數、數據，使能廣播這幾個流程，每個流程執行成功才能真正將廣播使能起來，那這其中的坑聽我娓娓道來。
1、廣播名字
廣播數據中包含本端藍牙設備的名字，方便掃描方發現該廣播。所以在構造AdvertiseData數據時setIncludeDeviceName設置成true就可現實廣播中加入藍牙name。
但是如果你的藍牙名字是中文字符，那大坑就在向你招手了。由於廣播數據是有長度要求，被限制在最多31字節
安卓源碼中也會在BluetoothLeAdvertiser.totalBytes()檢測廣播數據長度是否符合要求,但是計算藍牙名字的長度時使用的是String .length()，這樣中文名字的藍牙名字有幾個字符就是佔幾個字節，比如藍牙名字是“一頭老母豬”，那這邊計算的長度爲5。
但是最後在AdvertiseHelper.advertiseDataToBytes()方法中將AdvertiseData數據轉換成byte[]型數組時採用String.getBytes(“UTF-8”)轉換中文字符, "UTF-8"格式的編碼轉換在不同的系統中可以將一箇中文字符轉換成不同字節的數組。
安卓系統中通過"UTF-8"會將一箇中文字符轉換成三個字節的數據，所以藍牙名稱爲“一頭老母豬”經"UTF-8"轉換後會得到一個15字節的數據。
這樣會導致一個問題：在BluetoothLeAdvertiser檢測符合要求的廣播數據，在最終轉換成byte[]型數組後的數據長度可能會超過31字節，這樣發送廣播數據時可能會丟失部分應用設置的初始數據。
2、廣播數據
藍牙協議中規定了傳統BLE廣播的數據長度最多就是31字節，可有時掃描廣播卻發現廣播數據不對，平白無故多了些數據，這時問題可能出在使用的藍牙協議棧bluedroid非原生協議棧。有些藍牙協議棧供應商自己的協議棧會私自添加一些數據，導致廣播數據變多，或丟失應用設置的部分初始數據，如下圖是使用的非原生協議棧後發送的廣播數據增加了AD Type = 0x12的數據：
所以使用第三方提供的藍牙協議棧時需要多多瞭解他們的實現是否和原生有差異，避免像上面這樣無緣無故地增加了些可有可無的數據，從而丟失了原始設置的數據。
3、廣播參數Interval
廣播參數Interval是一個範圍值，interval_min ~ interval_max ,兩者相處50，即interval_max = interval_min + 50，但是在傳統廣播的HCI定義中，interval的取值範圍爲：0x0020 ~ 0x4000
而且參數inteval的選取還在於設置廣播參數選用的是哪個接口：
使能傳統廣播從上表可以得出以下結論：
-
startAdvertising，則interval只有三種選擇，但都在HCI規定的範圍內
-
startAdvertisingSet，則interval是一個範圍值，大大增加了用戶的可選項，但可能會超出傳統廣播定義的interval最大值0x4000。這一點應用使能傳統廣播時需重點關注。
源碼學習無止境，發現源碼相關bug有助於規避不必要的風險，本篇避坑指南就暫時指到這兒，以後的學習中發現源碼bug會繼續更新，感興趣的小夥伴歡迎私信留言一起討論源碼bug。
更多互聯互通技術，歡迎關注微信公衆號：Connectivity
