iOS - Bluetooth 蓝牙介绍(下)

回去查看 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 数据库是一个树形结构。

    iOS - Bluetooth 蓝牙介绍(下)_第1张图片
    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 方法即可。
  • 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


你可能感兴趣的:(iOS - Bluetooth 蓝牙介绍(下))