iOS藍(lán)牙開發(fā)相關(guān)知識(shí)點(diǎn)和注意事項(xiàng)

總結(jié)一下藍(lán)牙開發(fā)相關(guān)的知識(shí)點(diǎn)和注意事項(xiàng)，做個(gè)筆記，也希望你們能少踩坑

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比城區(qū)網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式城區(qū)網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋城區(qū)地區(qū)。費(fèi)用合理售后完善，十余年實(shí)體公司更值得信賴。

(公司部分藍(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é)詳見： 傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙的區(qū)別

iOS中藍(lán)牙相關(guān)功能都封裝進(jìn)了 CoreBluetooth 類中,其中有幾個(gè)常見的參數(shù)和概念

具體API參考 CoreBluetooth藍(lán)牙開發(fā)

保存到數(shù)組中的設(shè)備可通過 UUID 來進(jìn)行區(qū)分。從 iOS7之后蘋果不提供外設(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)：

寫入數(shù)據(jù)時(shí)可能會(huì)遇到需要分包發(fā)送的情況，我們可以通過下面的API或許當(dāng)前特征支持的最大的單條寫入長(zhǎng)度

maxLength 一般取決于藍(lán)牙模塊內(nèi)部接收 緩沖區(qū) 的大小，很多硬件設(shè)備這個(gè)緩沖區(qū)的大小是 20 字節(jié), 這個(gè)大小也和特征的寫入權(quán)限有關(guān)，像具有寫入權(quán)限 withResponse 類的特征其大小一般為 512 字節(jié)，當(dāng)然這些都是取決于設(shè)備測(cè)的設(shè)置；

當(dāng)我們單次發(fā)送的數(shù)據(jù)字節(jié)長(zhǎng)度大于 maxLength 時(shí)，我們就需要采用分包的方式來發(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ì)斷開，所以為了保持兩者持續(xù)的連接狀態(tài)，需要做保活處理，也就是需要持續(xù)的發(fā)送心跳包(watchdog)。相應(yīng)的處理是使用一個(gè)定時(shí)器定時(shí)向設(shè)備側(cè)發(fā)送符合設(shè)備協(xié)議格式的心跳包。

斷開連接很簡(jiǎn)單，只需要調(diào)用 [self.centralManager cancelPeripheralConnection:peripheral] 傳入需要斷開連接的設(shè)備對(duì)象就行了。斷開連接時(shí)會(huì)自動(dòng)調(diào)用 centralManager:didDisconnectPeripheral:error: 代理方法。

按照之前的慣例，當(dāng)error為nil時(shí)表示斷開成功，error不為nil時(shí)斷開失敗。這種理解是錯(cuò)誤的。

當(dāng)你調(diào)用 cancelPeripheralConnection: 方法（主動(dòng)斷開）斷開連接時(shí)error為nil ; 沒有調(diào)用這個(gè)方法（異常斷開）而斷開時(shí)error返回的是異常斷開的原因。也可以理解為主動(dòng)調(diào)用斷開連接方法一定會(huì)斷開

接下來就是斷開重連的問題了，對(duì)藍(lán)牙功能進(jìn)行封裝時(shí)肯定少不了斷開重連。首先斷開時(shí)可通過上面的代理方法的error是否為nil判斷是否是異常斷開，一般情況下異常斷開時(shí)是需要重連的

原因就是當(dāng)設(shè)備斷開連接后 peripheral.services 為nil了，當(dāng)然 service.characteristics 也是nil，所以需要在斷開連接時(shí)把保存這個(gè)設(shè)備對(duì)應(yīng)的服務(wù)和特征全部清除，然后在連接成功時(shí)重新過一遍發(fā)現(xiàn)服務(wù)和發(fā)現(xiàn)特征的流程就好了。

iOS7 開始，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è)就向打開器發(fā)送打卡信息，從而自動(dòng)打卡。這種場(chǎng)景還有很多。 其中一個(gè)最重要的功能就是App的喚醒功能(殺死后也能喚醒)

舉一個(gè)我們的例子，我們的產(chǎn)品業(yè)務(wù)場(chǎng)景就是在進(jìn)入車輛以后，需要使用藍(lán)牙連接我們的后裝車載設(shè)備以采集車輛信息和駕駛行為行程等，這里有一個(gè)問題就是在App被殺死的情況下如何喚醒App, 因?yàn)椴豢赡芤笥脩裘看味贾鲃?dòng)去打開App，這樣體驗(yàn)太差。我們的做法是通過iBeacon，當(dāng)我們的車輛點(diǎn)火以后，設(shè)備測(cè)通電，發(fā)出 iBeacon廣播 ，App實(shí)現(xiàn)監(jiān)聽iBeacon相關(guān)功能后就可以喚醒我們App，然后在相應(yīng)的回調(diào)的處理一些事情，比如通過藍(lán)牙連接設(shè)備。這里的前提條件是我們的硬件設(shè)備測(cè)包含iBeacon模塊，具有iBeacon功能，而且對(duì)iBeacon的廣播頻率也有一定的要求，長(zhǎng)了可能喚醒的功能會(huì)不穩(wěn)定，官方建議的好像是100ms，頻率超高越耗電，但可以讓手機(jī)或其它監(jiān)聽設(shè)備越快地發(fā)現(xiàn)iBeacon。標(biāo)準(zhǔn)的BLE廣播距離是100m，這使Beacon在室內(nèi)位置跟蹤場(chǎng)景下的效果更理想。

關(guān)于iBeacon更多的使用及介紹請(qǐng)參考

蘋果核 - iOS端近場(chǎng)圍欄檢測(cè)（一） ——iBeacon

iBeacon技術(shù)初探

iOS 藍(lán)牙BLE開發(fā)

GAP（Generic Access Profile）：它用來控制設(shè)備連接和廣播，GAP 使你的設(shè)備被其他設(shè)備可見，并決定了你的設(shè)備是否可以或者怎樣與合同設(shè)備進(jìn)行交互。

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è)備讀寫設(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í)，開啟掃描，設(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 Ble開發(fā)丟包問題

最近一直在開發(fā)通過ble進(jìn)行設(shè)備與App交互的產(chǎn)品。在開發(fā)過程中，手機(jī)一直作為中央設(shè)備，負(fù)責(zé)主動(dòng)發(fā)起掃描連接，而設(shè)備作為邊緣設(shè)備。需求需要兩者發(fā)送指令，傳輸文件。文件的傳輸就是將設(shè)備中的文件拆解成一包一包的數(shù)據(jù)通過ble發(fā)送給App。在設(shè)備與App定義了一套通用的協(xié)議的基礎(chǔ)上，兩者的指令發(fā)送很正常，因?yàn)橹噶畹陌l(fā)送簡(jiǎn)短而且單一，雙方處理沒有問題。但是在發(fā)送文件時(shí)，遇到了嚴(yán)重的丟包問題。當(dāng)時(shí)設(shè)置的設(shè)備發(fā)送數(shù)據(jù)到App，拆分的數(shù)據(jù)包大小是180個(gè)字節(jié)，這在iphone6s上已經(jīng)達(dá)到上限了。但是在發(fā)送文件時(shí)，App上接受的數(shù)據(jù)會(huì)出現(xiàn)丟包，首先懷疑的是設(shè)備端沒有將數(shù)據(jù)發(fā)送出來，后來設(shè)備端改了發(fā)送邏輯，在每一包數(shù)據(jù)發(fā)送之后，在收到底層的發(fā)送成功回調(diào)之后再發(fā)送下一包數(shù)據(jù)，在這種模式下，App端接受到的數(shù)據(jù)還是會(huì)丟。當(dāng)時(shí)問題很困擾，App端覺得是設(shè)備端的問題，設(shè)備端覺得是App端的問題。后來我想到了一種場(chǎng)景，在那種場(chǎng)景的啟發(fā)下，我覺得現(xiàn)在這種場(chǎng)景是之前那種場(chǎng)景的反向。

之前我在做一款A(yù)I 語音耳機(jī)時(shí)，也是通過ble傳輸實(shí)時(shí)音頻以及進(jìn)行OTA（固件升級(jí)）的。當(dāng)時(shí)在傳輸OTA數(shù)據(jù)包時(shí)，由于耳機(jī)的內(nèi)存不夠，在我一直發(fā)送文件包時(shí)，耳機(jī)會(huì)crash，后來固件排查下來由于內(nèi)存不夠，在瘋狂發(fā)送數(shù)據(jù)時(shí)，把內(nèi)存撐爆了，導(dǎo)致了耳機(jī)的奔潰，最后的解決方案是我對(duì)發(fā)送的每一包數(shù)據(jù)都設(shè)置了合適的長(zhǎng)度外，還在每一包的發(fā)送過程中進(jìn)行sleep，給固件時(shí)間去進(jìn)行處理，這樣問題就解決了。

然后我聯(lián)想到這次的問題，由于不同的手機(jī)采用的藍(lán)牙芯片參差不齊，不同的藍(lán)牙芯片的處理能力又不同，所以我懷疑在固件瘋狂發(fā)送數(shù)據(jù)到手機(jī)上時(shí)，根據(jù)不同手機(jī)的藍(lán)牙芯片的處理能力，會(huì)出現(xiàn)丟包的大小也不一樣。針對(duì)這種懷疑，我們測(cè)試了iphone6s，iphonex，iphone11，發(fā)現(xiàn)后兩臺(tái)設(shè)備的丟包率明顯小很多。我們又測(cè)試了不同價(jià)位的Android手機(jī)，也發(fā)現(xiàn)低端Android手機(jī)的丟包率也明顯大于中高端手機(jī)。在基于這種測(cè)試基礎(chǔ)上，提出了解決方案：1.降低每個(gè)數(shù)據(jù)包的大小，2.每個(gè)數(shù)據(jù)包間隔時(shí)間發(fā)送，這個(gè)時(shí)間需要測(cè)試。在經(jīng)過測(cè)試之后，單純第一點(diǎn)解決方案和第二點(diǎn)解決方案都不會(huì)達(dá)到最理想的結(jié)果，所以合適的方案就是兩者結(jié)合，將丟包率降到更低。所以最終的解決方案就是降低每一包的大小的同時(shí)，也保證每包數(shù)據(jù)包的發(fā)送間隔，這兩者的數(shù)據(jù)我們是通過測(cè)試之后拿到的平衡值，針對(duì)不同的固件的藍(lán)牙芯片這個(gè)數(shù)據(jù)可能都是不同的。

兜兜轉(zhuǎn)轉(zhuǎn)了一圈查到了丟包問題的原因，其實(shí)這個(gè)原因不難想，我跟固件開發(fā)當(dāng)時(shí)都覺得是對(duì)方處理的問題，導(dǎo)致一直沒有從全局去看這個(gè)問題，記錄一下。

iOS 低功耗藍(lán)牙4.0開發(fā)指南。

1.什么是藍(lán)牙4.0，藍(lán)牙其它標(biāo)準(zhǔn)又是什么？

詳細(xì)描述：低功耗藍(lán)牙(Low Energy; LE)，又視為Bluetooth Smart或藍(lán)牙核心規(guī)格4.0版本。其特點(diǎn)具備節(jié)能、便于采用，是藍(lán)牙技術(shù)專為物聯(lián)網(wǎng)(Internet of Things; IOT)開發(fā)的技術(shù)版本。所以它最主要的特點(diǎn)是低功耗，普及率高。現(xiàn)在所說的藍(lán)牙設(shè)備，大部分都是在說4.0設(shè)備，ble也特指4.0設(shè)備。 在4.0之前重要的版本有 2.1版本-基本速率／增強(qiáng)數(shù)據(jù)率(BR/EDR) 和 3.0 高速藍(lán)牙 版本，這些統(tǒng)稱為經(jīng)典藍(lán)牙。4.0還有4.1和4.2的小版本，其中4.2版本對(duì)傳輸速率做了進(jìn)一步他提升，提高了2.5倍，蘋果從iphone6開始使用4.2，最新的藍(lán)牙標(biāo)準(zhǔn)為藍(lán)牙5.0，其中最大的特點(diǎn)連接范圍擴(kuò)大了4倍，速度又提高了2倍，無連接數(shù)據(jù)廣播能力提高了8倍，增加了藍(lán)牙組網(wǎng)的能力。

2.藍(lán)牙開發(fā)必須知道的概念。

2.1.1 central和peripheral：

藍(lán)牙應(yīng)用開發(fā)中，存在兩種角色，分別是central和peripheral(p?’r?f?r?l) ,中文就是中心和外設(shè)。比如手機(jī)去連接智能設(shè)備，那手機(jī)就是central，智能設(shè)備就是peripheral。大多時(shí)候都是central去連接peripheral的場(chǎng)景。

2.1.2 廣播和連接:

peripheral會(huì)發(fā)出廣播,central掃描到廣播后，可以對(duì)設(shè)備進(jìn)行連接，發(fā)出connect請(qǐng)求，peripheral接收到請(qǐng)求后，同意連接后，central和peripheral就建立了連接。

2.1.3?連接后的操作:

write，read，notify，indecate， response or not …

indecate和notify的區(qū)別就在于，indecate是一定會(huì)收到數(shù)據(jù)，notify有可能會(huì)丟失數(shù)據(jù)（不會(huì)有central收到數(shù)據(jù)的回應(yīng)），write也分為response和noresponse，如果是response，那么write成功回收到peripheral的確認(rèn)消息，但是會(huì)降低寫入的速率。

2.1.4 協(xié)議:

每個(gè)具體的智能設(shè)備，都約定了一組數(shù)據(jù)格式，這個(gè)就是數(shù)據(jù)協(xié)議，例如手環(huán)中獲取到數(shù)據(jù)0X001023，其中第2位到第5位表示步數(shù)，那么就2310就是步數(shù)的16進(jìn)制的數(shù)據(jù)，轉(zhuǎn)換成10進(jìn)制就是8976步，需要注意的是，設(shè)備端都是小端模式，所以取4位時(shí)候，高字節(jié)在前低字節(jié)在后。

3. iOS藍(lán)牙應(yīng)用的一般開發(fā)流程。

4. 藍(lán)牙的數(shù)據(jù)交互。

write，read，notify，indecate， response or not … 都是容易理解的，indecate和notify對(duì)應(yīng)的是長(zhǎng)連接，建立indecate后，peripheral可以隨時(shí)往central發(fā)送數(shù)據(jù)。

indecate和notify的區(qū)別就在于，indecate是一定會(huì)收到數(shù)據(jù)，notify有可能會(huì)丟失數(shù)據(jù)（不會(huì)有central收到數(shù)據(jù)的回應(yīng)），write也分為response和noresponse，如果是response，那么write成功回收到peripheral的確認(rèn)消息，但是會(huì)降低寫入的速率。

對(duì)于一個(gè)charateristic，他的讀寫訂閱的權(quán)限是peripheral決定的，熟悉可以被同時(shí)設(shè)置，一般會(huì)根據(jù)外設(shè)的功能來決定。

5.藍(lán)牙ota DFU。

藍(lán)牙ota,DFU（Device Firmware Update）指的是藍(lán)牙設(shè)備的固件升級(jí)，其實(shí)是一整套流程，不同的藍(lán)牙芯片，ota的流程有不同之處，我這里用ti的芯片舉例。步驟為：切系統(tǒng)(bootloader mode)，重啟，傳輸數(shù)據(jù)，驗(yàn)證數(shù)據(jù)，切系統(tǒng)，重啟，完成。

其中數(shù)據(jù)傳輸也會(huì)分成很多節(jié)去發(fā)送，沒法送一段數(shù)據(jù)，做一次數(shù)據(jù)校驗(yàn)。

6.ota存在的問題。

每個(gè)智能設(shè)備的速率，功耗，存儲(chǔ)都會(huì)有很多限制，導(dǎo)致很多設(shè)備會(huì)自己去實(shí)現(xiàn)ota的功能，自定義流程和數(shù)據(jù)傳輸方式，導(dǎo)致許多設(shè)備都是有自己私有的ota模式和協(xié)議，所以在做開發(fā)的時(shí)候，要仔細(xì)閱讀設(shè)備協(xié)議中對(duì)ota的描述。

7.如何做自動(dòng)重連。

只需要在設(shè)備斷開連接的委托方法中，重新調(diào)用gatt.connet或者是centralManager.connet方法就可以了，無論當(dāng)時(shí)設(shè)備是否有點(diǎn)，是否在周圍，當(dāng)設(shè)備再次開會(huì)或者連接到可連接范圍內(nèi)，都會(huì)自動(dòng)被連上。

8.連接失敗處理。

分兩個(gè)平臺(tái)來說，iOS端也有連接失敗的委托，但是好像幾乎不會(huì)發(fā)生這種情況，而對(duì)于同款設(shè)備，android常常會(huì)出現(xiàn)連接失敗的情況，status != BluetoothGatt.GATT_SUCCESS，android端開發(fā)請(qǐng)不要把連接失敗和斷開連接放在一塊處理，因?yàn)閿嚅_連接可以直接嘗試重新連接，而連接失敗后嘗試重新連接，需要加一些延時(shí)，并且需要gatt.close，清空一下狀態(tài)，否則會(huì)把gatt阻塞導(dǎo)致手機(jī)不重啟藍(lán)牙就再也無法連接任何設(shè)備的情況 。

9.后臺(tái)運(yùn)行。

iOS后來運(yùn)行，需要設(shè)備中info.Plist權(quán)限，key:Required background modes ,value: bluetooth-central(手機(jī)作為central) , bluetooth-peripheral。

10.同時(shí)連接多個(gè)設(shè)備。

使用同一個(gè)CBCentralManager，通過進(jìn)入委托的peripheral的identifier區(qū)分不同的設(shè)備，進(jìn)行不同的操作和處理。

11.掃描廣播包。

所有外設(shè)，只有在發(fā)出廣播包的情況下，才能被central發(fā)現(xiàn)，絕大多數(shù)情況下，外設(shè)被連接后就不會(huì)發(fā)出廣播（也有例外），很多人遇到無法找到設(shè)備的問題，大多屬于這種情況。

12.提高藍(lán)牙連接速度。

無論是iOS，還是android，都可以通過已綁定的設(shè)備，在不開啟掃描的情況下進(jìn)行快速連接，iOS需要的參數(shù)是peripheral的identifier，android需要mac地址。但android和iOS還是有一些區(qū)別的，比如iOS不能拿到已綁定的設(shè)備list，但是可以通過UUID去拿到peripheral的實(shí)例。而android可以拿到已綁定的設(shè)備list。android綁定過程需要手動(dòng)調(diào)用createBond的方法，而iOS在連接成功一次后會(huì)自動(dòng)綁定。 android在處理createBond時(shí)，常常會(huì)應(yīng)為不同手機(jī)平臺(tái)，不同設(shè)備，會(huì)產(chǎn)生兼容性的問題，這點(diǎn)需要注意。

13.定向掃描。

在掃描時(shí)候可以傳入serviceUUID，這樣可以掃描到特定條件的設(shè)備，提高掃描的速度，排除干擾。

14.如何獲取mac地址。

而iOS出于蘋果的安全策略問題，無法直接獲得mac地址，只能得到一個(gè)mac地址換算出來的identifier。

iOS BLE 開發(fā)小記[1] - CoreBluetooth 是什么

現(xiàn)在我們都知道，很多智能硬件設(shè)備都已經(jīng)集成了低功耗藍(lán)牙模塊，這樣我們就可以開發(fā)一個(gè) iOS 或者 Mac APP 與它們進(jìn)行交互。從 macOS 10.9 和 iOS 6 以后，Mac 和 iOS 設(shè)備就支持 低功耗藍(lán)牙技術(shù)了，我們可以通過 CoreBluetooth 這個(gè)框架與底層的各種藍(lán)牙協(xié)議棧進(jìn)行交互，比如 GATT、ATT 和 L2CAP 等。

與底層交互的過程如下圖所示：

開始下文之前，我們需要了解幾個(gè)概念。對(duì)藍(lán)牙不夠了解的可以看一下維基百科關(guān)于 藍(lán)牙 的簡(jiǎn)介。

Bluetooth 4.0 : 藍(lán)牙 4.0 是 Bluetooth SIG 于2010年7月7日推出的新的規(guī)范，其最重要的特性是功耗低，省電！

BLE : Bluetooth low energy wireless technology,也就是低功耗無線藍(lán)牙技術(shù)。

BLE 是關(guān)于藍(lán)牙4.0 的詳細(xì)說明，它定義了一套用于低功耗設(shè)備之間通信的協(xié)議。而CoreBluetooth 則是對(duì) BLE 協(xié)議棧的抽象。也就是說，它隱藏了許多底層的詳細(xì)實(shí)現(xiàn)細(xì)節(jié)，這樣對(duì)我們開發(fā)者來說，開發(fā)一個(gè) APP 與 BLE 設(shè)備進(jìn)行交互將會(huì)很便捷。

CoreBluetooth 中最關(guān)鍵的兩個(gè)角色就是 Central(中心) 和 Peripheral（周邊）, Peripheral 一般是提供數(shù)據(jù)的一方，而 Central 一般獲取 Peripheral 提供的數(shù)據(jù)然后來完成特定的任務(wù)。舉個(gè)例子，一個(gè)集成 BLE 的數(shù)字室溫計(jì)可能提供房間中的實(shí)時(shí)溫度，我們通過 APP 就可以讀取、分析和顯示房間中的溫度。

Peripheral 通過向空中廣播數(shù)據(jù)的方式來使我們能感知到它的存在。Central 通過掃描搜索來發(fā)現(xiàn)周圍正在廣播數(shù)據(jù)的 Peripheral, 找到指定的 Peripheral 后，發(fā)送連接請(qǐng)求進(jìn)行連接，連接成功后則與 Peripheral 進(jìn)行一些數(shù)據(jù)交互， Peripheral 則會(huì)通過合適的方式對(duì) Central 進(jìn)行響應(yīng)。

CoreBluetooth 對(duì)通用的藍(lán)牙任務(wù)進(jìn)行了簡(jiǎn)化處理，你在 App 中通過 CoreBluetooth 來集成 BLE 功能將會(huì)變得簡(jiǎn)單，如果你開發(fā)的 APP 遵循了 Centrals 的開發(fā)規(guī)范，CoreBluetooth 將會(huì)幫你處理與 Peripheral 的掃描、連接以及數(shù)據(jù)交互的過程，除此之外，通過 CoreBluetooth 將你的設(shè)備設(shè)置為 本地 Peripheral 也會(huì)很便捷。

iOS APP 的狀態(tài)也會(huì)影響藍(lán)牙的行為，當(dāng)你的 APP 在后臺(tái)運(yùn)行或者處于暫停狀態(tài)中，藍(lán)牙的行為將會(huì)受到影響。默認(rèn)情況下，當(dāng)你的 APP 在后臺(tái)運(yùn)行時(shí)或者處于暫停狀態(tài)中，你的 APP 是不能與 BLE 進(jìn)行數(shù)據(jù)通信的，也就是說，當(dāng) APP 后臺(tái)運(yùn)行時(shí)，你需要與 BLE 進(jìn)行數(shù)據(jù)通信，你需要聲明你的 APP 支持藍(lán)牙后臺(tái)運(yùn)行模式，即使你聲明了支持后臺(tái)運(yùn)行模式，藍(lán)牙在后臺(tái)運(yùn)行模式下的數(shù)據(jù)處理方式也會(huì)變得不同，當(dāng)開發(fā)你的 BLE APP 時(shí)，你需要注意這些不同點(diǎn)。

即使 APP 在后臺(tái)運(yùn)行時(shí)，當(dāng)系統(tǒng)內(nèi)存過低時(shí)也會(huì)殺掉 APP 的后臺(tái)進(jìn)程，對(duì)于 iOS 7，CoreBluetooth 支持 Central 和 Peripheral 的狀態(tài)信息的保存和恢復(fù)。可以通過這個(gè)功能來實(shí)現(xiàn)與 BLE 設(shè)備的長(zhǎng)期交互。

CoreBluetooth 框架為你的 APP 與許多常見的 BLE 設(shè)備進(jìn)行交互提供了交互接口，通過合理的利用和實(shí)踐將會(huì)提高用戶的體驗(yàn)。

舉個(gè)例子，當(dāng)你實(shí)現(xiàn) Central 或 Peripheral 的功能時(shí)，會(huì)利用設(shè)備攜帶的無線電廣播設(shè)備（Radio）向空中廣播信號(hào)，這樣就會(huì)影響到電池的續(xù)航時(shí)間，因此當(dāng)你設(shè)計(jì) APP 時(shí)，需要盡可能的減少 Radio 的使用頻率。

重要提醒： 在 iOS 10以后，通過 CoreBluetooth 與 BLE 設(shè)備進(jìn)行數(shù)據(jù)通信時(shí)，必須在項(xiàng)目的 Info.plist 文件中包含關(guān)于 NSBluetoothPerpheralUsageDescription 的描述,否則會(huì)導(dǎo)致 APP 閃退，詳情見 NSBluetoothPerpheralUsageDescription 。

在 BLE 通信中主要包含兩種角色：Central（中心）和 Peripheral（周邊），基于傳統(tǒng)的客戶-服務(wù)器架構(gòu)，Peripheral 通常會(huì)提供其他設(shè)備需要的數(shù)據(jù)，Central 通常利用通過 Peripheral 獲取的信息來完成特定的任務(wù)，如圖所示，心率監(jiān)視器 提供數(shù)據(jù)給 Mac 或 iOS APP，然后來顯示用戶的心率數(shù)據(jù)。

Peripheral 以廣播數(shù)據(jù)包的形式廣播服務(wù)中的數(shù)據(jù)，廣播數(shù)據(jù)包指的是包含 Peripheral 有用信息的一個(gè)較小數(shù)據(jù)包，比如 Peripheral 的名字和主要功能數(shù)據(jù)。比如，一個(gè)數(shù)字室溫計(jì)廣播的數(shù)據(jù)中可能包括當(dāng)前室溫，對(duì)于 BLE，廣播是顯示它們存在的主要方式。

如圖，對(duì)于一個(gè) Central 來說，它能夠搜索和獲取到它想要的 Peripheral 的廣播信息。

連接 Peripheral 的目的就是和 Peripheral 提供的數(shù)據(jù)進(jìn)行交互，在你理解這一點(diǎn)后，可以更好的明白 Peripheral 的數(shù)據(jù)組成結(jié)構(gòu)。

Peripheral 包含一個(gè)或多個(gè) Service(服務(wù))和連接信號(hào)強(qiáng)度的有用信息。Service 可以理解成是一個(gè)完成指定功能的數(shù)據(jù)集合。舉個(gè)例子，一個(gè)心率監(jiān)測(cè)服務(wù)的功能就是可能就是從心率傳感器中讀取心率數(shù)據(jù)。

Service 是由 Characteristic（特征） 組成的，Characteristic 為 Peripheral 的 Service 提供更詳細(xì)的信息，舉個(gè)例子，心率服務(wù)可能包含一個(gè)測(cè)量不同體位的心率數(shù)據(jù)的 Characteristic 和一個(gè)傳輸心率數(shù)據(jù)的 Characteristic，下圖所示的是一個(gè)心率監(jiān)測(cè)設(shè)備的數(shù)據(jù)組成結(jié)構(gòu)。

當(dāng) Central 與 Peripheral 建立成功的連接后，Central 可以發(fā)現(xiàn) Peripheral 提供的全系列的 Service 和 Characteristic，廣播數(shù)據(jù)包中的數(shù)據(jù)僅僅是可用服務(wù)的一小部分而已。

Central 可以通過讀取或?qū)懭?Service Characteristic 值的方式與 Service 進(jìn)行交互。你的 APP 也許需要從數(shù)字室溫計(jì)中獲取當(dāng)前室內(nèi)的溫度或者設(shè)置一個(gè)溫度值到數(shù)字室溫計(jì)中。

BLE 通信過程中涉及到的主要角色和數(shù)據(jù)處理已經(jīng)簡(jiǎn)單的集成到 CoreBluetooth 框架中了。

當(dāng)你通過本地 Central 與周邊 Peripheral 進(jìn)行交互時(shí)，你只需要調(diào)用 Central 方面的方法就可以了，除非你設(shè)置一個(gè)本地 Peripheral，并用它來響應(yīng)其他的 Central 的交互請(qǐng)求，實(shí)際運(yùn)用中，你的藍(lán)牙處理大部分會(huì)在 Central 方面。

在 Central 方面，用 CBCentralManager 對(duì)象來表示一個(gè)Local Central 設(shè)備，這個(gè)對(duì)象被用來管理 Remote Peripheral 設(shè)備（用 CBPeripheral 對(duì)象來表示），包括搜索和連接正在廣播數(shù)據(jù)的 Peripheral。如圖所示的是 CoreBluetooth 框架中如何表示 Local Central 和 Remote Peripheral。

當(dāng)你與 Remote Peripheral 進(jìn)行數(shù)據(jù)交互時(shí)，你將處理它的 Service 和 Characteristic，在 CoreBluetooth 框架中，用 CBService 對(duì)象來表示 Peripheral 中的服務(wù)，同樣地，用 CBCharacteristic 對(duì)象來表示 Service 中的特征。下圖所示的是 Remote Peripheral 的服務(wù)特征結(jié)構(gòu)樹。

對(duì)于 macOS 10.9 和 iOS 6， Mac 和 iOS 設(shè)備可以實(shí)現(xiàn) BLE Peripheral 的功能，如為其他設(shè)備（包括 Mac，iPhone，和 iPad）提供數(shù)據(jù)。當(dāng)你遵循 Peripheral 的開發(fā)規(guī)范時(shí)，就可以調(diào)用 BLE 通信的 Peripheral 方面的方法。

在 Peripheral 方面，一個(gè) Local Peripheral 可以用 CBPeripheralManager 對(duì)象來表示，這個(gè)對(duì)象被用來管理發(fā)布包含的服務(wù)，包括組織構(gòu)建 Peripheral 的數(shù)據(jù)結(jié)構(gòu)以及向中心設(shè)備廣播數(shù)據(jù)，Peripheral Manager 也對(duì) Remote Central的讀寫交互請(qǐng)求做出響應(yīng)。如圖所示的是一個(gè) Local Peripheral 和 Remote Central。

當(dāng)你設(shè)置并與 Local Peripheral 進(jìn)行數(shù)據(jù)交互時(shí)，你處理的是它的可變的 Service 和 Characteristic，在 CoreBluetooth 框架中，用 CBMutableService 對(duì)象來表示 Local Peripheral 中的服務(wù)，同樣地，用 CBMutableCharacteristic 對(duì)象來表示Local Peripheral 服務(wù)中的特征。下圖表示的是一個(gè) Local Peripheral 中的服務(wù)特征結(jié)構(gòu)樹。

后續(xù)章節(jié)會(huì)進(jìn)一步補(bǔ)充關(guān)于 BLE 開發(fā)的知識(shí)。

1、 TP40013257-CH1-SW1

2、 CoreBluetoothOverview

歡迎在本文下面留言一起交流心得...

在IOS 的開發(fā)中iBeacon和BLE的區(qū)別

在ios中ibeacon是基于地理位置的微定位技術(shù)（從這句話中可以得出Introduced in iOS 7, iBeacon is an exciting technology enabling new location awareness possibilities for apps.），雖然借助手機(jī)藍(lán)牙進(jìn)行接收Majro、Minor，但是他們?cè)陂_發(fā)工程中沒有任何關(guān)系。

ibeacon使用蘋果提供CoreLocation庫(kù)，然而在BLE在開發(fā)過程中使用CoreBluetooth庫(kù)。從上面提供的庫(kù)來看就很清楚了，特別是在IOS8之上的時(shí)候如果想使用ibeacon，必須讓用戶點(diǎn)擊是否允許“App使用地理位置”。如果在第一次使用ios app掃描ibeacon的時(shí)候沒有提示這句話是不可能接收到ibeacon的信號(hào)（除非ios 8.0之下）。如果是BLE則的開發(fā)過程中之需要提示用戶打開藍(lán)牙，并不要求其他的地理位置任何信息。

第一：在ios中所有的數(shù)據(jù)都是通過API獲取的，也就是說在IOS中不會(huì)看到藍(lán)牙模塊的裸數(shù)據(jù)（在這里的裸數(shù)據(jù)就代表藍(lán)牙模塊發(fā)送的16進(jìn)制的數(shù)據(jù)），只能拿到蘋果公司提供的極個(gè)別的API中的數(shù)據(jù)。

第二：ble、ibeacon各使用各自的API，他們之間沒有任何對(duì)應(yīng)關(guān)系。如果想使用ble就不可能獲取到ibeacon的major、minor、uuid等信息，如果使用ibeacon，沒有辦法發(fā)起鏈接請(qǐng)求獲取服務(wù)。

第三：在ios中ibeacon通信數(shù)據(jù)只有

這個(gè)六個(gè)屬性，其分別含義是“ proximityUUID major、minor表示ibeacon的uuid，major、minor；proximity就是蘋果提供的幾個(gè)表示距離的屬性CLProximityUnknown（沒有數(shù)據(jù)）,CLProximityImmediate（十厘米以內(nèi)）,CLProximityNear（一米以內(nèi)）,CLProximityFar（一米以外）”。

“在很多硬件人員的眼中認(rèn)為，ibeacon和ble沒有區(qū)別啊，我們都是在同一個(gè)模塊上面開發(fā)的，只是發(fā)送的數(shù)據(jù)格式不一樣，ibeacon應(yīng)該和ble沒有區(qū)別，ios可以獲取數(shù)據(jù)按照我們給的通信協(xié)議進(jìn)行解析就可以啊。”這個(gè)就犯了我剛才所說的一個(gè)錯(cuò)誤，在ios的開發(fā)過程中ibeacon和ble是兩個(gè)不同的東西，所有的數(shù)據(jù)都被蘋果攔截了，只給開發(fā)者特定的api可以調(diào)用。雖然從硬件上面來看沒有任何區(qū)別但是在開發(fā)過程中確實(shí)兩個(gè)不同的東西。但是有很多的廠商又想讓ble具有ibeacon的類似的功能，比如可以讓app獲取到major、minor這個(gè)又怎么辦？讓ios的app獲取ble的MAC地址等等功能（說明一下，ios是不能直接獲取ble的mac地址的）？在這里（只是我個(gè)人的意見也是我在工作中得到的一些方法）是我的建議，一般很多ble正在發(fā)送發(fā)現(xiàn)廣播的時(shí)候攜帶了“kCBAdvDataServiceData”信息，可以把ibeacon的major、minor放在kCBAdvDataServiceData的數(shù)據(jù)區(qū)域，然后讓app根據(jù)協(xié)議截取響應(yīng)的信息。也可以放到其他的信息中，這要看公司的策略。

如果有一款iOSble的巡檢App（非ibeacon的App）可以用BLE掃描出ibeacon的信息，他的App肯定不是直接掃描ibeacon，這一點(diǎn)可以從兩個(gè)方面進(jìn)行驗(yàn)證第一：是否使用用戶的地理位置，第二：拿一個(gè)其他廠家的標(biāo)準(zhǔn)ibeacon，（ibeacon的uuid一定不要一樣，因?yàn)閕os在掃描ibeacon的時(shí)候一定要指定需要掃描的uuid，換一個(gè)uuid

app都不可能掃描到）。通過上面兩點(diǎn)可以很好的判定app是巡檢ble還是ibeacon。

總結(jié)上面所有的觀點(diǎn)，如果想使用ios的app巡檢ble又能巡檢ibeacon，一定要在藍(lán)牙模塊的廣播數(shù)據(jù)中做文章。怎么做文章需要各廠商自己權(quán)衡。

iPhone用戶可以在未打開App情況下（App被用戶開啟過，并且授權(quán)使用藍(lán)牙以及定位，并且藍(lán)牙處于開啟狀態(tài)），收到IBeacon設(shè)備（藍(lán)牙外設(shè)設(shè)備）廣播的信息，并短暫的激活該App （約10秒）去執(zhí)行一些方法。

根據(jù)IBeacon設(shè)備的發(fā)射范圍，確定用戶當(dāng)前的狀態(tài)：進(jìn)入、持續(xù)監(jiān)聽、離開。然后做出不同的響應(yīng)

藍(lán)牙掃一掃；區(qū)域推送；活動(dòng)現(xiàn)場(chǎng)互動(dòng)（配對(duì)，尋寶等）；簽到，藍(lán)牙鎖（應(yīng)用內(nèi)手動(dòng)簽到、開鎖或者點(diǎn)亮屏幕即可簽到、開鎖）。

藍(lán)牙連接打印機(jī)

當(dāng)前標(biāo)題：iosble開發(fā),iossible
分享地址：http://chinadenli.net/article41/dseeoed.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、營(yíng)銷型網(wǎng)站建設(shè)、App設(shè)計(jì)、網(wǎng)站導(dǎo)航、App開發(fā)、網(wǎng)站設(shè)計(jì)公司

廣告

聲明：本網(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í)需注明來源： 創(chuàng)新互聯(lián)