Core Bluetooth Programming Guide - Best Practices for Setting Up Your Local Device as a Peripheral 第6章 中文翻译

将你的本地设备设为 Peripheral 的最佳实践

如同许多 central 端的事务一样，Core Bluetooth 框架给予你在 peripheral 端大多数领域的控制力。本章提供了基本原则和最佳实践，帮助你获取驾驭这一层的能力，且以负责任的方式。

关于广播的考虑

尊重广播数据的限制

要广播你的 peripheral 上的数据，通过传递一个广播数据的 dictionary 给 CBPeripheralManager 类的 startAdvertising: 方法，在 Advertising Your Services 章节有描述。当你创建一个准备广播的 dictionary，请记得，你能够广播什么数据，以及能广播多少数据，都是有限制的。
尽管总的来说，广播包可以包含多种多样关于 peripheral 的信息，但实际上，你只能广播你的设备的本地名称，以及你想广播的 services 的 UUID。即是说，当你创建你的广播 dictionary 时，你仅仅可以指定以下两种 key：CBAdvertisementDataLocalNameKey 和 CBAdvertisementDataServiceUUIDsKey。指定任何其它值都会报错。
与此同时，你在广播数据时能使用多少空间同样有限制。当你的应用在前台时，它的初始广播数据至多能使用至多 28bytes 空间，包含上面两种 key 的任意组合。如果这个空间用完了，在响应扫描时可以有额外 10bytes 空间，只能用于本地名称。任何 service UUID 若无法放进被分配的区域，将被添加到一个特殊的“溢出（overflow）”区域，它们仅能被扫描时显式指定了它们的 iOS 设备发现。当你的应用在后台时，本地名称不会被广播，并且所有 service UUID 被置于溢出区。

注意：这里所说的大小不包含 2bytes 的头部信息，那是每个新数据类型格式定义在 Bluetooth 4.0 specification, Volume 3, Part C, Section 11。
广播 peripheral 数据是设置你的本地设备实现 peripheral 角色的重要部分。下面的章节帮助你恰当的做好这件事。
为了遵守这些空间限制，在广播中请限制你的 service 的 UUID 为那些能标识你的主要服务的。

仅当你需要的时候才广播数据

因为广播 peripheral 数据要使用你本地设备的无线电（因此也需要耗费电量），仅在你想要其它设备连接你的时候才发广播。一旦连接建立，这些设备可以直接探索或互动 peripheral 上的数据，不再需要任何广播包。因此，为了最小化无线电使用、提高应用性能、且保留更多电量，请在不需要时停止广播。要在本地 peripheral 上停止广播，只需简单的调用 CBPeripheralManager类的 stopAdvertising 方法，如下：

    [myPeripheralManager stopAdvertising];

让用户决定何时广播

有时候只有用户知道何时该广播。例如，当你知道周围没有任何 BLE 设备时让你的应用在你的设备上发广播是毫无意义的。由于你的应用通常是不知道周边是否有其它设备，在你的应用的 UI 中提供一种方法让用户决定何时广播。

配置你的特性

当你创建一个可变的 characteristic，你需要设置它的属性、值、和权限。这些设置决定了已连接的 central 如何访问 characteristic 的值并与之交互。下文为你执行以下两个任务提供一些指导，尽管基于你的应用的需求，你可能决定为你的 characteristic 设置不同的属性和权限：
允许已连接的 central 订阅你的 charateristic
保护敏感的 characteristic 值，不被未配对的 central 读取。

配置你的特性以支持通知

如在 Subscribe to Characteristic Values That Change Often 中描述的那样，对于变化频繁的（远程 service 的） characteristic 值，推荐 central 订阅它。可能的情况，鼓励这种行为，允许已连接的 central 订阅你的 characteritic 的值。
当你创建一个可变的 characteristic，通过设置 characteristic 属性中的 CBCharacteristicPropertyNotify 常量来支持订阅，如下：

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

在本例中，这个 characteristic 值是可读的，并且可被已连接的 central 订阅。

访问敏感数据需要一个已配对的连接

取决于你的用例，你可能需要提供一个或多个 characteristic，其值需要是安全的。例如，设想一下你需要提供一个社交媒体个人档案的 service。这个 service 可能包含了一些 characteristic，其值代表会员的个人档案，比如姓、名以及 email 地址。基本上你只想允许被信任的设备取得会员的 email 地址。
你可以通过设置 characteristic 的属性和权限来保证只有被信任的设备才能访问敏感的 characteristic 值。继续上面的例子，只允许被信任的设备 获取用户的 email 地址，设置 characteristic 的属性和权限，如下：

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

在本例中，这个 characteristic 被设置为只有被信任的设备才能读取或订阅它的值。当一个已连接的远程 central 尝试读取或订阅这个 charateristic 的值，Core Bluetooth 会尝试配对本地 peripheral 和 central，来创建一个安全连接。
例如，如果 central 和 peripheral 都是 iOS 设备，两边同时收到一个弹框，提示说对方设备想要配对。在 central 设备上的提示还包含一个代码，你必须将这个代码输出到 peripheral 设备弹框的文本框中以完成配对过程。

在配对过程结束后，peripheral 设备会认为 central 设备是一个被信任的设备，并允许它访问加密的 characteristic 值。