iOS 中使用 Core Bluetooth 框架實(shí)現(xiàn)藍(lán)牙通信蚯舱。Core Bluetooth 是基于藍(lán)牙 4.0 的低功耗模式實(shí)現(xiàn)的良漱。
藍(lán)牙的連接類(lèi)似于 Client/Server 構(gòu)架模型。中心設(shè)備作為客戶(hù)端授滓，周邊設(shè)備作為服務(wù)端羞海，掃描并建立連接進(jìn)行數(shù)據(jù)交換。
CBCentralManager 類(lèi)表示中心設(shè)備筛婉，掃描發(fā)現(xiàn)周邊藍(lán)牙設(shè)備，周邊藍(lán)牙設(shè)備用 CBPeripheral 類(lèi)表示癞松。
一個(gè)藍(lán)牙設(shè)備可能存在多種用途爽撒，每一種用途對(duì)應(yīng)一個(gè)服務(wù)，使用 CBService 表示响蓉，比如心率傳感器有心率監(jiān)測(cè)服務(wù)硕勿。
一個(gè)服務(wù)可以細(xì)分為多種特征，使用 CBCharacteristic 表示枫甲，比如心率監(jiān)測(cè)服務(wù)中源武，含有心率的測(cè)量值扼褪、地理位置的定位等 Characteristic。
一個(gè)特征可以有多種描述粱栖，用 CBDescriptor 表示话浇。
以上涉及到的 CBService，CBCharacteristic闹究，CBDescriptor 類(lèi)都繼承自 CBAttribute幔崖，它們有一個(gè)共同的屬性 CBUUID，用來(lái)作為唯一的標(biāo)識(shí)跋核。
Peripheral 作為 Server 端岖瑰， Central 作為 Client叛买， Peripheral 廣播自己的 Services 和 Characteristics砂代， Central 可以選擇訂閱某一個(gè)具體的 Service, 也可以一次性訂閱全部的 Server（不建議這么做）。獲取到某個(gè) Service 之后率挣，同樣需要繼續(xù)發(fā)現(xiàn)這個(gè)服務(wù)下的 Characteristics刻伊。Peripheral 和 Central 之間通過(guò) Characteristic 建立一個(gè)雙向的數(shù)據(jù)通道。
注意一定要用真機(jī)測(cè)試椒功。
編碼
在 iOS 10 之后需要在 Info.plist 文件里面設(shè)置 NSBluetoothPeripheralUsageDescription 字段捶箱，添加訪(fǎng)問(wèn)藍(lán)牙權(quán)限的描述，否則強(qiáng)行訪(fǎng)問(wèn)藍(lán)牙功能會(huì)造成 Crash动漾。
開(kāi)始丁屎，初始化一個(gè)中心設(shè)備：
CBCentralManager *centralManager = [[CBCentralManager alloc] initWithDelegate:self queue:nil options:nil];
_centralManager = centralManager;
這里有一個(gè)注意點(diǎn)，CBCentralManager 的創(chuàng)建是異步的旱眯，如果初始化完成之后沒(méi)有被當(dāng)前創(chuàng)建它的類(lèi)所持有晨川，就會(huì)在下一次 RunLoop 迭代的時(shí)候釋放。當(dāng)然 CBCentralManager 實(shí)例如果不是在 ViewController 中創(chuàng)建的删豺，那么持有 CBCentralManager 的這個(gè)類(lèi)在初始化之后也必須被 ViewController 持有共虑，否則控制臺(tái)會(huì)有如下的錯(cuò)誤輸出：
[CoreBluetooth] XPC connection invalid
如果成功初始化，就會(huì)回調(diào) CBCentralManagerDelegate:
// 在 cetral 的狀態(tài)變?yōu)?CBManagerStatePoweredOn 的時(shí)候開(kāi)始掃描
- (void)centralManagerDidUpdateState:(CBCentralManager *)central {
if (central.state == CBManagerStatePoweredOn) {
[_centralManager scanForPeripheralsWithServices:nil options:nil];
}
}
中心設(shè)備處于 PowerOn 狀態(tài)的時(shí)候開(kāi)始掃描周邊設(shè)備呀页，可以使用指定的 UUID 發(fā)現(xiàn)特定的 Service妈拌，也可以傳入 nil，表示發(fā)現(xiàn)所有周邊的藍(lán)牙設(shè)備蓬蝶，不過(guò)還是建議只發(fā)現(xiàn)自己需要服務(wù)的設(shè)備尘分。發(fā)現(xiàn)之后會(huì)回調(diào)如下方法：
- (void)centralManager:(CBCentralManager *)central
didDiscoverPeripheral:(CBPeripheral *)peripheral
advertisementData:(NSDictionary<NSString *, id> *)advertisementData RSSI:(NSNumber *)RSSI {
if (!peripheral.name) return; // Ingore name is nil peripheral.
if (![_peripheralsList containsObject:peripheral]) {
[_peripheralsList addObject:peripheral];
_peripherals = _peripheralsList.copy;
}
}
成功發(fā)現(xiàn)設(shè)備后選擇一個(gè) peripheral 建立連接，在建立連接之后停止發(fā)現(xiàn)：
[_centralManager connectPeripheral:peripheral options:nil];
連接成功后會(huì)繼續(xù)回調(diào) CBCentralManagerDelegate 中的方法：
- (void)centralManager:(CBCentralManager *)central didConnectPeripheral:(CBPeripheral *)peripheral {
peripheral.delegate = self;
// Client to do discover services method...
CBUUID *seriveUUID = [CBUUID UUIDWithString:@"d2009d00-6000-1000-8000-XXXX"];
// nil 代表發(fā)現(xiàn)所有服務(wù)丸氛。
[peripheral discoverServices:@[seriveUUID]];
}
連接成功該周邊設(shè)備之后伪货，再發(fā)現(xiàn)需要使用該設(shè)備的具體服務(wù)。
接下來(lái)就是響應(yīng) CBPeripheralDelegate 代理方法了诡延。
成功發(fā)現(xiàn)周邊設(shè)備的某個(gè)服務(wù)之后響應(yīng)方法：
// 發(fā)現(xiàn)服務(wù)
- (void)peripheral:(CBPeripheral *)peripheral didDiscoverServices:(nullable NSError *)error {
NSArray *services = peripheral.services;
if (services) {
CBService *service = services[0];
CBUUID *writeUUID = [CBUUID UUIDWithString: TRANSFER_SERVICE_UUID];
CBUUID *notifyUUID = [CBUUID UUIDWithString: TRANSFER_SERVICE_UUID];
[peripheral discoverCharacteristics:@[writeUUID, notifyUUID] forService:service]; // 發(fā)現(xiàn)服務(wù)
}
}
發(fā)現(xiàn)服務(wù)（CBService）之后抑胎，還需要發(fā)現(xiàn)該服務(wù)下的特征（Characteristic）梨撞。這里通常會(huì)有兩中特征：寫(xiě)特征和通知特征。
發(fā)現(xiàn)特征之后一定要打開(kāi)通知特性香罐，否者寫(xiě)入數(shù)據(jù)之后卧波，不會(huì)收到回復(fù)數(shù)據(jù)。
// 發(fā)現(xiàn)特征
- (void)peripheral:(CBPeripheral *)peripheral didDiscoverCharacteristicsForService:(CBService *)service error:(nullable NSError *)error {
if (!error) {
NSArray *characteristicArray = service.characteristics;
if（characteristicArray.count > 1） {
CBCharacteristic *writeCharacteristic = characteristicArray[0];
CBCharacteristic *notifyCharacteristic = characteristicArray[1];
// 通知使能庇茫， YES enable notification only, NO disable notifications and indications
[peripheral setNotifyValue:YES forCharacteristic:notifyCharacteristic];
}
} else {
NSLog(@"Discover Charactertics Error : %@", error);
}
}
使用 writeCharactersitc 寫(xiě)入數(shù)據(jù)：
[peripheral writeValue:writeData.copy forCharacteristic:writeCharactersitc type:CBCharacteristicWriteWithResponse];
寫(xiě)入數(shù)據(jù)之后港粱，在需要回復(fù)的前提下會(huì)回調(diào)如下兩個(gè)代理方法：
// 寫(xiě)入成功
- (void)peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic error:(nullable NSError *)error {
if (!error) {
NSLog(@"Write Success");
} else {
NSLog(@"WriteVale Error = %@", error);
}
}
// 寫(xiě)入成功后的應(yīng)答
- (void)peripheral:(CBPeripheral *)peripheral didUpdateValueForCharacteristic:(CBCharacteristic *)characteristic error:(NSError *)error {
if (error) {
NSLog(@"update value error: %@", error);
} else {
NSData *responseData = characteristic.value;
}
}
至此，一次完整的藍(lán)牙通信就完成了旦签。
藍(lán)牙數(shù)據(jù)包的載荷比較小查坪，在應(yīng)答的過(guò)程中，經(jīng)常需要進(jìn)行拆包宁炫、組合偿曙。包的第一個(gè)字節(jié)代表包的序列號(hào)。
參考
iOS開(kāi)發(fā)之玩轉(zhuǎn)藍(lán)牙CoreBluetooth
關(guān)鍵概念
談到藍(lán)牙羔巢，很容易讓人聯(lián)想到藍(lán)牙穿戴設(shè)備望忆，好像聽(tīng)起來(lái)更靠近硬件層一些。蘋(píng)果其實(shí)對(duì)iOS和OSX上的藍(lán)牙已做了一層很好的封裝竿秆，看過(guò)CoreBluetooth Framework的大致API之后启摄，基本上就將其流程明白個(gè)大概。難點(diǎn)在于理解其工作模式和理清一些關(guān)鍵概念幽钢，比如Peripehral, Central, Service, characteristics等等歉备，不要被這些陌生的單詞嚇到，網(wǎng)絡(luò)協(xié)議的應(yīng)用大多脫不了CS的架構(gòu)模型匪燕，這里和大家一起對(duì)照傳統(tǒng)的Client/Server架構(gòu)來(lái)梳理下iOS和OSX上CoreBluetooth的重要知識(shí)點(diǎn)蕾羊。我畫(huà)了一張圖，方便大家一目了然的明白CoreBluetooth的工作原理谎懦。
我們只需要把Peripehral, Central, Service, characteristics幾個(gè)概念理清肚豺，再各自對(duì)應(yīng)到我們之前關(guān)于CS的知識(shí)體系之中就可以輕松的做一層自己的封裝了。
初次查看CoreBluetooth文檔的時(shí)候界拦，很容易把Central理解成Server吸申，其實(shí)剛好相反，Peripheral才是我們的Server享甸。正如上圖所示截碴，Peripheral和Central之間建立的是一對(duì)多的關(guān)系。每個(gè)Peripheral會(huì)以廣播的模式告訴外界自己能提供哪些Service蛉威，這里Service的概念和我們傳統(tǒng)CS架構(gòu)當(dāng)中的Service基本是一致的日丹，每個(gè)PeriPheral可以提供多個(gè)Service，而每個(gè)Service呢蚯嫌，會(huì)包含多個(gè)characteristic哲虾，characteristic是個(gè)陌生但十分關(guān)鍵的概念丙躏，可以把characteristic理解成一個(gè)Service模塊具體提供哪些服務(wù)，比如一個(gè)心率監(jiān)測(cè)Service同時(shí)包含心率測(cè)量characteristic和地理位置定位characteristic束凑。
Peripheral作為Server晒旅，Central作為Client，Peripheral廣播自己的Service和characteristic汪诉，Central訂閱某一個(gè)具體的characteristic废恋，Peripheral就和Central之間通過(guò)characteristic建立了一個(gè)雙向的數(shù)據(jù)通道，整個(gè)模型非常簡(jiǎn)潔而且符合我們CS的架構(gòu)體系扒寄。接下來(lái)具體看下CoreBluetooth的相關(guān)API鱼鼓。
優(yōu)雅的CoreBluetooth
首先值得開(kāi)心一把的是iOS和OSX使用的是同一套API封裝，都是基于CoreBluetooth Framework该编，只在極細(xì)小的地方有些差異迄本，完全可以做一層library的封裝在兩個(gè)平臺(tái)上無(wú)縫銜接使用。
在具體搭建基于CoreBluetooth應(yīng)用之前上渴，要先確立到底哪一方作為Peripheral岸梨，哪一方又是Central。Macbook稠氮，iPhone，iPad都能成為Peripheral或者Central半开。我們通過(guò)代碼的方式再看一遍上面的架構(gòu)流程隔披。
Server端
創(chuàng)建Peripheral，也就是我們的Server:
_peripheral = [[CBPeripheralManager alloc] initWithDelegate:self queue:nil];
生成Service以備添加到Peripheral當(dāng)中:
CBMutableService *transferService = [[CBMutableService alloc] initWithType:[CBUUID UUIDWithString:TRANSFER_SERVICE_UUID] primary:YES];
生成characteristics以備添加到Service當(dāng)中:
self.transferCharacteristic = [[CBMutableCharacteristic alloc] initWithType:[CBUUID UUIDWithString:TRANSFER_CHARACTERISTIC_UUID] properties:CBCharacteristicPropertyNotify|CBCharacteristicPropertyWrite
value:nil permissions:CBAttributePermissionsReadable|CBAttributePermissionsWriteable];
建立Peripheral寂拆，Server奢米，characteristics三者之間的關(guān)系并開(kāi)始廣播服務(wù):
//建立關(guān)系
transferService.characteristics = @[self.transferCharacteristic];
[self.peripheral addService:transferService];
//開(kāi)始廣播
[self.peripheral startAdvertising:@{ CBAdvertisementDataServiceUUIDsKey : @[[CBUUID UUIDWithString:TRANSFER_SERVICE_UUID]] }];
Client端
創(chuàng)建我們的Central，也就是client:
_central = [[CBCentralManager alloc] initWithDelegate:self queue:nil];
掃描可用的Peripheral:
[self.central scanForPeripheralsWithServices:@[[CBUUID UUIDWithString:TRANSFER_SERVICE_UUID]]
options:@{ CBCentralManagerScanOptionAllowDuplicatesKey : @YES }];
掃描到Peripheral之后連接：
[self.central connectPeripheral:targetPeripheral options:nil];
連接成功之后查找可用的Service：
[peripheral discoverServices:@[[CBUUID UUIDWithString:TRANSFER_SERVICE_UUID]]];
找到Service之后纠永，進(jìn)一步查找可用的Characteristics并訂閱:
//查找Characteristics
[peripheral discoverCharacteristics:@[[CBUUID UUIDWithString:TRANSFER_CHARACTERISTIC_UUID]] forService:service];
查找到Characteristics訂閱：
//訂閱
[peripheral setNotifyValue:YES forCharacteristic:characteristic];
訂閱之后Central和Peripheral之間就建立了一個(gè)雙向的數(shù)據(jù)通道鬓长，后續(xù)二者之間的數(shù)據(jù)傳輸就可以通過(guò)characteristic來(lái)完成了。
數(shù)據(jù)傳輸
有了數(shù)據(jù)通道尝江，接下來(lái)就是如何傳輸數(shù)據(jù)了涉波。說(shuō)到數(shù)據(jù)傳輸就免不了要確定應(yīng)用層的協(xié)議，類(lèi)似平時(shí)我們使用socket實(shí)現(xiàn)游戲的網(wǎng)絡(luò)模塊時(shí)炭序，需要自定義應(yīng)用層協(xié)議才能實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的交換啤覆，協(xié)議的設(shè)計(jì)這里就不展開(kāi)說(shuō)了，之前有過(guò)相關(guān)經(jīng)驗(yàn)的童鞋完全可以把協(xié)議層遷移過(guò)來(lái)惭聂。
再看下Peripheral是如何向Central發(fā)送數(shù)據(jù)的窗声，首先Peripheral會(huì)向自己的characteristic寫(xiě)數(shù)據(jù)：
[self.peripheral updateValue:chunk forCharacteristic:self.transferCharacteristic onSubscribedCentrals:@[self.central]];
Central那一端會(huì)通過(guò)如下回調(diào)收到來(lái)自Peripheral的數(shù)據(jù)流：
- (void)peripheral:(CBPeripheral *)peripheral didUpdateValueForCharacteristic:(CBCharacteristic *)characteristic error:(NSError *)error;
這里值得注意的是二者數(shù)據(jù)的發(fā)送與獲取，是以二進(jìn)制流的方式發(fā)送的辜纲，是NSData的形式封裝的笨觅，Peripheral可以持續(xù)不停的發(fā)送二進(jìn)制流拦耐，所以Central端收到的時(shí)候需要自己做協(xié)議的解析，根據(jù)自定義協(xié)議將整個(gè)流拆成一個(gè)個(gè)的業(yè)務(wù)Packet包见剩。
而Central發(fā)送的時(shí)候卻是封裝成了一個(gè)個(gè)的Request揩魂，比如Central端調(diào)用如下API發(fā)送數(shù)據(jù)：
[self.discoveredPeripheral writeValue:data forCharacteristic:self.discoveredCharacterstic type:CBCharacteristicWriteWithoutResponse];
Peripheral端會(huì)收到如下回調(diào)：
- (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveWriteRequests:(NSArray<CBATTRequest *> *)requests
數(shù)據(jù)被封裝成了單獨(dú)的CBATTRequest，直接去Request當(dāng)中取value就可以獲取到Central所發(fā)送過(guò)來(lái)的數(shù)據(jù)炮温。
已知的坑
我之前測(cè)試協(xié)議的時(shí)候發(fā)現(xiàn)一個(gè)不大不小的坑火脉，多個(gè)Central（比如A和B）端同時(shí)一個(gè)Peripheral發(fā)送數(shù)據(jù)的時(shí)候，Peripheral會(huì)收到多個(gè)CBATTRequest柒啤，奇怪的是每個(gè)CBATTRequest當(dāng)中的Central都會(huì)指向最先建立連接的A倦挂，結(jié)果導(dǎo)致Peripheral端無(wú)法判斷write請(qǐng)求的數(shù)據(jù)來(lái)自哪一個(gè)Central。
簡(jiǎn)單腦洞
藍(lán)牙不僅僅能應(yīng)用于穿戴式設(shè)備担巩，還能做一些好玩的小眾應(yīng)用或者游戲方援，其本質(zhì)是一個(gè)小型封閉的局域網(wǎng)，不用經(jīng)過(guò)第三方的Server或者Cloud涛癌，很安全犯戏。
比如兩臺(tái)iPhone設(shè)備之間通過(guò)基于藍(lán)牙的IM App進(jìn)行聊天（距離這么近，為什么不當(dāng)面聊拳话，黑人問(wèn)號(hào)先匪？）。
比如一些基于藍(lán)牙對(duì)戰(zhàn)的小游戲弃衍。
比如通過(guò)藍(lán)牙在iPhone和Macbook之間做數(shù)據(jù)同步呀非。
藍(lán)牙常遇縮寫(xiě)
MFI ======= make for ipad ,iphone, itouch 專(zhuān)們?yōu)樘O(píng)果設(shè)備制作的設(shè)備
BLE ==== buletouch low energy，藍(lán)牙4.0設(shè)備因?yàn)榈秃碾娋刀ⅲ砸步凶鯞LE
peripheral,central == 外設(shè)和中心,發(fā)起連接的時(shí)central岸裙，被連接的設(shè)備為perilheral
service and characteristic === 服務(wù)和特征 每個(gè)設(shè)備會(huì)提供服務(wù)和特征，類(lèi)似于服務(wù)端的api速缆，但是機(jī)構(gòu)不同降允。每個(gè)外設(shè)會(huì)有很多服務(wù)，每個(gè)服務(wù)中包含很多字段艺糜，這些字段的權(quán)限一般分為 讀read剧董，寫(xiě)write，通知notiy幾種倦踢，就是我們連接設(shè)備后具體需要操作的內(nèi)容送滞。
Description 每個(gè)characteristic可以對(duì)應(yīng)一個(gè)或多個(gè)Description用戶(hù)描述characteristic的信息或?qū)傩?/p>
MFI === 開(kāi)發(fā)使用ExternalAccessory 框架
4.0 BLE === 開(kāi)發(fā)使用CoreBluetooth 框架
每個(gè)設(shè)備都會(huì)有一些服務(wù)，每個(gè)服務(wù)里面都會(huì)有一些特征辱挥，特征就是具體鍵值對(duì)犁嗅，提供數(shù)據(jù)的地方。每個(gè)特征屬性分為這么幾種：讀晤碘，寫(xiě)褂微，通知這么幾種方式功蜓。
//objcetive c特征的定義枚舉
typedef NS_OPTIONS(NSUInteger, CBCharacteristicProperties) {
CBCharacteristicPropertyBroadcast = 0x01,
CBCharacteristicPropertyRead = 0x02,
CBCharacteristicPropertyWriteWithoutResponse = 0x04,
CBCharacteristicPropertyWrite = 0x08,
CBCharacteristicPropertyNotify = 0x10,
CBCharacteristicPropertyIndicate = 0x20,
CBCharacteristicPropertyAuthenticatedSignedWrites = 0x40,
CBCharacteristicPropertyExtendedProperties = 0x80,
CBCharacteristicPropertyNotifyEncryptionRequired NS_ENUM_AVAILABLE(NA, 6_0) = 0x100,
CBCharacteristicPropertyIndicateEncryptionRequired NS_ENUM_AVAILABLE(NA, 6_0) = 0x200
};
藍(lán)牙中心模式流程
1. 建立中心角色
2. 掃描外設(shè)（discover）
3. 連接外設(shè)(connect)
4. 掃描外設(shè)中的服務(wù)和特征(discover)
4.1 獲取外設(shè)的services
4.2 獲取外設(shè)的Characteristics,獲取Characteristics的值，獲取Characteristics的Descriptor和Descriptor的值
5. 與外設(shè)做數(shù)據(jù)交互(explore and interact)
6. 訂閱Characteristic的通知
7. 斷開(kāi)連接(disconnect)
準(zhǔn)備環(huán)境
1 xcode
2 開(kāi)發(fā)證書(shū)和手機(jī)（藍(lán)牙程序需要使用使用真機(jī)調(diào)試宠蚂，使用模擬器也可以調(diào)試式撼，但是方法很蛋疼，我會(huì)放在最后說(shuō)）
3 藍(lán)牙外設(shè)
藍(lán)牙外設(shè)模式流程
1. 啟動(dòng)一個(gè)Peripheral管理對(duì)象
2. 本地Peripheral設(shè)置服務(wù),特性,描述求厕，權(quán)限等等
3. Peripheral發(fā)送廣告
4. 設(shè)置處理訂閱著隆、取消訂閱、讀characteristic呀癣、寫(xiě)characteristic的委托方法
藍(lán)牙設(shè)備狀態(tài)
1. 待機(jī)狀態(tài)（standby）：設(shè)備沒(méi)有傳輸和發(fā)送數(shù)據(jù)美浦，并且沒(méi)有連接到任何設(shè)
2. 廣播狀態(tài)（Advertiser）：周期性廣播狀態(tài)
3. 掃描狀態(tài)（Scanner）：主動(dòng)尋找正在廣播的設(shè)備
4. 發(fā)起鏈接狀態(tài)（Initiator）：主動(dòng)向掃描設(shè)備發(fā)起連接。
5. 主設(shè)備（Master）：作為主設(shè)備連接到其他設(shè)備项栏。
6. 從設(shè)備（Slave）：作為從設(shè)備連接到其他設(shè)備浦辨。
藍(lán)牙設(shè)備的五種工作狀態(tài)
準(zhǔn)備（standby）
廣播（advertising）
監(jiān)聽(tīng)掃描（Scanning
發(fā)起連接（Initiating）
已連接（Connected）
藍(lán)牙和版本的使用限制
藍(lán)牙2.0 === 越獄設(shè)備
藍(lán)牙4.0 === IOS6 以上
MFI認(rèn)證設(shè)備（Make For ipod/ipad/iphone） === 無(wú)限制
名詞解釋
GAAT : Generic Attribute Profile , GATT配置文件是一個(gè)通用規(guī)范，用于在BLE鏈路上發(fā)送和接收被稱(chēng)為“屬性”的數(shù)據(jù)塊沼沈。目前所有的BLE應(yīng)用都基于GATT流酬。 藍(lán)牙SIG規(guī)定了許多低功耗設(shè)備的配置文件。配置文件是設(shè)備如何在特定的應(yīng)用程序中工作的規(guī)格說(shuō)明列另。注意一個(gè)設(shè)備可以實(shí)現(xiàn)多個(gè)配置文件芽腾。例如，一個(gè)設(shè)備可能包括心率監(jiān)測(cè)儀和電量檢測(cè)访递。
Characteristic 一個(gè)characteristic包括一個(gè)單一變量和0-n個(gè)用來(lái)描述characteristic變量的descriptor晦嵌，characteristic可以被認(rèn)為是一個(gè)類(lèi)型，類(lèi) 似于類(lèi)拷姿。
Descriptor Descriptor用來(lái)描述characteristic變量的屬性。例如旱函，一個(gè)descriptor可以規(guī)定一個(gè)可讀的描述响巢，或者一個(gè)characteristic變量可接受的范圍，或者一個(gè)characteristic變量特定的測(cè)量單位棒妨。 Service service是characteristic的集合踪古。例如，你可能有一個(gè)叫“Heart Rate Monitor(心率監(jiān)測(cè)儀)”的service券腔，它包括了很多characteristics伏穆，如“heart rate measurement(心率測(cè)量)”等。你可以在bluetooth.org 找到一個(gè)目前支持的基于GATT的配置文件和服務(wù)列表纷纫。
藍(lán)牙2.0和4.0是什么區(qū)別
藍(lán)牙2.0是我們所使用的最原始的版本枕扫，藍(lán)牙4.0是截至目前研究出的最新版的藍(lán)牙，是在原來(lái)藍(lán)牙3.0的版本上進(jìn)行升級(jí)之后的版本辱魁。兩者區(qū)別是：
藍(lán)牙4.0的兼容性很強(qiáng)烟瞧，可以兼容藍(lán)牙所有版本诗鸭，但是藍(lán)牙2.0的兼容性就不行了，不能兼容高級(jí)版本的藍(lán)牙設(shè)備参滴。
藍(lán)牙2.0的傳輸速度只能達(dá)到當(dāng)前速率的三倍左右强岸，但是藍(lán)牙4.0的傳輸速度是非常快砾赔，而且還可以多設(shè)備連接蝌箍，最少的時(shí)候可以是8個(gè)，最多的時(shí)候可以達(dá)到27個(gè)暴心。藍(lán)牙2.0只能進(jìn)行短距離的數(shù)據(jù)傳輸妓盲，擴(kuò)大范圍就不行了，但是藍(lán)牙4.0的無(wú)線(xiàn)范圍已經(jīng)擴(kuò)大很多了酷勺，現(xiàn)在最大范圍已經(jīng)可以超過(guò)100米了本橙。
開(kāi)著藍(lán)牙時(shí)手機(jī)耗電就非常快脆诉，藍(lán)牙4.0就在耗能減小很多甚亭，現(xiàn)在的4.0版本和2.0版本相比較，可以減少將近90%的耗電量击胜。
在成本上藍(lán)牙4.0所投入的遠(yuǎn)遠(yuǎn)低于藍(lán)牙2.0亏狰，這也是升級(jí)后的藍(lán)牙4.0的一大特性。
藍(lán)牙2.0 是 1.2 的改良提升版偶摔，傳輸率約在 1.8M/s~2.1M/s暇唾，開(kāi)始支持雙工模式——即一面作語(yǔ)音通訊，同時(shí)亦可以傳輸檔案/高質(zhì)素圖片辰斋，2.0 版本當(dāng)然也支持 Stereo 運(yùn)作策州。
藍(lán)牙4.0規(guī)范于2010年7月7日正式發(fā)布，其最大意義在于低功耗宫仗，同時(shí)加強(qiáng)不同OEM廠(chǎng)商之間的設(shè)備兼容性够挂，并且降低延遲，理論最高傳輸速度依然為24Mbps(即3MB/s)藕夫，有效覆蓋范圍擴(kuò)大到100米(之前的版本為10米)孽糖。該標(biāo)準(zhǔn)芯片被大量的手機(jī)、平板所采用毅贮。
藍(lán)牙4.0的版本比藍(lán)牙2.0的高办悟，4.0的傳輸速度更快，同時(shí)功耗更低滩褥，2.0的藍(lán)牙設(shè)備之間配對(duì)病蛉，需要手動(dòng)輸入密碼，4.0的藍(lán)牙設(shè)備之間配對(duì)，會(huì)自動(dòng)生成密碼铡恕，只需要點(diǎn)擊確認(rèn)即可琢感。
關(guān)于藍(lán)牙2.0和4.0區(qū)別
1、采用藍(lán)牙4.0低功耗探熔。
優(yōu)點(diǎn)：不需做蘋(píng)果解密芯片驹针，不需MFI蘋(píng)果認(rèn)證。
缺點(diǎn)：數(shù)據(jù)量不能太大诀艰、手機(jī)必須是藍(lán)牙4.0的柬甥；（藍(lán)牙4.0可以支持蘋(píng)果 iPhone4S、iPhone5等具有藍(lán)牙4.0功能的蘋(píng)果IOS設(shè)備）
2其垄、采用藍(lán)牙2.1苛蒲。
優(yōu)點(diǎn)：數(shù)據(jù)量可以大一些、手機(jī)不需要藍(lán)牙4.0绿满，
缺點(diǎn)：需要MFI認(rèn)證臂外，認(rèn)證后可以購(gòu)買(mǎi)蘋(píng)果指定的解密芯片，方可使用藍(lán)牙傳輸數(shù)據(jù)喇颁。MFI認(rèn)證約9.9萬(wàn)美元/款產(chǎn)品漏健，認(rèn)證周期約半年。（藍(lán)牙2.1+MFI認(rèn)證芯片橘霎，可以支持蘋(píng)果iPhone4蔫浆、iPhone4S、iPhone5等具有藍(lán)牙2.1以上功能的蘋(píng)果IOS設(shè)備）
CoreBluetooth 框架
功能：藍(lán)牙4.0協(xié)議之間信息傳輸姐叁，支持iOS和Android設(shè)備瓦盛。
傳輸方式：藍(lán)牙
支持系統(tǒng)：iOS、Android
http://blog.csdn.net/pony_maggie/article/details/26740237
Socket
功能：通過(guò)TCP或UDP進(jìn)行相同局域網(wǎng)內(nèi)信息傳輸外潜，支持iOS和Android設(shè)備原环。
傳輸方式：WiFi
支持系統(tǒng)：iOS、Android
http://blog.csdn.net/kesalin/article/details/8798039
服務(wù)和特征都是用UUID來(lái)唯一標(biāo)識(shí)的处窥，UUID的概念如果不清楚請(qǐng)自行g(shù)oogle,國(guó)際藍(lán)牙組織為一些很典型的設(shè)備(比如測(cè)量心跳和血壓的設(shè)備)規(guī)定了標(biāo)準(zhǔn)的service UUID(特征的UUID比較多扮念，這里就不列舉了),如下:
define BLE_UUID_ALERT_NOTIFICATION_SERVICE 0x1811
define BLE_UUID_BATTERY_SERVICE 0x180F
define BLE_UUID_BLOOD_PRESSURE_SERVICE 0x1810
define BLE_UUID_CURRENT_TIME_SERVICE 0x1805
define BLE_UUID_CYCLING_SPEED_AND_CADENCE 0x1816
define BLE_UUID_DEVICE_INFORMATION_SERVICE 0x180A
define BLE_UUID_GLUCOSE_SERVICE 0x1808
define BLE_UUID_HEALTH_THERMOMETER_SERVICE 0x1809
define BLE_UUID_HEART_RATE_SERVICE 0x180D
define BLE_UUID_HUMAN_INTERFACE_DEVICE_SERVICE 0x1812
define BLE_UUID_IMMEDIATE_ALERT_SERVICE 0x1802
define BLE_UUID_LINK_LOSS_SERVICE 0x1803
define BLE_UUID_NEXT_DST_CHANGE_SERVICE 0x1807
define BLE_UUID_PHONE_ALERT_STATUS_SERVICE 0x180E
define BLE_UUID_REFERENCE_TIME_UPDATE_SERVICE 0x1806
define BLE_UUID_RUNNING_SPEED_AND_CADENCE 0x1814
define BLE_UUID_SCAN_PARAMETERS_SERVICE 0x1813
define BLE_UUID_TX_POWER_SERVICE 0x1804
define BLE_UUID_CGM_SERVICE 0x181A
數(shù)據(jù)的讀分為兩種，一種是直接讀(reading directly),另外一種是訂閱(subscribe)碧库。從名字也能基本理解兩者的不同。實(shí)際使用中具體用一種要看具體的應(yīng)用場(chǎng)景以及特征本身的屬性巧勤。
經(jīng)典藍(lán)牙（classic Bluetooth）
低功耗藍(lán)牙（Bluetooth low energy嵌灰，簡(jiǎn)稱(chēng)BLE或者LE）
首先，在2010年以前颅悉，當(dāng)我們談?wù)撍{(lán)牙的時(shí)候沽瞭，就是在說(shuō)經(jīng)典藍(lán)牙，因?yàn)槟莻€(gè)時(shí)候還沒(méi)有低功耗藍(lán)牙剩瓶。經(jīng)典藍(lán)牙由藍(lán)牙技術(shù)聯(lián)盟（Bluetooth special interest group驹溃，簡(jiǎn)稱(chēng)Bluetooth SIG）提出并維護(hù)城丧，每次SIG發(fā)布一版新的藍(lán)牙規(guī)格時(shí)，都會(huì)指明規(guī)格的版本號(hào)豌鹤，比如說(shuō)藍(lán)牙規(guī)格1.0/2.0等亡哄，其中藍(lán)牙1.0大概在1999年左右發(fā)布的，藍(lán)牙2.0在2004年發(fā)布布疙，藍(lán)牙2.1在2007年發(fā)布蚊惯，藍(lán)牙3.0在2009年發(fā)布，他們都是在2010年之前發(fā)布的灵临，因此藍(lán)牙1.0/2.0/2.1/3.0都是講經(jīng)典藍(lán)牙的截型，里面沒(méi)有任何關(guān)于低功耗藍(lán)牙的描述。如果你打開(kāi)藍(lán)牙3.0規(guī)格書(shū)儒溉，你會(huì)發(fā)現(xiàn)經(jīng)典藍(lán)牙包括BR宦焦，EDR和HS(AMP)三種模式。
簡(jiǎn)單來(lái)說(shuō)顿涣，只要是藍(lán)牙技術(shù)聯(lián)盟(SIG)發(fā)布的技術(shù)波闹，即可以稱(chēng)為藍(lán)牙技術(shù)。2010年园骆，SIG聯(lián)盟合并了Wibree聯(lián)盟（注：Wibree聯(lián)盟由Nokia和Nordic等創(chuàng)立舔痪，旨在為手機(jī)周邊設(shè)備尋找一種更低功耗的無(wú)線(xiàn)通信技術(shù)），并把Wibree聯(lián)盟提出的低功耗無(wú)線(xiàn)技術(shù)重新命名為低功耗藍(lán)牙技術(shù)（BLE）锌唾，從此BLE也成了一種藍(lán)牙技術(shù)锄码。相應(yīng)地，2010年發(fā)布的藍(lán)牙4.0規(guī)格就同時(shí)包含經(jīng)典藍(lán)牙和低功耗藍(lán)牙晌涕，也就是說(shuō)滋捶，從藍(lán)牙4.0之后，藍(lán)牙才分經(jīng)典藍(lán)牙和低功耗藍(lán)牙余黎。其實(shí)重窟，“經(jīng)典藍(lán)牙”這個(gè)稱(chēng)謂不是非常專(zhuān)業(yè)，它是人民群眾為了口頭上的方便而創(chuàng)造出來(lái)的惧财，在藍(lán)牙4.0規(guī)格中巡扇，SIG定義了四種藍(lán)牙controller技術(shù)：BR，EDR垮衷，AMP和LE厅翔，也就是說(shuō)，藍(lán)牙只有一種藍(lán)牙搀突，那就是SIG的藍(lán)牙刀闷，而藍(lán)牙技術(shù)本身包含四種類(lèi)型：BR，EDR，AMP和LE甸昏，由于LE是2010年才提出的顽分，比較新，因此為了說(shuō)起來(lái)方便施蜜，人們把之前的BR/EDR/AMP技術(shù)稱(chēng)為經(jīng)典藍(lán)牙技術(shù)卒蘸。大家千萬(wàn)不要以為藍(lán)牙4.0之后，藍(lán)牙只有LE一種模式花墩！
為了區(qū)分所謂的低功耗藍(lán)牙和經(jīng)典藍(lán)牙悬秉，藍(lán)牙4.0發(fā)布之初，SIG還特意將Bluetooth low engery對(duì)外宣傳為Bluetooth smart冰蘑，而“Bluetooth”繼續(xù)用來(lái)指代經(jīng)典藍(lán)牙和泌，Bluetooth smart ready則用來(lái)表示雙模藍(lán)牙（即同時(shí)支持經(jīng)典藍(lán)牙和低功耗藍(lán)牙），所以市面上有很多關(guān)于Bluetooth smart祠肥，Bluetooth武氓，Bluetooth smart ready的宣傳材料，但是這些名字不僅沒(méi)有起到傳播Bluetooth品牌的作用仇箱，還讓眾多消費(fèi)者和開(kāi)發(fā)者感到混淆县恕，所以后來(lái)SIG不再頻繁使用Bluetooth smart等名字，更多的是與藍(lán)牙4.0規(guī)格對(duì)齊剂桥，直接使用LE忠烛，BR，EDR等名字進(jìn)行宣傳权逗，對(duì)外也不再宣傳低功耗藍(lán)牙和經(jīng)典藍(lán)牙的不同美尸，并將兩者統(tǒng)一到“Bluetooth（藍(lán)牙）”這個(gè)大品牌下面一起宣傳。
藍(lán)牙技術(shù)聯(lián)盟(SIG)后續(xù)發(fā)布的藍(lán)牙4.1/4.2/5.0斟薇，都是同時(shí)包含低功耗藍(lán)牙和經(jīng)典藍(lán)牙的师坎。所以大家開(kāi)發(fā)藍(lán)牙應(yīng)用的時(shí)候，一定要搞清楚自己是要開(kāi)發(fā)低功耗藍(lán)牙應(yīng)用還是經(jīng)典藍(lán)牙應(yīng)用堪滨，兩者的應(yīng)用場(chǎng)景是不同的胯陋。一般而言，經(jīng)典藍(lán)牙主要應(yīng)用在藍(lán)牙電話(huà)接聽(tīng)，藍(lán)牙耳機(jī)，藍(lán)牙音箱等場(chǎng)合囚枪，低功耗藍(lán)牙應(yīng)用在可穿戴設(shè)備，IoT智能設(shè)備按灶，健身設(shè)備，藍(lán)牙鼠標(biāo)鍵盤(pán)等電池供電場(chǎng)合筐咧。當(dāng)然，經(jīng)典藍(lán)牙也可以用電池供電，但LE對(duì)電池的要求更低量蕊，甚至可以用紐扣電池供電铺罢，而續(xù)航時(shí)間卻很長(zhǎng)，有的LE設(shè)備可以達(dá)到幾年残炮。下圖對(duì)經(jīng)典藍(lán)牙和低功耗藍(lán)牙的典型應(yīng)用場(chǎng)景進(jìn)行了總結(jié)韭赘。
需要引起大家注意的是，經(jīng)典藍(lán)牙和低功耗藍(lán)牙兩者物理層調(diào)制解調(diào)方式是不一樣的势就，所以低功耗藍(lán)牙設(shè)備和經(jīng)典藍(lán)牙設(shè)備兩者之間是不能相互通信的泉瞻，選型的時(shí)候千萬(wàn)不要搞混，如果主設(shè)備是低功耗藍(lán)牙設(shè)備苞冯，從設(shè)備也必須是低功耗藍(lán)牙設(shè)備袖牙；同樣，經(jīng)典藍(lán)牙的從設(shè)備也只能和經(jīng)典藍(lán)牙的主設(shè)備進(jìn)行通信舅锄。不過(guò)市場(chǎng)上還有一種雙模藍(lán)牙設(shè)備鞭达，即同時(shí)支持低功耗藍(lán)牙和經(jīng)典藍(lán)牙，比如我們天天用到的手機(jī)皇忿，手機(jī)可以和經(jīng)典藍(lán)牙設(shè)備通信畴蹭，也可以和低功耗藍(lán)牙設(shè)備通信，如前所述鳍烁，這不代表低功耗藍(lán)牙設(shè)備可以和經(jīng)典藍(lán)牙設(shè)備通信叨襟，其實(shí)手機(jī)使用了分時(shí)機(jī)制來(lái)達(dá)到同時(shí)和低功耗藍(lán)牙設(shè)備以及經(jīng)典藍(lán)牙設(shè)備通信的目的，即手機(jī)讓雙模藍(lán)牙芯片不斷地在低功耗藍(lán)牙模式和經(jīng)典藍(lán)牙模式之間進(jìn)行切換幔荒，以同時(shí)支持低功耗藍(lán)牙設(shè)備和經(jīng)典藍(lán)牙設(shè)備糊闽。低功耗藍(lán)牙方案，經(jīng)典藍(lán)牙方案铺峭，還是雙模藍(lán)牙方案墓怀，大家選型的時(shí)候一定要弄明白他們之間的區(qū)別，以選擇適合自己的藍(lán)牙方案卫键。
