回去查看 iOS - Bluetooth 蓝牙介绍（上）
5、外设模式的使用
5.1 App 作为外设被连接的实现
-
1、启动一个 Peripheral 管理对象
- 打开 peripheralManager，设置 peripheralManager 的委托。
-
2、配置本地 Peripheral，设置服务、特性、描述、权限等等
创建 characteristics，characteristics 的 description，创建 service，把 characteristics 添加到 service 中，再把 service 添加到 peripheralManager 中。
当 peripheral 成功打开后，才可以配置 service 和 characteristics。这里创建的 service 和 characteristics 对象是 CBMutableCharacteristic 和 CBMutableService。他们的区别就像 NSArray 和 NSMutableArray 区别类似。我们先创建 characteristics 和 description，description 是 characteristics 的描述，描述分很多种，常用的就是 CBUUIDCharacteristicUserDescriptionString。
-
3、开启广播 advertising
- 添加发送广播后悔调用代理的 peripheralManagerDidStartAdvertising:error: 方法。
4、设置处理订阅、取消订阅、读 characteristic、写 characteristic 的委托方法
5.2 作为 Peripheral 时的请求响应
5.2.1 初始化 CBPeripheralManager
将设备作为 peripheral，第一步就是初始化 CBPeripheralManager 对象。可以通过调用 CBPeripheralManager 的
initWithDelegate:queue:options:方法来进行初始化：上面的几个参数中，将 self 设为代理来接收相关回调，queue 为 nil 表示在主线程。
当你调用上面这方法后，便会回调
peripheralManagerDidUpdateState:。所以在此之前，你需要先遵循CBPeripheralManagerDelegate。这个代理方法能获取当前 iOS 设备能否作为 peripheral。
5.2.2 配置 service 和 characteristic
-
就像之前讲到的一样，peripheral 数据库是一个树形结构。
Bluetooth24 所以在创建 peripheral 的时候，也要像这种树形结构一样，将 service 和 characteristic 装进去。在此之前，我们需要做的是学会如何标识 service 和 characteristic。
-
1、使用 UUID 来标识 service 和 characteristic
- service 和 characteristic 都通过 128 位的 UUID 来进行标识，Core Bluetooth 将 UUID 封装为了 CBUUID 。关于详细 UUID 的介绍，请参考上面的 4.3.1 CBUUID 讲解。
-
2、为自定义的 service 和 characteristic 创建 UUID
你的 service 或者 characteristic 的 UUID 并没有公共的 UUID，这时你需要创建自己的 UUID。
使用命令行的
uuidgen能很容易的生成 UUID。首先打开终端，为你的每一个 service 和 characteristic 创建 UUID。在终端输入uuidgen然后回车，具体如下：可以通过
UUIDWithString:方法，将 UUID 生成 CBUUID 对象。
-
3、构建 service 和 characteristic 树形结构
在将 UUID 打包为 CBUUID 之后，就可以创建 CBMutableService 和 CBMutableCharacteristic 并把他们组成一个树形结构了。创建 CBMutableCharacteristic 对象可以通过该类的
initWithType:properties:value:permissions:方法：创建 characteristic 的时候，就为他设置了 properties 和 permissions。这两个属性分别定义了 characteristic 的可读写状态和 central 连接后是否能订阅。上面这种初始化方式，代表着 characteristic 可读。更多的选项，可以去看看 CBMutableCharacteristic Class Reference。
如果给 characteristic 设置了 value 参数，那么这个 value 会被缓存，并且 properties 和 permissions 会自动设置为可读。如果想要 characteristic 可写，或者在其生命周期会改变它的值，那需要将 value 设置为 nil。这样的话，就会动态的来处理 value 。
现在已经成功的创建了 characteristic，下一步就是创建一个 service，并将它们构成树形结构。调用 CBMutableService 的
initWithType:primary:方法来初始化 service：第二个参数 primary 设置为 YES 表示该 service 为 primary service（主服务），与 secondary service（次服务）相对。primary service 描述了设备的主要功能，并且能包含其他 service。secondary service 描述的是引用它的那个 service 的相关信息。比如，一个心率监测器，primary service 描述的是当前心率数据，secondary service 描述描述的是当前电量。
创建了 service 之后，就可以包含 characteristic 了：
5.2.3 发布 service 和 characteristic
构建好树形结构之后，接下来便需要将这结构加入设备的数据库。这一操作 Core Bluetooth 已经封装好了，调用 CBPeripheralManager 的
addService:方法即可：当调用以上方法时，便会回调 CBPeripheralDelegate 的
peripheralManager:didAddService:error:回调。当有错误，或者当前 service 不能发布的时候，可以在这个代理中来进行检测：当你发布 service 之后，service 就会缓存下来，并且无法再修改。
5.2.4 广播 service
搞定发布 service 和 characteristic 之后，就可以开始给正在监听的 central 发广播了。可以通过调用 CBPeripheralManager 的
startAdvertising:方法并传入字典作为参数来进行广播：上面的代码中，key 只用到了 CBAdvertisementDataServiceUUIDsKey，对应的 value 是包含需要广播的 service 的 CBUUID 类型数组。除此之外，还有以下 key：
但是只有 CBAdvertisementDataLocalNameKey 和 CBAdvertisementDataServiceUUIDsKey 才是 peripheral Manager 支持的。
当开始广播时，peripheral Manager 会回调
peripheralManagerDidStartAdvertising:error:方法。如果有错或者 service 无法进行广播，则可以在该该方法中检测：因为空间的限制，并且还可能有多个 app 在同时发起广播，所以数据广播基于 best effort（即在接口发生拥塞时，立即丢包，直到业务量减小）。
广播服务在程序挂起时依然可用。
5.2.5 响应 central 的读写操作
在连接到一个或多个 central 之后，peripheral 有可能会收到读写请求。此时，你应该根据请求作出相应的响应，接下来便会提到这方面的处理。
-
1、读取请求
当收到读请求时，会回调
peripheralManager:didReceiveReadRequest:方法。该回调将请求封装为了 CBATTRequest 对象，在该对象中，包含很多可用的属性。其中一种用法是在收到读请求时，可以通过 CBATTRequest 的 characteristic 属性来判断当前被读的 characteristic 是哪一个 characteristic：
匹配上 UUID 之后，接下来需要确保读取数据的 offset（偏移量）不会超过 characteristic 数据的总长度：
假设偏移量验证通过，下面需要截取 characteristic 中的数据，并赋值给
request.value。注意，offset 也要参与计算：读取完成后，记着调用 CBPeripheralManager 的
respondToRequest:withResult:方法，告诉 central 已经读取成功了：如果 UUID 匹配不上，或者是因为其他原因导致读取失败，那么也应该调用
respondToRequest:withResult:方法，并返回失败原因。官方提供了一个失败原因枚举，可能有你需要的。
-
2、写入请求
写入请求和读取请求一样简单。当 central 想要写入一个或多个 characteristic 时，CBPeripheralManager 回调
peripheralManager:didReceiveWriteRequests:。该方法会获得一个 CBATTRequest 数组，包含所有写入请求。当确保一切验证没问题后（与读取操作验证类似：UUID 与 offset），便可以进行写入：成功后，同样去调用
respondToRequest:withResult:。但是和读取操作不同的是，读取只有一个 CBATTRequest，但是写入是一个 CBATTRequest 数组，所以这里直接传入第一个 request 就行：因为收到的是一个请求数组，所以，当他们其中有任何一个不满足条件，那就不必再处理下去了，直接调用
respondToRequest:withResult:方法返回相应的错误。
5.2.6 发送更新数据给订阅了的 central
central 可能会订阅了一个或多个 characteristic，当数据更新时，需要给他们发送通知。下面就来详细介绍下。
当 central 订阅 characteristic 的时候，会回调 CBPeripheralManager 的
peripheralManager:central:didSubscribeToCharacteristic:方法：通过上面这个代理，可以用个数组来保存被订阅的 characteristic，并在它们的数据更新时，调用 CBPeripheralManager 的
updateValue:forCharacteristic:onSubscribedCentrals:方法来告诉 central 有新的数据：这个方法的最后一个参数能指定要通知的 central。如果参数为 nil，则表示想所有订阅了的 central 发送通知。
同时
updateValue:forCharacteristic:onSubscribedCentrals:方法会返回一个 BOOL 标识是否发送成功。如果发送队列任务是满的，则会返回 NO。当有可用的空间时，会回调peripheralManagerIsReadyToUpdateSubscribers:方法。所以你可以在这个回调用调用updateValue:forCharacteristic:onSubscribedCentrals:重新发送数据。发送数据使用到的是通知，当你更新订阅的 central 时，应该调用一次
updateValue:forCharacteristic:onSubscribedCentrals:。因为 characteristic 数据大小的关系，不是所有的更新都能发送成功，这种问题应该由 central 端来处理。调用 CBPeripheral 的
readValueForCharacteristic:方法，来主动获取数据。
5.3 请求响应 - 最佳实践
5.3.1 关于广播的思考
广播是 peripheral 的一个重要操作，接下来会讲到广播的正确姿势。
-
1、注意广播对数据大小的限制
正如前文提到过的那样，广播是通过调用 CBPeripheralManager 的
startAdvertising:方法发起的。当你将要发送的数据打包成字典后，千万要记住数据大小是有限制的。即使广播可以包含 peripheral 的很多信息，但是其实只需要广播 peripheral 的名称和 service 的 UUID 就足够了。也就是构建字典时，填写 CBAdvertisementDataLocalNameKey 和 CBAdvertisementDataServiceUUIDsKey 对应的 value 即可，如果使用其他 key，将会导致错误。
当 app 运行在前台时，有 28 bytes 的空间可用于广播。如果这 28 bytes 用完了，则会在扫描响应时额外分配 10 bytes 的空间，但这空间只能用于被 CBAdvertisementDataLocalNameKey 修饰的 local name（即在
startAdvertising:时传入的数据）。以上提到的空间，均不包含 2 bytes 的报文头。被 CBAdvertisementDataServiceUUIDsKey 修饰的 service 的 UUID 数组数据，均不会添加到特殊的 overflow 区域。并且这些 service 只能被 iOS 设备发现。当程序挂起后，local name 和 UUID 都会被加入到 overflow 区。为了保证在有限的空间中，正确的标识设备和 service UUID，请正确构建广播的数据。
-
2、只广播必要的数据
- 当 peripheral 想要被发现时，它会向外界发送广播，此时会用到设备的无线电（当然还有电池）。一旦连接成功，central 便能直接从 peripheral 中读取数据了，那么此时广播的数据将不再有用。所以，为了减少无线电的使用、提高手机性能、保护设备电池，应该在被连接后，及时关闭广播。停止广播调用 CBPeripheralManager 的
stopAdvertising方法即可。
- 当 peripheral 想要被发现时，它会向外界发送广播，此时会用到设备的无线电（当然还有电池）。一旦连接成功，central 便能直接从 peripheral 中读取数据了，那么此时广播的数据将不再有用。所以，为了减少无线电的使用、提高手机性能、保护设备电池，应该在被连接后，及时关闭广播。停止广播调用 CBPeripheralManager 的
-
3、手动开启广播
- 其实什么时候应该广播，多数情况下，用户比我们更清楚。比如，他们知道周围没有开着的 BLE 设备，那他就不会把 peripheral 的广播打开。所以提供给用户一个手动开启广播的 UI 更为合适。
5.3.2 配置 characteristic
在创建 characteristic 的时候，就为它设定了相应的 properties、value 和 promissions。这些属性决定了 central 如何和 characteristic 通信。properties 和 promissions 可能需要根据 app 的需求来设置，下来就来谈谈如何配置 characteristic：
-
1、让 characteristic 支持通知
之前在 central 的时候提到过，如果要读取经常变化的 characteristic 的数据，更推荐使用订阅。所以，如果可以，最好 characteristic 允许订阅。
如果像下面这样初始化 characteristic 就是允许读和订阅：
-
2、限制只能配对的 central 才能访问敏感信息
有些时候，可能有这样的需求：需要 service 的一个或多个 characteristic 的数据安全性。假如有一个社交媒体的 service，那么它的 characteristic 可能包含了用户的姓名、邮箱等私人信息，所以只让信任的 central 才能访问这些数据是很有必要的。
这可以通过设置相应的 properties 和 promissions 来达到效果：
像上面这样设置，便能只让配对的 central 才能进行订阅。并且在连接过程中，Core Bluetooth 还会自动建立安全连接。
在尝试配对时，两端都会弹出警告框，central 端会提供 code，peripheral 端必须要输入该 code 才能配对成功。成功之后，peripheral 才会信任该 central，并允许读写数据。
6、后台运行蓝牙服务
对于 iOS app 来说，知道现在是运行在前台和后台是至关重要的。因为当程序挂起后，对资源的使用是相当有限的。关于多任务的介绍，可以看 app 开发手册。
默认情况下，Core Bluetooth 是不会在后台运行的（无论是 central 还是 peripheral）。但你也可以配置在 app 收到事件后，从挂起状态唤醒。即使程序不是完全的支持后台模式，也可以要求在有重要事件时接收系统通知。
即使在以上两种情况下（完全允许后台和部分允许后台），程序也有可能不会永远挂起。在前台程序需要更多内存时，被挂起的程序很有可能会被强制退出，那样会断开所有的连接。从 iOS 7 开始，能够先保存状态（无论是 central 还是 peripheral），并在重新打开 app 时还原这些状态。通过这一特性，就可以做长时间操作了。
6.1 运行在前台的 app（Foreground-Only）
除非去申请后台权限，否则 app 都是只在前台运行的，程序在进入后台不久便会切换到挂起状态。挂起后，程序将无法再接收任何蓝牙事件。
对于 central 来说，挂起将无法再进行扫描和搜索 peripheral。对于 peripheral 来说，将无法再发起广播，central 也无法再访问动态变化的 characteristic 数据，访问将返回 error。
根据不同情况，这种机制会影响程序在以下几个方面的运用。你正在读取 peripheral 的数据，结果程序被挂起了（可能是用户切换到了另外一个 app），此时连接会被断开，但是要直到程序重新唤醒时，你才知道被断开了。
-
1、利用连接 Peripheral 时的选项
Foreground-Only app 在挂起的时候，便会加入到系统的一个队列中，当程序重新唤醒时，系统便会通知程序。Core Bluetooth 会在程序中包含 central 时，给用户以提示。用户可根据提示来判断是否要唤醒该 app。
可以利用 central 在连接 peripheral 时的方法
connectPeripheral:options:中的 options 来触发提示：
6.2 Core Bluetooth 后台模式
如果你想让你的 app 能在后台运行蓝牙，那么必须在 info.plist 中打开蓝牙的后台运行模式。当配置之后，收到相关事件便会从后台唤醒。这一机制对定期接收数据的 app 很有用，比如心率监测器。
-
下面会介绍两种后台模式，一种是作为 central 的，一种是作为 peripheral 的，如果 app 两种角色都有，那则需要开启两种模式。配置即是在 info.plist 中添加
UIBackgroundModes key，类型为数组，value 则根据你当前角色来选择：-
bluetooth-central：即 Central。 -
bluetooth-peripheral：即 Peripheral。
-
这个配置在 Xcode 中，也可以在 Capabilities 中进行配置，而不用直接面对 key-value。如果要看到 key-value，可以在 info.plist 中打开查看。
-
1、作为 Central 的后台模式
如果在 info.plist 中配置了 UIBackgroundModes – bluetooth-central，那么系统则允许程序在后台处理蓝牙相关事件。在程序进入后台后，依然能扫描、搜索 peripheral，并且还能进行数据交互。当 CBCentralManagerDelegate 和 CBPeripheralDelegate 的代理方法被调用时，系统将会唤醒程序。此时允许你去处理重要的事件，比如：连接的建立或断开，peripheral 发送了数据，central manager 的状态改变。
-
虽然此时程序能在后台运行，但是对 peripheral 的扫描和在前台时是不一样的。实际情况是这样的：
设置的 CBCentralManagerScanOptionAllowDuplicatesKey 将失效，并将发现的多个 peripheral 广播的事件合并为一个。
如果全部的 app 都在后台搜索 peripheral，那么每次搜索的时间间隔会更大。这会导致搜索到 peripheral 的时间变长。
这些相应的调整会减少无线电使用，并提升续航能力。
-
2、作为 peripheral 的后台模式
作为 peripheral 时，如果需要支持后台模式，则在 info.plist 中配置 UIBackgroundModes – bluetooth-peripheral。配置后，系统会在有读写请求和订阅事件时，唤醒程序。
-
在后台，除了允许处理读写请求和订阅事件外，Core Bluetooth 框架还允许 peripheral 发出广播。同样，广播事件也有前后台区别。在后台发起时是这样的：
- CBAdvertisementDataLocalNameKey 将失效，在广播时，广播数据将不再包含 peripheral 的名字。
- 被 CBAdvertisementDataServiceUUIDsKey 修饰的 UUID 数组将会被放到 overflow 区域中，意味着只能被明确标识了搜索 service UUID 的 iOS 设备找到。
- 如果所有 app 都在后台发起广播，那么发起频率会降低。
6.3 巧妙的使用后台模式
虽然程序支持一个或多个 Core Bluetooth 服务在后台运行，但也不要滥用。因为蓝牙服务会占用 iOS 设备的无线电资源，这也会间接影响到续航能力，所以尽可能少的去使用后台模式。app 会唤醒程序并处理相关事务，完成后又会快速回到挂起状态。
-
无论是 central 还是 peripheral，要支持后台模式都应该遵循以下几点：
- 程序应该提供 UI，让用户决定是否要在后台运行。
- 一旦程序在后台被唤醒，程序只有 10s 的时间来处理相关事务。所以应该在程序再次挂起前处理完事件。后台运行的太耗时的程序会被系统强制关闭进程。
- 处理无关的事件不应该唤醒程序。
和后台运行的更多介绍，可以查看 App Programming Guide for iOS。
6.4 处理常驻后台任务
某些 app 可能需要 Core Bluetooth 常驻后台，比如，一款用 BLE 技术和门锁通信的 app。当用户离开时，自动上锁，回来时，自动开锁（即使程序运行在后台）。当用户离开时，可能已超出蓝牙连接范围，所以没办法给锁通信。此时可以调用 CBCentralManager 的
connectPeripheral:options:方法，因为该方法没有超时设置，所以，在用户返回时，可以重新连接到锁。但是还有这样的情形：用户可能离开家好几天，并且在这期间，程序已经被完全退出了。那么用户再次回家时，就不能自动开锁。对于这类 app 来说，常驻后台操作就显得尤为重要。
-
1、状态保存与恢复
因为状态的保存和恢复 Core Bluetooth 都为我们封装好了，所以我们只需要选择是否需要这个特性即可。系统会保存当前 central manager 或 peripheral manager，并且继续执行蓝牙相关事件（即使程序已经不再运行）。一旦事件执行完毕，系统会在后台重启 app，这时你有机会去存储当前状态，并且处理一些事物。在之前提到的 “门锁” 的例子中，系统会监视连接请求，并在
centralManager:didConnectPeripheral:回调时，重启 app，在用户回家后，连接操作结束。Core Bluetooth 的状态保存与恢复在设备作为 central、peripheral 或者这两种角色时，都可用。在设备作为 central 并添加了状态保存与恢复支持后，如果 app 被强行关闭进程，系统会自动保存 central manager 的状态（如果 app 有多个 central manager，你可以选择哪一个需要系统保存）。
-
对于 CBCentralManager，系统会保存以下信息：
- central 准备连接或已经连接的 peripheral
- central 需要扫描的 service（包括扫描时，配置的 options）
- central 订阅的 characteristic
-
对于 peripheral 来说，情况也差不多。系统对 CBPeripheralManager 的处理方式如下：
- peripheral 在广播的数据
- peripheral 存入的 service 和 characteristic 的树形结构
- 已经被 central 订阅了的 characteristic 的值
当系统在后台重新加载程序后（可能是因为找到了要找的 peripheral），你可以重新实例化 central manager 或 peripheral 并恢复他们的状态。
-
2、添加状态存储和恢复支持
-
状态的存储和恢复功能在 Core Bluetooth 中是可选的，添加支持可以通过以下几个步骤：
- （必须）在初始化 central manager 或 peripheral manager 时，要选择是否需要支持。会在文后的【3、选择支持存储和恢复】中介绍。
- （必须）在系统从后台重新加载程序时，重新初始化 central manager 或 peripheral manager。会在文后的【4、重新初始化 central manager 和 peripheral manager】中介绍。
- （必须）实现恢复状态相关的代理方法。会在文后的【5、实现恢复状态的代理方法】中介绍。
- （可选）更新 central manager 或 peripheral manager 的初始化过程。会在文后的【6、更新 manager 初始化过程】中介绍。
-
-
3、选择支持存储和恢复
如果要支持存储和恢复，则需要在初始化 manager 的时候给一个 restoration identifier。restoration identifier 是 string 类型，并标识了 app 中的 central manager 或 peripheral manager。这个 string 很重要，它将会告诉 Core Bluetooth 需要存储状态，毕竟 Core Bluetooth 恢复有 identifier 的对象。
例如，在 central 端，要想支持该特性，可以在调用 CBCentralManager 的初始化方法时，配置 CBCentralManagerOptionRestoreIdentifierKey：
虽然以上代码没有展示出来，其实在 peripheral manager 中要设置 identifier 也是这样的。只是在初始化时，将 key 改成了 CBPeripheralManagerOptionRestoreIdentifierKey。
因为程序可以有多个 CBCentralManager 和 CBPeripheralManager，所以要确保每个 identifier 都是唯一的。
-
4、重新初始化 central manager 和 peripheral manager
当系统重新在后台加载程序时，首先需要做的即根据存储的 identifier，重新初始化 central manager 或 peripheral manager。如果你只有一个 manager，并且 manager 存在于 app 生命周期中，那这个步骤就不需要做什么了。
如果 app 中包含多个 manager，或者 manager 不是在整个 app 生命周期中都存在的，那 app 就必须要区分你要重新初始化哪个 manager 了。你可以通过从 app delegate 中的
application:didFinishLaunchingWithOptions:中取出 key（UIApplicationLaunchOptionsBluetoothCentralsKey 或 UIApplicationLaunchOptionsBluetoothPeripheralsKey）中的 value（数组类型）来得到程序退出之前存储的 manager identifier 列表：拿到这个列表后，就可以通过循环来重新初始化所有的 manager 了。
-
5、实现恢复状态的代理方法
在重新初始化 manager 之后，接下来需要同步 Core Bluetooth 存储的他们的状态。要想弄清楚在程序被退出时都在做些什么，就需要正确的实现代理方法。对于 central manager 来说，需要实现
centralManager:willRestoreState:；对于 peripheral manager 来说，需要实现peripheralManager:willRestoreState:。注意：如果选择存储和恢复状态，当系统在后台重新加载程序时，首先调用的方法是
centralManager:willRestoreState:或peripheralManager:willRestoreState:。如果没有选择存储的恢复状态（或者唤醒时没有什么内容需要恢复），那么首先调用的方法是centralManagerDidUpdateState:或peripheralManagerDidUpdateState:。无论是以上哪种代理方法，最后一个参数都是一个包含程序退出前状态的字典。字典中，可用的 key ，central 端有：
peripheral 端有：
要恢复 central manager 的状态，可以用
centralManager:willRestoreState:返回字典中的 key 来得到。假如说 central manager 有想要或者已经连接的 peripheral，那么可以通过 CBCentralManagerRestoredStatePeripheralsKey 对应得到的 peripheral（CBPeripheral 对象）数组来得到。具体要对拿到的 peripheral 数组做什么就要根据需求来了。如果这是个 central manager 搜索到的 peripheral 数组，那就可以存储这个数组的引用，并且开始建立连接了（注意给这些 peripheral 设置代理，否则连接后不会走 peripheral 的代理方法）。
恢复 peripheral manager 的状态和 central manager 的方式类似，就只是把代理方法换成了
peripheralManager:willRestoreState:，并且使用对应的 key 即可。
-
6、更新 manager 初始化过程
在实现了全部的必须步骤后，你可能想要更新 manager 的初始化过程。虽然这是个可选的操作，但是它对确保各种操作能正常进行尤为重要。假如，你的应用在 central 和 peripheral 做数据交互时，被强制退出了。即使 app 最后恢复状态时，找到了这个 peripheral，那你也不知道 central 和这个 peripheral 当时的具体状态。但其实我们在恢复时，是想恢复到程序被强制退出前的那一步。
这个需求，可以在代理方法
centralManagerDidUpdateState:中，通过发现恢复的 peripheral 是否之前已经成功连接来实现：上面的代码描述了，当系统在完成搜索 service 之后才退出的程序，可以通过调用
discoverServices:方法来恢复 peripheral 的数据。如果 app 成功搜索到 service，你可以是否能搜索到需要的 characteristic（或者已经订阅过）。通过更新初始化过程，可以确保在正确的时间点，调用正确的方法。
7、第三方框架
-
iOS 蓝牙开发中常用的第三方框架
BabyBluetooth
LGBluetooth
BeaconOSX
BluetoothSerial