【移動應(yīng)用開發(fā)技術(shù)】Android BLE開發(fā)的各種坑

【移動應(yīng)用開發(fā)技術(shù)】AndroidBLE開發(fā)的各種坑

這段時(shí)間在做低功耗藍(lán)牙（BLE）應(yīng)用的開發(fā)（并不涉及藍(lán)牙協(xié)議棧）?？傮w感覺AndroidBLE還是不太穩(wěn)定，開發(fā)起來也是各種痛苦。這里記錄一些雜項(xiàng)和開發(fā)中遇到的問題及其解決方法，避免大家踩坑。本文說的問題有些沒有得到官方文檔的驗(yàn)證，不過也有一些論壇帖子的支持，也可以算是有一定根據(jù)。Android從4.3(APILevel18)開始支持低功耗藍(lán)牙，但是只支持作為中心設(shè)備（Central）模式，這就意味著Android設(shè)備只能主動掃描和鏈接其他外圍設(shè)備（Peripheral）。從Android5.0(APILevel21)開始兩種模式都支持。BLE官方文檔在

這里。在

BluetoothAdapter.startLeScan()

的時(shí)候，在

BluetoothAdapter.LeScanCallback.onLeScan()

中不能做太多事情，特別是周圍的BLE設(shè)備多的時(shí)候，非常容易導(dǎo)致出現(xiàn)如下錯(cuò)誤：E/GKILINUX(17741):#####ERROR:GKIexception:GKIexception():TaskStateTableE/GKILINUX(17741):#####

E/GKILINUX(17741):#####ERROR:GKIexception:TASKID[0]taskname[BTU]state[1]

E/GKILINUX(17741):#####

E/GKILINUX(17741):#####ERROR:GKIexception:TASKID[1]taskname[BTIF]state[1]

E/GKILINUX(17741):#####

E/GKILINUX(17741):#####ERROR:GKIexception:TASKID[2]taskname[A2DP-MEDIA]state[1]

E/GKILINUX(17741):#####

E/GKILINUX(17741):#####ERROR:GKIexception:GKIexception65524getbuf:outofbuffers#####

E/GKILINUX(17741):#####ERROR:GKIexception:

E/GKI_LINUX(17741):

**********************開發(fā)建議：在

onLeScan()

回調(diào)中只做盡量少的工作，可以把掃描到的設(shè)備，扔到另外一個(gè)線程中去處理，讓

onLeScan()

盡快返回3、在使用

BluetoothDevice.connectGatt()

或者

BluetoothGatt.connect()

等建立

BluetoothGatt

連接的時(shí)候，在任何時(shí)刻都只能最多一個(gè)設(shè)備在嘗試建立連接。如果同時(shí)對多個(gè)藍(lán)牙設(shè)備發(fā)起建立Gatt連接請求。如果前面的設(shè)備連接失敗了，后面的設(shè)備請求會被永遠(yuǎn)阻塞住，不會有任何連接回調(diào)。開發(fā)建議：如果要對多個(gè)設(shè)備發(fā)起連接請求，最好是有一個(gè)同一個(gè)的設(shè)備連接管理，把發(fā)起連接請求序列化起來。前一個(gè)設(shè)備請求建立連接，后面請求在隊(duì)列中等待。如果連接成功了，就處理下一個(gè)連接請求。如果連接失敗了（例如出錯(cuò)，或者連接超時(shí)失?。?，就馬上調(diào)用

BluetoothGatt.disconnect()

來釋放建立連接請求，然后處理下一個(gè)設(shè)備連接請求。4、對BluetoothGatt操作

(read/write)Characteristic(),

(read/write)Descriptor()

和

readRemoteRssi()

都是異步操作。需要特別注意的是，同時(shí)只能有一個(gè)操作（有些貼這說只能同時(shí)有一個(gè)

writeCharacteristic()，這個(gè)我并沒有嚴(yán)格驗(yàn)證），也就是等上一個(gè)操作回調(diào)（例如

onCharacteristicWrite()）以后，再進(jìn)行下一個(gè)操作。開發(fā)建議：把這寫操作都封裝成同步操作，一個(gè)操作回調(diào)之前，阻塞主其他調(diào)用。5、BLE設(shè)備的建立和斷開連接的操作，例如

BluetoothDevice.connectGatt(),BluetoothGatt.connect(),

BluetoothGatt.disconnect()，BluetoothGatt.discoverServices()等操作最好都放在主線程中，否則你會遇到很多意想不到的麻煩。開發(fā)建議：對

BluetoothGatt

的連接和斷開請求，都通過發(fā)送消息到Android的主線程中，讓主線程來執(zhí)行具體的操作。例如創(chuàng)建一個(gè)

newHandler(context.getMainLooper());，把消息發(fā)送到這個(gè)

Handler

中6、如果你在開發(fā)BLE應(yīng)用的時(shí)候，有時(shí)候會發(fā)現(xiàn)系統(tǒng)的功耗明顯增加了，查看電量使用情況，藍(lán)牙功耗占比非常高，好像低功耗是徒有虛名。使用

adbbugreport

獲取的了系統(tǒng)信息，分析發(fā)現(xiàn)一個(gè)名叫

BluetoothRemoteDevices的

WakeLock

鎖持有時(shí)間非常長，導(dǎo)致系統(tǒng)進(jìn)入不了休眠。分析源代碼發(fā)現(xiàn)，在連接BLE設(shè)備的過程中，系統(tǒng)會持有（Aquire）這個(gè)

WakeLock，直到連接上或者主動斷開連接（調(diào)用

disconnect()）才會釋放。如果BLE設(shè)備不在范圍內(nèi)，這個(gè)超時(shí)時(shí)間大約為30s，而這時(shí)你可能又要嘗試重新連接，這個(gè)

WakeLock

有被重新持有，這樣系統(tǒng)就永遠(yuǎn)不能休眠了。開發(fā)建議：對BLE設(shè)備連接，連接過程要盡量短，如果連接不上，不要盲目進(jìn)行重連，否這你的電池會很快被消耗掉。這個(gè)情況，實(shí)際上對傳統(tǒng)藍(lán)牙設(shè)備連接也是一樣。7、Android作為中心設(shè)備，最多只能同時(shí)連接6個(gè)BLE外圍設(shè)備（可能不同的設(shè)備這個(gè)數(shù)字不一樣），超過6個(gè)，就會連接不上了?，F(xiàn)在BLE設(shè)備越來越多，其實(shí)并不夠用，所以在開發(fā)的過程中，需要特別的謹(jǐn)慎使用。開發(fā)建議：按照需要連接設(shè)備，如果設(shè)備使用完了，應(yīng)該馬上釋放連接（調(diào)用BluetoothGatt.close()），騰出系統(tǒng)資源給其他可能的設(shè)備連接。8、發(fā)起藍(lán)牙Gatt連接

BluetoothDevice.connectGatt(Contextcontext,booleanautoConnect,BluetoothGattCallbackcallback)，這里有一個(gè)參數(shù)autoConnect，如果為

true

的話，系統(tǒng)就會發(fā)起一個(gè)后臺連接，等到系統(tǒng)發(fā)現(xiàn)了一個(gè)設(shè)備，就會自動連上，通常這個(gè)過程是非常慢的。為

false

的話，就會直接連接，通常會比較快。同樣，BluetoothGatt.connect()只能發(fā)起一個(gè)后臺連接，不是直接連接。所以這個(gè)地方需要小心。public

boolean

connect()

{

try

{

mService.clientConnect(mClientIf,

mDevice.getAddress(),

false,

mTransport);

//

autoConnect

is

inverse

of

"isDirect"

return

true;

}

catch

(RemoteException

e)

{

Log.e(TAG,"",e);

return

false;

}

}開發(fā)建議：如果