iOS開發(fā)之藍(lán)牙/Socket鏈接小票打印機(jī)（二）

上一篇 主要介紹了部分ESC/POS指令集，包括一些常用的排版指令，打印位圖指令等。另外，還介紹了將圖片轉(zhuǎn)換成點(diǎn)陣圖的方法。在這篇文章中，將主要介紹通過藍(lán)牙和Socket連接打印機(jī)，發(fā)送打印指令相關(guān)知識。這里將用到 CoreBluetooth.framework 和 CocoaAsyncSocket 。

10年積累的成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有龍勝免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

藍(lán)牙是一種支持設(shè)備間短距離通訊的無線電技術(shù)。iOS系統(tǒng)中，有四個(gè)框架支持藍(lán)牙鏈接：

CoreBluetooth框架有兩個(gè)核心概念，central（中心）和 peripheral（外設(shè)），它們分別有自己對應(yīng)的API；這里顯然是手機(jī)作為central，藍(lán)牙打印機(jī)作為peripheral；

設(shè)置代理后，會回調(diào)此方法，確認(rèn)藍(lán)牙狀態(tài)，當(dāng)狀態(tài)為 CBCentralManagerStatePoweredOn 才能去掃描設(shè)備，藍(lán)牙狀態(tài)變化時(shí)，也會回調(diào)此方法

調(diào)用此方法開始掃描外設(shè)

注意：第一個(gè)參數(shù)指定一個(gè) CBUUID 對象數(shù)組，每個(gè)對象表示外圍設(shè)備正在通告的服務(wù)的通用唯一標(biāo)識符（UUID）。此時(shí)，僅返回公布這些服務(wù)的外設(shè)。當(dāng)參數(shù)為 nil ，則返回所有已發(fā)現(xiàn)的外設(shè)，而不管其支持的服務(wù)是什么。

當(dāng)掃描到4.0外設(shè)后會回調(diào)此方法，這里包含設(shè)備的相關(guān)信息，如名稱、UUID、信號強(qiáng)度等；

調(diào)用此方法連接外設(shè)

[self.centralManager connectPeripheral:peripheral options:nil];

注意：第一個(gè)參數(shù)是要連接的外設(shè)。第二個(gè)參數(shù) options 是可選的 NSDictionary ,系統(tǒng)定義了一下三個(gè)鍵，它們的值都是NSNumber (Boolean)；默認(rèn)為NO。當(dāng)設(shè)置為YES，則應(yīng)用進(jìn)入后臺或者被掛起后，系統(tǒng)會用Alert通知藍(lán)牙外設(shè)的狀態(tài)變化，效果是這樣

連接成功或失敗，都有對應(yīng)的回調(diào)方法

連接成功后設(shè)置代理 peripheral.delegate = self ,調(diào)用 [peripheral discoverServices:nil]; 尋找外設(shè)內(nèi)的服務(wù)。這里的參數(shù)是一個(gè)存放 CBUUID 對象的數(shù)組，用于發(fā)現(xiàn)特定的服務(wù)。當(dāng)傳nil時(shí)，表示發(fā)現(xiàn)外設(shè)內(nèi)所有的服務(wù)。發(fā)現(xiàn)服務(wù)后系統(tǒng)會回調(diào)下面的方法:

發(fā)現(xiàn)服務(wù)后，調(diào)用 [peripheral discoverCharacteristics:nil forService:service]; 去發(fā)現(xiàn)服務(wù)中包含的特征。和上面幾個(gè)方法一樣，第一個(gè)參數(shù)用于發(fā)現(xiàn)指定的特征。為nil時(shí)，表示發(fā)現(xiàn)服務(wù)的所有特征。

當(dāng)掃描到寫入特征時(shí)，保存，用于寫入數(shù)據(jù)。

寫入數(shù)據(jù)，我們只需要調(diào)用方法

這里的 self.peripheral 就是連接的外設(shè)， self.characteristicInfo 就是之前保存的寫入特征；這里最好使用 CBCharacteristicPropertyWrite 特征，并且 type 選擇 CBCharacteristicWriteWithResponse 。當(dāng)寫入數(shù)據(jù)成功后，系統(tǒng)會通過下面這個(gè)方法通知我們：

由于藍(lán)牙設(shè)備每次可寫入的數(shù)據(jù)量是有限制的，因此，我們需要將之前拼接的打印數(shù)據(jù)進(jìn)行拆分，分批發(fā)送給打印機(jī)

這里的 MAX_CHARACTERISTIC_VALUE_SIZE 是個(gè)宏定義，表示每次發(fā)送的數(shù)據(jù)長度，經(jīng)筆者測試，當(dāng) MAX_CHARACTERISTIC_VALUE_SIZE = 20 時(shí)，打印文字是正常速度。但打印圖片的速度非常慢， 應(yīng)該在硬件允許的范圍內(nèi)，每次發(fā)盡量多的數(shù)據(jù)。 不同品牌型號的打印機(jī)，這個(gè)參數(shù)是不同的，筆者的藍(lán)牙打印機(jī)該值最多到140。超出后會出現(xiàn)無法打印問題。 最后筆者將該值定為 MAX_CHARACTERISTIC_VALUE_SIZE = 120 ，測試了公司幾臺打印機(jī)都沒有問題。

另外iOS9以后增加了方法 maximumWriteValueLengthForType: 可以獲取寫入特診的最大寫入數(shù)據(jù)量，但經(jīng)筆者測試，對于部分打印機(jī)（比如我們公司的）是不準(zhǔn)確的，因此，不要太依賴此方法，最好還是自己取一個(gè)合適的值。

注意：每個(gè)打印機(jī)都有一個(gè)緩沖區(qū)，緩沖區(qū)的大小視品牌型號有所不同。打印機(jī)的打印速度有限，如果我們瞬間發(fā)送大量的數(shù)據(jù)給打印機(jī)，會造成打印機(jī)緩沖區(qū)滿。緩沖區(qū)滿后，如繼續(xù)寫入，可能會出現(xiàn)數(shù)據(jù)丟失，打印亂碼。

這里使用 CocoaAsyncSocket 開源框架，與打印機(jī)進(jìn)行 Socket 連接。 CocoaAsyncSocket 中主要包含兩個(gè)類:

這里我們只用到 GCDAsyncSocket ，因此只需要將 GCDAsyncSocket.h 和 GCDAsyncSocket.m 兩個(gè)文件導(dǎo)入項(xiàng)目。

注意：手機(jī)和打印機(jī)必須在同一局域網(wǎng)下，設(shè)置到打印機(jī)的host和port。

連接成功后會通過代理回調(diào)

Timeout為負(fù)，表示不設(shè)置超時(shí)時(shí)間。這里的data就是 上一篇 中拼接的打印數(shù)據(jù)。

寫入完成后回調(diào)

斷開連接有以下幾種方法

連接斷開后回調(diào)

讀取到數(shù)據(jù)會回調(diào)

網(wǎng)口打印機(jī)一般都支持狀態(tài)查詢，查詢指令如下：

可以通過 上一篇 介紹指令拼接方法，查詢打印機(jī)的狀態(tài)。

本篇只是簡單介紹了，通過藍(lán)牙和Socket連接打印機(jī)的方法。雖然可以初步完成連接和打印，但是，在真正的項(xiàng)目中使用還是遠(yuǎn)遠(yuǎn)不夠的。這里還有很多情況需要考慮，比如連接斷開、打印機(jī)異常、打印機(jī)緩沖區(qū)滿、打印機(jī)缺紙等。我們可以針對自身的業(yè)務(wù)情況，進(jìn)行相應(yīng)的處理。

Core Bluetooth Programming Guide

Getting the pixel data from a CGImage object

Core Bluetooth Programming Guide

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

iOS 藍(lán)牙開發(fā)（二）

iOS 藍(lán)牙開發(fā)（三）

iOS 藍(lán)牙開發(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即可開始掃描， 具體方法 [self.centralManager scanForPeripheralsWithServices:nil options:nil] 當(dāng)調(diào)用 scanForPeripheralsWithServices：options: 函數(shù)時(shí)就會實(shí)時(shí)調(diào)用其代理方法 - (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary *)advertisementData RSSI:(NSNumber *)RSSI

peripheral 是外設(shè)類 advertisementData 是廣播的值，一般攜帶設(shè)備名， serviceUUID 等信息。 RSSI 絕對值越大，表示信號越差，設(shè)備離的越遠(yuǎn)。如果想裝換成百分比強(qiáng)度， （RSSI+100）/1001 （這是一個(gè)約數(shù)，藍(lán)牙信號值并不一定是-100 - 0的值）

藍(lán)牙的連接是當(dāng)中心設(shè)備掃描到可用外設(shè)后， 利用函數(shù) [self.centralManager connectPeripheral:peripheral options:nil]; 進(jìn)行鏈接， 當(dāng)函數(shù)被調(diào)用后， 就會回調(diào)其對應(yīng)的代理函數(shù)。

本篇筆記主要是記錄如何初始化藍(lán)牙的 CBCentralManager 的中心管理類，并記錄如何實(shí)現(xiàn)掃描周邊外設(shè)、如何鏈接、獲取藍(lán)牙當(dāng)前狀態(tài)。

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)是低功耗，普及率高?，F(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版本對傳輸速率做了進(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的場景。

2.1.2 廣播和連接:

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

2.1.3?連接后的操作:

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

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

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對應(yīng)的是長連接，建立indecate后，peripheral可以隨時(shí)往central發(fā)送數(shù)據(jù)。

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

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

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

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

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

6.ota存在的問題。

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

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

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

8.連接失敗處理。

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

9.后臺運(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è)被連接后就不會發(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在連接成功一次后會自動(dòng)綁定。 android在處理createBond時(shí)，常常會應(yīng)為不同手機(jī)平臺，不同設(shè)備，會產(chǎn)生兼容性的問題，這點(diǎn)需要注意。

13.定向掃描。

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

14.如何獲取mac地址。

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

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

總結(jié)一下藍(lán)牙開發(fā)相關(guān)的知識點(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)用場景和應(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)識換成了由mac封裝加密后的UUID，需要注意的是不同的手機(jī)獲取同一個(gè)外設(shè)的UUID是不同的，所以在不同手機(jī)之間UUID不是唯一的，但在本機(jī)上可以作為唯一標(biāo)識(特殊情況手機(jī)刷機(jī)后也會改變UUID)。

如何獲取Mac地址

一般使用場景是根據(jù)Mac地址區(qū)分某個(gè)外設(shè)

注意點(diǎn)：

寫入數(shù)據(jù)時(shí)可能會遇到需要分包發(fā)送的情況，我們可以通過下面的API或許當(dā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è)備測的設(shè)置；

當(dāng)我們單次發(fā)送的數(shù)據(jù)字節(jié)長度大于 maxLength 時(shí)，我們就需要采用分包的方式來發(fā)送數(shù)據(jù)了,

分包發(fā)送的邏輯類似于下面

這邊延時(shí)主要是設(shè)備側(cè)的接收模塊接收數(shù)據(jù)以及處理能力有限

外圍設(shè)備測和中心設(shè)備(大部分情況下是手機(jī))保持藍(lán)牙連接的狀態(tài)下，如果長時(shí)間不產(chǎn)生交互，藍(lán)牙就會斷開，所以為了保持兩者持續(xù)的連接狀態(tài)，需要做?；钐幚?，也就是需要持續(xù)的發(fā)送心跳包(watchdog)。相應(yīng)的處理是使用一個(gè)定時(shí)器定時(shí)向設(shè)備側(cè)發(fā)送符合設(shè)備協(xié)議格式的心跳包。

斷開連接很簡單，只需要調(diào)用 [self.centralManager cancelPeripheralConnection:peripheral] 傳入需要斷開連接的設(shè)備對象就行了。斷開連接時(shí)會自動(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)用斷開連接方法一定會斷開

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

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

iOS7 開始，Apple加入了Beacon圍欄檢測的API, ( iBeacon-維基百科 ), 其工作方式是，配備有低功耗藍(lán)牙（BLE）通信功能的設(shè)備使用 BLE 技術(shù)向周圍發(fā)送自己特有的 ID，接收到該 ID 的應(yīng)用軟件會根據(jù)該 ID 采取一些行動(dòng)。比如，在店鋪里設(shè)置 iBeacon 通信模塊的話，便可讓 iPhone 和 iPad 上運(yùn)行一資訊告知服務(wù)器，或者由服務(wù)器向顧客發(fā)送折扣券及進(jìn)店積分, 或者公司的手機(jī)打卡，只要手機(jī)靠近打卡器一定范圍，手機(jī)測就向打開器發(fā)送打卡信息，從而自動(dòng)打卡。這種場景還有很多。 其中一個(gè)最重要的功能就是App的喚醒功能(殺死后也能喚醒)

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

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

蘋果核 - iOS端近場圍欄檢測（一） ——iBeacon

iBeacon技術(shù)初探

iOS 藍(lán)牙開發(fā)（三）

iOS 藍(lán)牙開發(fā)（一）

iOS 藍(lán)牙開發(fā)（二）

iOS 藍(lán)牙開發(fā)（四）

前面記錄了藍(lán)牙如何進(jìn)行掃描、鏈接、以及獲取外設(shè)的服務(wù)和特征，本篇筆記我將記錄如何實(shí)現(xiàn) 與外設(shè)做數(shù)據(jù)交互(explore and interact) 。

構(gòu)建方法流程：鏈接成功-獲取指定的服務(wù)與特征-訂閱指定的特征值-通過具有寫權(quán)限的特征值來寫數(shù)據(jù)-最后在函數(shù) didUpdateValueForCharacteristic 中獲取藍(lán)牙的反饋信息；

總結(jié)：

本篇筆記大概就是在接收到服務(wù)和特征后對數(shù)據(jù)進(jìn)行寫入的操作的過程，筆記中的重點(diǎn)在于要熟悉構(gòu)建特征和服務(wù)的方法流程。熟悉流程，我們就能清楚知道當(dāng)在寫入數(shù)據(jù)時(shí)，系統(tǒng)藍(lán)牙會在函數(shù) didUpdateValueForCharacteristic 方法中給我們反饋寫入是否成功的反饋信息。

當(dāng)前名稱：ios藍(lán)牙外設(shè)開發(fā),ios不支持藍(lán)牙外設(shè)
標(biāo)題路徑：http://www.rwnh.cn/article8/dssogip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、定制網(wǎng)站、、網(wǎng)站設(shè)計(jì)公司、品牌網(wǎng)站設(shè)計(jì)、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)