iOS BLE 開發小記[6] 設置本地設備爲 Peripheral 的最佳實踐

歡迎訪問個人博客 muhlenXi，該文章出自個人博客，歡迎轉載，轉載請註明來源: muhlenxi.com/2017/05/07/…*

導語：

在這篇文章中，主要是將你的本地設備設置爲一個廣播數據的 Peripheral 的最佳實踐，以及實際開發過程當中應該注意的事項。

正如許多 Central 端的處理同樣，CoreBluetooth 框架容許你控制 Peripheral 各方面的實現。這一篇將會給你提供一些準則和以負責的方式給你提供一些使用的最佳實踐。

留意廣播的數據

廣播 Peripheral 的數據是實現設備本地設備爲 Peripheral 的重要部分。接下來的小節將會幫助你以一些合理的方式來廣播數據。

遵照廣播數據長度的限制

廣播 Peripheral 的數據是經過調用 CBPeripheralManager 類的 startAdvertising: 方法時傳入廣播數據的字典來完成的。當你建立一個廣播數據字典時，須要注意你能廣播數據的內容和長度限制。

儘管一般的廣播數據包能夠各類各樣 Peripheral 設備的信息。也許你僅僅想廣播設備的 Local Name 和你想要廣播的服務的 UUID，也就是說，當你建立廣播數據字典的時候，你僅僅可以指定如下兩種 Key：CBAdvertisementDataLocalNameKey 和 CBAdvertisementDataServiceUUIDsKey,若是你指定其餘的 Key，你將會收到錯誤提醒。

對廣播數據的空間大小也有限制。當你的 APP 在前臺運行狀態時，你能夠有 28 字節的空間用來初始化廣播數據字典，該字典包含兩個支持的 key。若是空間用盡，最爲搜索響應將會額外增長 10 個字節的空間僅僅用於 Local name。任何服務的 UUID 不容許加入到這個專用的 「overflow」 空間。當用戶設備顯示搜索的時候才能夠發現這個專用空間的內容。當你的 APP 在後臺運行狀態時，則不會廣播 Local name，而且全部服務的 UUID 將會被放到這個特別空間裏。

注意：這些空間不包含每一個新數據類型的 2 個字節的頭部信息，廣播數據和響應數據的正確格式在 Bluetooth 4。0 規範，第3卷，C部分，11章節有定義。

爲了在使空間大小在這些約束以內，僅容許廣播主要的 Service UUID。

僅僅廣播你須要的數據

由於廣播數據須要用到設備的 Radio ，會影響電池續航時間，所以當你想要別的設備鏈接你時，再廣播數據。鏈接後，這些設備能夠直接與 Peripheral 的數據進行交互，不須要其餘廣播數據包。所以，想要促進 BLE 的處理，應中止廣播來最小化 Radio 的使用，進而增長 APP 的性能和保留設備的電量。經過調用 CBPeripheralManager 類的 stopAdvertising 方法便可。

[myPeripheralManager stopAdvertising];
複製代碼

讓用戶來決定何時來廣播

知道何時來廣播一般用戶比較清楚。舉個例子，當你知道附近沒有任何 BLE 設備時，在你的設備上 用 APP 廣播服務是沒有意義的。由於你的 APP 常常感知不到什麼設備在附近，應在 APP 中提供一個 UI 界面來讓用戶選擇什麼時候廣播。

配置你的 Characteristic

當你建立一個 mutable Characteristic，而後你設置它的屬性，值，權限等。這些設定決定着 Central 如何鏈接和如何與 Characteristic 的值交互。雖然你可能基於你的 APP 的不一樣須要來配置 不一樣的Characteristic 屬性、值、權限。當你須要執行如下的兩種任務時，下面的小節將會提供一些指導：

• 容許 Central 鏈接來訂閱 Characteristic
• 保護 Characteristic 的敏感信息不被未配對的 Central 訪問

配置你的 Characteristic 支持通知

在以前文章的描述中，咱們知道對於常常改變值的 Characteristic，建議 Central 訂閱該 Characteristic。 只要可能，應容許鏈接的 Central 來訂閱你的 Characteristic 的值。

當你建立一個 mutable Characteristic 時，經過設置 Characteristic 的 properties 屬性爲 CBCharacteristicPropertyNotify 來支持訂閱。就像這樣：

myCharacteristic = [[CBMutableCharacteristic alloc]
        initWithType:myCharacteristicUUID
        properties:CBCharacteristicPropertyRead | CBCharacteristicPropertyNotify
        value:nil permissions:CBAttributePermissionsReadable];
複製代碼

示例中，Characteristic 的值是可讀的，它能夠被鏈接的 Central 訂閱。

須要一個配對的鏈接來訪問敏感數據

根據使用狀況，你可能想要發佈一個服務，這個服務的一個或多個 Characteristic 的值是敏感的。舉個例子，你可能想要發佈一個 社交服務描述 服務，這個服務可能包含一些表明用戶描述信息的 Characteristic，好比姓，名字，和 email 地址等。頗有可能，你想要容許受信任的設備來獲取用戶的 email 地址。

你能夠確保只有受信任的設備才能訪問敏感 Characteristic 的值，你能夠經過恰當的設置 Characteristic 的屬性和權限來達到目的。繼續上面提到的例子，只容許受信任的設備來得到用戶的 email 地址，恰當的設置 Characteristic 的 properties 和 permissions，像這樣：

emailCharacteristic = [[CBMutableCharacteristic alloc]
        initWithType:emailCharacteristicUUID
        properties:CBCharacteristicPropertyRead
        | CBCharacteristicPropertyNotifyEncryptionRequired
        value:nil permissions:CBAttributePermissionsReadEncryptionRequired];
複製代碼

示例代碼中，Characteristic 配置的只容許受信任的設備來讀和訂閱它的值。當鏈接後，Remote Central 嘗試讀取或訂閱這個 Characteristic 的值時， CoreBluetooth 將嘗試將 Central 和本地設備配對來建立安全鏈接。

舉個例子，若是 Central 和 Peripheral 都是 iOS 設備，雙方都會彈出一個表示有設備想要配對的彈框。你須要將 Central 設備上彈框的配對碼填入到 Peripheral 設備上彈框的文本框裏來完成配對處理。

完成配對後，Peripheral 會認爲該 Central 是個受信任的設備，並容許 Central 來訪問它的加密Characteristic 的值。

參考文獻

一、Best Practices for Setting Up Your Local Device as a Peripheral

結束語

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