iOS13更新之後，app關於iPhone作爲藍牙Ble外圍設備發送廣播時直接崩了，當時內心也是崩潰的，因爲在iOS13之前自己做智能硬件開發也已經三四年了，iOS的藍牙一直很穩定（讓安卓的同事羨慕）。
問題是：
“CBAdvertisementDataTxPowerLevelKey”這個字段從那冒出來的我沒寫啊，因爲在iOS13之前寫了也沒用。然後各種找問題後來有個兄弟也加入了進來，我們各種查看API都沒有用啊，內心是崩潰的，但是我秉持着作爲一個程序猿不撞南牆不回頭的信念試呀試、試呀試，突然找到自己最早寫的藍牙模塊的代碼，一試我去竟然可以沒有0x0a，
什麼鬼？屎黃屏湊乎看一下吧。
藍牙模塊的代碼自己用了三年沒有大動過。尼瑪？爲啥三年前寫的測試代碼可以？？？心中一萬隻羊駝在奔騰。使勁對比結果還是不應該啊，各種manager、uuid、API沒毛病啊？一毛一樣。問題在哪呢？
各種替換，然後到開始廣播的時候奇蹟出現了，你沒有看錯“startAdvertising”，就是臨門一腳跟前的配置啥的每一毛錢關係。我的測試代碼是廣播3個長度爲128bit的uuit可以不顯示0x0a，然後那個大兄弟是懟了12個16bit的uuid也可以完美避開“CBAdvertisementDataTxPowerLevelKey”。
對於被這個突如其來的問題困擾的兄弟們，這個問題我只能說是可以解決的，具體怎麼解決得看你們的代碼怎麼處理了，因爲每個兄弟的代碼風格習慣都不一樣。試試更健康，大力出奇跡。
然後，在最後給各位做智能硬件開發的移動端程序猿一些建議，對於藍牙通信有一套標準的藍牙協議
只要以後硬件工程師按標準辦事，不再按位取值，哪怕以後到iOS2020也不用擔心藍牙廣播數據出問題。
哇咔咔，問題解決了，是不是很開心。再幹一碗雞湯吧！無規矩不成方圓，按規矩辦事才能事半功倍。