一、如何定義ble中service uuid？
- 藍(lán)牙標(biāo)準(zhǔn)規(guī)范里面定義了很多已經(jīng)定義過的service uuid，如果沖突了會(huì)造成很多意外的問題。
- 藍(lán)牙的service uuid的格式如下
UUID.fromString("00001234-0000-1000-8000-00805f9b34fb") - 在Android可以簡(jiǎn)單的采用這個(gè)原則：1艺智、利用這個(gè)字符串【00002903-0000-1000-8000-00805f9b34fb】用第5-8位的數(shù)字做變化，其他數(shù)字保持不變圾亏。比如
UUID.fromString("00007777-0000-1000-8000-00805f9b34fb")
UUID.fromString("00009999-0000-1000-8000-00805f9b34fb")
二十拣、ble中心設(shè)備開啟掃描，設(shè)置所關(guān)心的serviceuuid志鹃。
bluetoothLeScanner = mBluetoothAdapter.getBluetoothLeScanner();
List<ScanFilter> filters = new ArrayList<>();
ScanFilter filter = new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");)
.build();
filters.add(filter);
ScanSettings scanSettings = new ScanSettings.Builder()
.setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
.build();
bluetoothLeScanner.startScan(filters, scanSettings, scanCallback);
new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");
三夭问、ble外圍設(shè)備可以在廣播的時(shí)候設(shè)定AdvertiseData的magic number【manufacturerId 和 manufacturerSpecificData】。這樣即使定義service uuid跟別人的有沖突曹铃，也可以在中心過濾該magic number來找到符合自己需求的外圍設(shè)備
- 外圍構(gòu)建AdvertiseData
AdvertiseData.Builder()
.setIncludeDeviceName(true)
.addServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb"))
.addManufacturerData(0x7777, new byte[]{0x07, 0x07})
.build();
- 中心處理AdvertiseData中的
final ScanCallback scanCallback = new ScanCallback() {
@Override
public void onScanResult(int callbackType, ScanResult result) {
super.onScanResult(callbackType, result);
ScanRecord scanRecord = result.getScanRecord();
SparseArray<byte[]> mandufacturerData = scanRecord.getManufacturerSpecificData();
此時(shí)可以根據(jù)mandufacturerData來匹配自己設(shè)定的外圍設(shè)備
四缰趋、什么時(shí)候ble的中心和外圍才算真正的連接上？（可以開始傳輸數(shù)據(jù)了）
在BluetoothGattCallback中的關(guān)于此問題有三步回調(diào)
1陕见、public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState)
這是ble中心和外圍連接后秘血，最先觸發(fā)的回調(diào)。newstate等于BluetoothProfile.STATE_CONNECTED僅僅表示中心設(shè)備連接上了评甜，這個(gè)時(shí)候需要去調(diào)用BluetoothGatt去發(fā)現(xiàn)服務(wù)灰粮。
注意case1，在new state為BluetoothProfile.STATE_DISCONNECTED時(shí)忍坷，務(wù)必關(guān)掉BluetoothGatt粘舟，因?yàn)槊看握{(diào)用
mBluetoothGatt = device.connectGatt(SpeakerApp.appContext, false, mGattCallBack);都會(huì)生成新的對(duì)象红柱，而不會(huì)去主動(dòng)關(guān)閉老的對(duì)象注意case2，133問題蓖乘，iPhone 和 某些Android手機(jī)作為旁支會(huì)出現(xiàn)藍(lán)牙初始連接就是133，此情況下應(yīng)該立刻重新掃描連接韧骗。133問題鏈接
//iPhone 和 某些Android手機(jī)作為旁支會(huì)出現(xiàn)藍(lán)牙初始連接就是133嘉抒，此情況下立刻重試
if (status == 133) {
RLog.d(TAG, "發(fā)生設(shè)備初始連接133情況，需要重新掃描連接設(shè)備");
mBluetoothGatt.close();
//Ｅ郾Ｐ┦獭！需要去增加代碼進(jìn)行重新掃描重連
return;
}
if (newState == BluetoothProfile.STATE_CONNECTED) {
mBluetoothGatt = gatt;
mBluetoothGatt.discoverServices();
} else if (newState == BluetoothProfile.STATE_DISCONNECTED) {
mBluetoothGatt.close();
mBluetoothGatt = null;
}
2政模、 public void onServicesDiscovered(BluetoothGatt gatt, int status)
mBluetoothGatt.discoverServices()執(zhí)行后得到的callback岗宣，如果狀態(tài)為GATT_SUCCESS，則可以獲取ble旁支發(fā)起廣播的service和descriptor淋样，把廣播設(shè)為enable
mCharacteristic = service.getCharacteristic(UUID.fromString("00007770-0000-1000-8000-00805f9b34fb"));
if (mCharacteristic == null) {
RLog.e(TAG, "Can't find target characteristic.");
return;
}
gatt.setCharacteristicNotification(mCharacteristic, true);
BluetoothGattDescriptor descriptor = mCharacteristic.getDescriptor(UUID.fromString("00007777-0000-1000-8000-00805f9b34fb"));
descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);
gatt.writeDescriptor(descriptor);
3耗式、public void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status)
只有這一步status == BluetoothGatt.GATT_SUCCESS，才可以真正的傳輸數(shù)據(jù)趁猴，如果在第一步或者第二步就開始傳輸數(shù)據(jù)刊咳，會(huì)在某些特定的case下導(dǎo)致未知的bug或者空指針錯(cuò)誤
所以，在中心設(shè)備跟外圍開始連接后儡司，你可以設(shè)定一個(gè)超時(shí)時(shí)間娱挨，在超時(shí)時(shí)間過后，依然沒能回調(diào)onDescriptorWrite并獲得BluetoothGatt.GATT_SUCCESS捕犬，則此次過程失敗跷坝，你可以根據(jù)實(shí)際情況進(jìn)行重連或者提示錯(cuò)誤
五、mtu-20字節(jié)問題
mtu20的來源：GATT是基于ATT Protocol的碉碉，而它的 core spec里面定義了ATT的默認(rèn)MTU為23個(gè)bytes柴钻，除去ATT的opcode一個(gè)字節(jié)以及ATT的handle2個(gè)字節(jié)之后，剩下的20個(gè)字節(jié)便是留給GATT的了
如果要傳輸大于20字節(jié)的數(shù)據(jù)怎么辦垢粮？
1顿颅、 系統(tǒng)mtu可以支持修改到512字節(jié)，完成大數(shù)據(jù)量的傳輸足丢。但是由于涉及到中心和旁支都需要修改粱腻，會(huì)造成很大的局限性和底層修改量，而且會(huì)觸發(fā)比如某些設(shè)備第一次修改不生效斩跌，另一個(gè)設(shè)備一次連接中只能修改一次等bug绍些，非常不可取，十分不建議耀鸦。
2柬批、分包傳輸啸澡，自己設(shè)計(jì)協(xié)議分包傳輸是最可取的方案，需要注意的是在分包后氮帐，每一個(gè)包之間寫入數(shù)據(jù)需要設(shè)置間隔嗅虏，比如100ms。
六上沐、寫數(shù)據(jù)之前做校驗(yàn),判斷獲取的characteristic是否滿足可讀皮服，可廣播，或者需要回復(fù)等約定参咙。
return ((characteristic.getProperties() & BluetoothGattCharacteristic.PROPERTY_WRITE) > 0 ||
(characteristic.getProperties() & BluetoothGattCharacteristic.PROPERTY_WRITE_NO_RESPONSE) > 0);
七龄广、丟數(shù)據(jù)包問題
在做好5和6的基礎(chǔ)上，依然會(huì)在一些設(shè)備上出現(xiàn)蕴侧，由于系統(tǒng)原因择同，ble剛開始的發(fā)送第一個(gè)數(shù)據(jù)出現(xiàn)丟包，請(qǐng)對(duì)此做出特殊處理净宵。
八敲才、解析數(shù)據(jù)
中心端mtu分包發(fā)給外圍后，外圍可以在
public void onCharacteristicWriteRequest(BluetoothDevice device, int requestId, BluetoothGattCharacteristic characteristic, boolean preparedWrite, boolean responseNeeded, int offset, byte[] value)接收到數(shù)據(jù)并還原成原始數(shù)據(jù)外圍端mtu分包發(fā)給中心端后择葡，中心端可以在
public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic)接收到數(shù)據(jù)并還原成原始數(shù)據(jù)注意归斤，對(duì)于一些藍(lán)牙設(shè)備，總有一些特殊的狀態(tài)刁岸，對(duì)于接受到的數(shù)據(jù)一定要進(jìn)行正確性校驗(yàn)
九脏里、other坑
ble中的PROPERTY_WRITE_NO_RESPONSE不可信任，google的有些版本并沒有去讀取這個(gè)屬性值虹曙，而是直接設(shè)置為需要résponse迫横，穩(wěn)妥的方式最好設(shè)置為必須回復(fù)
在項(xiàng)目中如果有多個(gè)ble或 ble + 經(jīng)典藍(lán)牙連接，在一些臨界情況（比如設(shè)備重啟酝碳，crash閃退重啟）矾踱，a ble連接可能需要移除b ble（或 b經(jīng)典藍(lán)牙）連接產(chǎn)生的設(shè)備，否則會(huì)導(dǎo)致a ble一直連接不上疏哗。
BluetoothDevice remoteDevice = mBluetoothAdapter.getRemoteDevice("另一個(gè)ble 或者 藍(lán)牙設(shè)備mac值");
if (remoteDevice.getBondState() == BluetoothDevice.BOND_BONDED) {
try {
Method removeBond = remoteDevice.getClass().getDeclaredMethod("removeBond");
removeBond.invoke(remoteDevice);
RLog.d(TAG , "成功移除系統(tǒng)bug");
} catch (Exception e) {
RLog.e(TAG , "反射異常");
}
}
