歡迎訪問我的博客 muhlenXi，該文章出自我的博客，歡迎轉載，轉載請注明來源: http://muhlenxi.com/2017/05/07/iOS-Bluetooth-Low-Energy-Develop-Chapter6*
導語：
在這篇文章中，主要是將你的本地設備設置為一個廣播數據的 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
結束語
歡迎在本文下面留言一起交流心得...
