iOS BLE 開發小記[6] 設定本地裝置為 Peripheral 的最佳實踐

muhlenXi發表於2019-04-22
iOS

歡迎訪問我的部落格 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 的值。

參考文獻

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

結束語

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

相關文章