GAP(Generic Access Profile):它用來(lái)控制設(shè)備連接和廣播,GAP 使你的設(shè)備被其他設(shè)備可見(jiàn),并決定了你的設(shè)備是否可以或者怎樣與合同設(shè)備進(jìn)行交互。
創(chuàng)新互聯(lián)公司專注于企業(yè)成都全網(wǎng)營(yíng)銷推廣、網(wǎng)站重做改版、若羌網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5技術(shù)、成都商城網(wǎng)站開(kāi)發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù),價(jià)格優(yōu)惠性價(jià)比高,為若羌等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。
GATT(Generic Attribute Profile):BLE連接都是建立在GATT協(xié)議之上的。GATT 是一個(gè)在藍(lán)牙連接之上的發(fā)送和接收很短的數(shù)據(jù)段的通用規(guī)范,這些很短的數(shù)據(jù)段被稱為屬性(Attribute)。
BLE中主要有兩個(gè)角色:外圍設(shè)備(Peripheral)和中心設(shè)備(Central)。一個(gè)中心設(shè)備可以連接多個(gè)外圍設(shè)備,一個(gè)外圍設(shè)備包含一個(gè)或多個(gè)服務(wù)(services),一個(gè)服務(wù)包含一個(gè)或多個(gè)特征(characteristics)。
使用CoreBluetooth庫(kù),創(chuàng)建CBPeripheralManager,實(shí)現(xiàn)CBPeripheralManagerDelegate代理
創(chuàng)建完該對(duì)象,會(huì)回調(diào)peripheralManagerDidUpdateState:方法判斷藍(lán)牙狀態(tài),藍(lán)牙可用,給外設(shè)配置服務(wù)和特征
注意CBAttributePermissions
當(dāng)中心設(shè)備讀寫(xiě)設(shè)置CBAttributePermissionsReadEncryptionRequired/CBAttributePermissionsWriteEncryptionRequired權(quán)限的Characteristic時(shí),會(huì)彈出彈框,請(qǐng)求建立安全連接
給外設(shè)配置服務(wù)特征后,會(huì)調(diào)用peripheralManager:didAddService:error: 服務(wù)特征全部添加完后發(fā)起廣播,如果在廣播時(shí)設(shè)置CBAdvertisementDataServiceUUIDsKey,會(huì)把該service廣播出去,中心設(shè)備在掃描時(shí)可根據(jù)該uuid找到該設(shè)備。外圍設(shè)備靠不斷發(fā)廣播,使中心設(shè)備發(fā)現(xiàn)它。
當(dāng)中央端連接上了此設(shè)備并訂閱了特征時(shí)會(huì)回調(diào) didSubscribeToCharacteristic:
當(dāng)接收到中央端讀的請(qǐng)求時(shí)會(huì)調(diào)用didReceiveReadRequest:
創(chuàng)建CBCentralManager對(duì)象,實(shí)現(xiàn)CBCentralManagerDelegate代理
回調(diào)centralManagerDidUpdateState:代理方法,當(dāng)central.state==CBManagerStatePoweredOn時(shí),開(kāi)啟掃描,設(shè)置serviceUUIDs可掃描特定外設(shè),CBCentralManagerScanOptionAllowDuplicatesKey設(shè)為NO不重復(fù)掃描已發(fā)現(xiàn)設(shè)備,YES是允許
掃描到設(shè)備會(huì)回調(diào)centralManager:didDiscoverPeripheral:advertisementData:RSSI:,RSS絕對(duì)值越大,表示信號(hào)越差,設(shè)備離的越遠(yuǎn)
關(guān)閉掃描
連接設(shè)備
發(fā)現(xiàn)服務(wù)
發(fā)現(xiàn)特征
iOS 藍(lán)牙開(kāi)發(fā)(一)
iOS 藍(lán)牙開(kāi)發(fā)(二)
iOS 藍(lán)牙開(kāi)發(fā)(四)
前面記錄了藍(lán)牙如何進(jìn)行掃描、鏈接、以及獲取外設(shè)的服務(wù)和特征,本篇筆記我將記錄如何實(shí)現(xiàn) 與外設(shè)做數(shù)據(jù)交互(explore and interact) 。
構(gòu)建方法流程:鏈接成功-獲取指定的服務(wù)與特征-訂閱指定的特征值-通過(guò)具有寫(xiě)權(quán)限的特征值來(lái)寫(xiě)數(shù)據(jù)-最后在函數(shù) didUpdateValueForCharacteristic 中獲取藍(lán)牙的反饋信息;
總結(jié):
本篇筆記大概就是在接收到服務(wù)和特征后對(duì)數(shù)據(jù)進(jìn)行寫(xiě)入的操作的過(guò)程,筆記中的重點(diǎn)在于要熟悉構(gòu)建特征和服務(wù)的方法流程。熟悉流程,我們就能清楚知道當(dāng)在寫(xiě)入數(shù)據(jù)時(shí),系統(tǒng)藍(lán)牙會(huì)在函數(shù) didUpdateValueForCharacteristic 方法中給我們反饋寫(xiě)入是否成功的反饋信息。
iOS 藍(lán)牙開(kāi)發(fā)(二)
iOS 藍(lán)牙開(kāi)發(fā)(三)
iOS 藍(lán)牙開(kāi)發(fā)(四)
在iOS中藍(lán)牙相關(guān)實(shí)現(xiàn)都是在CoreBluetooth這個(gè)framework中的,所以我們創(chuàng)建一個(gè)單例類中需要先導(dǎo)入 #import CoreBluetooth/CoreBluetooth.h ,再后即可使用這個(gè)單例類進(jìn)行管理我們藍(lán)牙的掃描、連接、狀態(tài)等實(shí)現(xiàn)。
當(dāng) central.state 為CBManagerStatePoweredOn即可開(kāi)始掃描, 具體方法 [self.centralManager scanForPeripheralsWithServices:nil options:nil] 當(dāng)調(diào)用 scanForPeripheralsWithServices:options: 函數(shù)時(shí)就會(huì)實(shí)時(shí)調(diào)用其代理方法 - (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI
peripheral 是外設(shè)類 advertisementData 是廣播的值,一般攜帶設(shè)備名, serviceUUID 等信息。 RSSI 絕對(duì)值越大,表示信號(hào)越差,設(shè)備離的越遠(yuǎn)。如果想裝換成百分比強(qiáng)度, (RSSI+100)/1001 (這是一個(gè)約數(shù),藍(lán)牙信號(hào)值并不一定是-100 - 0的值)
藍(lán)牙的連接是當(dāng)中心設(shè)備掃描到可用外設(shè)后, 利用函數(shù) [self.centralManager connectPeripheral:peripheral options:nil]; 進(jìn)行鏈接, 當(dāng)函數(shù)被調(diào)用后, 就會(huì)回調(diào)其對(duì)應(yīng)的代理函數(shù)。
本篇筆記主要是記錄如何初始化藍(lán)牙的 CBCentralManager 的中心管理類,并記錄如何實(shí)現(xiàn)掃描周邊外設(shè)、如何鏈接、獲取藍(lán)牙當(dāng)前狀態(tài)。
總結(jié)一下藍(lán)牙開(kāi)發(fā)相關(guān)的知識(shí)點(diǎn)和注意事項(xiàng),做個(gè)筆記,也希望你們能少踩坑
(公司部分藍(lán)牙項(xiàng)目為混編項(xiàng)目,藍(lán)牙相關(guān)處理均采用了Objective-C,故本文????均采用OC,Swift處理相同)
藍(lán)牙4.0包含兩個(gè)藍(lán)牙標(biāo)準(zhǔn),它是一個(gè)是 雙模 的標(biāo)準(zhǔn),它包含 傳統(tǒng)藍(lán)牙部分(也稱經(jīng)典藍(lán)牙) 和 低功耗藍(lán)牙部分(BLE) , 二者適用于不同的應(yīng)用場(chǎng)景和應(yīng)用條件。他們的特點(diǎn)如下
所以藍(lán)牙4.0是集成了傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙兩個(gè)標(biāo)準(zhǔn)的,并不只是低功耗藍(lán)牙
藍(lán)牙4.0支持兩種部署方式: 雙模式 和 單模式 ,雙模同時(shí)支持經(jīng)典藍(lán)牙和低功耗藍(lán)牙,而單模則只支持其中一種。
二者更多細(xì)節(jié)詳見(jiàn): 傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙的區(qū)別
iOS中藍(lán)牙相關(guān)功能都封裝進(jìn)了 CoreBluetooth 類中,其中有幾個(gè)常見(jiàn)的參數(shù)和概念
具體API參考 CoreBluetooth藍(lán)牙開(kāi)發(fā)
保存到數(shù)組中的設(shè)備可通過(guò) UUID 來(lái)進(jìn)行區(qū)分。從 iOS7之后蘋(píng)果不提供外設(shè)的mac地址,外設(shè)的唯一標(biāo)識(shí)換成了由mac封裝加密后的UUID,需要注意的是不同的手機(jī)獲取同一個(gè)外設(shè)的UUID是不同的,所以在不同手機(jī)之間UUID不是唯一的,但在本機(jī)上可以作為唯一標(biāo)識(shí)(特殊情況手機(jī)刷機(jī)后也會(huì)改變UUID)。
如何獲取Mac地址
一般使用場(chǎng)景是根據(jù)Mac地址區(qū)分某個(gè)外設(shè)
注意點(diǎn):
寫(xiě)入數(shù)據(jù)時(shí)可能會(huì)遇到需要分包發(fā)送的情況,我們可以通過(guò)下面的API或許當(dāng)前特征支持的最大的單條寫(xiě)入長(zhǎng)度
maxLength 一般取決于藍(lán)牙模塊內(nèi)部接收 緩沖區(qū) 的大小,很多硬件設(shè)備這個(gè)緩沖區(qū)的大小是 20 字節(jié), 這個(gè)大小也和特征的寫(xiě)入權(quán)限有關(guān),像具有寫(xiě)入權(quán)限 withResponse 類的特征其大小一般為 512 字節(jié),當(dāng)然這些都是取決于設(shè)備測(cè)的設(shè)置;
當(dāng)我們單次發(fā)送的數(shù)據(jù)字節(jié)長(zhǎng)度大于 maxLength 時(shí),我們就需要采用分包的方式來(lái)發(fā)送數(shù)據(jù)了,
分包發(fā)送的邏輯類似于下面
這邊延時(shí)主要是設(shè)備側(cè)的接收模塊接收數(shù)據(jù)以及處理能力有限
外圍設(shè)備測(cè)和中心設(shè)備(大部分情況下是手機(jī))保持藍(lán)牙連接的狀態(tài)下,如果長(zhǎng)時(shí)間不產(chǎn)生交互,藍(lán)牙就會(huì)斷開(kāi),所以為了保持兩者持續(xù)的連接狀態(tài),需要做保活處理,也就是需要持續(xù)的發(fā)送心跳包(watchdog)。相應(yīng)的處理是使用一個(gè)定時(shí)器定時(shí)向設(shè)備側(cè)發(fā)送符合設(shè)備協(xié)議格式的心跳包。
斷開(kāi)連接很簡(jiǎn)單,只需要調(diào)用 [self.centralManager cancelPeripheralConnection:peripheral] 傳入需要斷開(kāi)連接的設(shè)備對(duì)象就行了。斷開(kāi)連接時(shí)會(huì)自動(dòng)調(diào)用 centralManager:didDisconnectPeripheral:error: 代理方法。
按照之前的慣例,當(dāng)error為nil時(shí)表示斷開(kāi)成功,error不為nil時(shí)斷開(kāi)失敗。這種理解是錯(cuò)誤的。
當(dāng)你調(diào)用 cancelPeripheralConnection: 方法(主動(dòng)斷開(kāi))斷開(kāi)連接時(shí)error為nil ; 沒(méi)有調(diào)用這個(gè)方法(異常斷開(kāi))而斷開(kāi)時(shí)error返回的是異常斷開(kāi)的原因。也可以理解為主動(dòng)調(diào)用斷開(kāi)連接方法一定會(huì)斷開(kāi)
接下來(lái)就是斷開(kāi)重連的問(wèn)題了,對(duì)藍(lán)牙功能進(jìn)行封裝時(shí)肯定少不了斷開(kāi)重連。首先斷開(kāi)時(shí)可通過(guò)上面的代理方法的error是否為nil判斷是否是異常斷開(kāi),一般情況下異常斷開(kāi)時(shí)是需要重連的
原因就是當(dāng)設(shè)備斷開(kāi)連接后 peripheral.services 為nil了,當(dāng)然 service.characteristics 也是nil,所以需要在斷開(kāi)連接時(shí)把保存這個(gè)設(shè)備對(duì)應(yīng)的服務(wù)和特征全部清除,然后在連接成功時(shí)重新過(guò)一遍發(fā)現(xiàn)服務(wù)和發(fā)現(xiàn)特征的流程就好了。
iOS7 開(kāi)始,Apple加入了Beacon圍欄檢測(cè)的API, ( iBeacon-維基百科 ), 其工作方式是,配備有低功耗藍(lán)牙(BLE)通信功能的設(shè)備使用 BLE 技術(shù)向周圍發(fā)送自己特有的 ID,接收到該 ID 的應(yīng)用軟件會(huì)根據(jù)該 ID 采取一些行動(dòng)。比如,在店鋪里設(shè)置 iBeacon 通信模塊的話,便可讓 iPhone 和 iPad 上運(yùn)行一資訊告知服務(wù)器,或者由服務(wù)器向顧客發(fā)送折扣券及進(jìn)店積分, 或者公司的手機(jī)打卡,只要手機(jī)靠近打卡器一定范圍,手機(jī)測(cè)就向打開(kāi)器發(fā)送打卡信息,從而自動(dòng)打卡。這種場(chǎng)景還有很多。 其中一個(gè)最重要的功能就是App的喚醒功能(殺死后也能喚醒)
舉一個(gè)我們的例子,我們的產(chǎn)品業(yè)務(wù)場(chǎng)景就是在進(jìn)入車輛以后,需要使用藍(lán)牙連接我們的后裝車載設(shè)備以采集車輛信息和駕駛行為行程等,這里有一個(gè)問(wèn)題就是在App被殺死的情況下如何喚醒App, 因?yàn)椴豢赡芤笥脩裘看味贾鲃?dòng)去打開(kāi)App,這樣體驗(yàn)太差。我們的做法是通過(guò)iBeacon,當(dāng)我們的車輛點(diǎn)火以后,設(shè)備測(cè)通電,發(fā)出 iBeacon廣播 ,App實(shí)現(xiàn)監(jiān)聽(tīng)iBeacon相關(guān)功能后就可以喚醒我們App,然后在相應(yīng)的回調(diào)的處理一些事情,比如通過(guò)藍(lán)牙連接設(shè)備。這里的前提條件是我們的硬件設(shè)備測(cè)包含iBeacon模塊,具有iBeacon功能,而且對(duì)iBeacon的廣播頻率也有一定的要求,長(zhǎng)了可能喚醒的功能會(huì)不穩(wěn)定,官方建議的好像是100ms,頻率超高越耗電,但可以讓手機(jī)或其它監(jiān)聽(tīng)設(shè)備越快地發(fā)現(xiàn)iBeacon。標(biāo)準(zhǔn)的BLE廣播距離是100m,這使Beacon在室內(nèi)位置跟蹤場(chǎng)景下的效果更理想。
關(guān)于iBeacon更多的使用及介紹請(qǐng)參考
蘋(píng)果核 - iOS端近場(chǎng)圍欄檢測(cè)(一) ——iBeacon
iBeacon技術(shù)初探
當(dāng)前名稱:ios藍(lán)牙開(kāi)發(fā)demo,ios藍(lán)牙app
當(dāng)前路徑:http://vcdvsql.cn/article12/dsdjigc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供用戶體驗(yàn)、品牌網(wǎng)站建設(shè)、關(guān)鍵詞優(yōu)化、建站公司、品牌網(wǎng)站制作、域名注冊(cè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)