【问题标题】:Core Bluetooth and backgrounding: Detection of a device and triggering an action, even after being days in background mode?核心蓝牙和后台:检测设备并触发操作,即使在后台模式下几天?
【发布时间】:2013-02-10 08:33:28
【问题描述】:

我编写了一个应用程序,它需要在某个低功耗蓝牙设备进入范围内时获得通知。如果 BLE 设备被注意到,我的应用程序只会存储一个时间戳。

正如 WWDC 2012 Core Bluetooth 视频中所述,在使用 Core Bluetooth 时,应用程序有两种可能在后台模式下运行:

事件背景

事件后台可能是大多数应用程序 将在与低功耗蓝牙设备交互时使用。这 模式不允许与附件直接通信时 该应用程序在后台,但确实提供了来自的通知 附件想要与应用程序通信时。 iOS 将 当您的应用程序在 背景并将继续监视通知。当。。。的时候 连接的 BTLE 配件有可用通知,iOS 会通知 配件想要与您的应用程序对话的用户,允许 用户加载您的应用程序并与附件交互。尽可能多 设备需要节省电力,只提供信息 确定性时间将大大提高电池寿命 配件和 iPhone 4S。

  • 此模式不需要 info.plist 条目。

会话后台

有时应用程序必须与之交互 一个附件,即使它在后台运行。考虑一个 运行需要实时监测心率的应用程序。有一个 清除此模型的 START 和 STOP。用户在 应用程序。当跑步处于活动状态时,应用程序会读取心率信息 直到运行完成或停止。会话后台也 允许在应用程序时扫描和连接到 BTLE 配件 在后台。一个 scanForPeripheralsWithServices 或 connectPeripheral 调用将继续,即使应用程序在 背景。 CoreBluetooth 将继续监控特定的 与您的应用正在寻找的服务相匹配的外围设备或外围设备 找到或连接时调用您的应用程序委托。铭记, 每次 BTLE 外设或 iPhone 4S 使用其收音机时, 耗尽各个设备的可用功率。应用开发者 使用基于会话的后台必须注意电源使用情况。

  • 会话后台需要在您的 Apps info.plist 中进入 UIBackgroundModes、bluetooth-central 的后台模式。

到目前为止,我的会话背景(使用相应的 info.plist 条目)。该应用程序要求 iOS 检索所有已知设备,然后将连接命令提供给我正在寻找的设备。即使在我的应用程序后台运行几分钟后,连接回调也会出现。

但是:应用程序在 - 比方说 - 一小时后暂停。这意味着下次用户启动我的应用时,它无法判断是否有人目击了感兴趣的 BLE 设备。

所以我的问题是:当某个 BLE 设备进入范围时,我的应用是否可以在没有用户交互的情况下获得通知,即使在发送到后台几天后,我也可以存储我的时间戳?

【问题讨论】:

    标签: iphone ios core-bluetooth bluetooth-lowenergy


    【解决方案1】:

    不,iOS 不保证您的应用在后台保持活跃。文档说:

    但是,在应用程序在后台运行(未挂起)并且系统出于某种原因需要终止它的情况下,可能会调用此方法。

    applicationWillTerminate 的文档)

    【讨论】:

    • 也就是说,在后台使用数天后,您的应用几乎没有机会保持活动状态。
    • 这个答案不正确。在 App Store 中查看应用程序“Dark Sky”。这是一个基于位置的天气应用程序。它已经在我的手机后台运行了几个月,并在下雨时不断通知我。
    • 该应用程序可能使用了推送通知。为此,应用程序不必在后台运行。
    • 请注意,iOS7 将引入新功能来克服这个问题。不过这会很难处理。
    • @ChristophWimberger 我怀疑您对 Dropbox 使用位置服务的建议 1) 它应该征求用户使用位置服务的许可,但我不知道它曾经这样做过。 2) 我认为以这种方式使用定位服务违反了 App Store 政策。 -- 能否提供信息来源的链接?
    【解决方案2】:

    从 iOS 7 开始,您的用例现在很容易支持。在 iOS 7 之前,您的应用程序可以注册有关该外围设备的通知,并且当系统有通知要传递时,它会在后台被唤醒。但是,如果您的应用程序在后台运行或重新启动时系统受到内存压力,则不会重新启动它。 iOS 7 为CBCentralManagerCBPeripheralManager 添加了状态恢复功能,因此现在操作系统会以有限的容量重新启动您的应用程序,即使它由于上述任何一种情况而没有运行。请参阅CoreBluetooth guide 了解更多信息。

    简而言之,对于您的用例,您可以执行以下操作:

    • 继续支持bluetooth-central作为后台执行模式。
    • 选择加入状态保存和恢复,如“添加对状态保存和恢复的支持”下的 here 所述。

    【讨论】:

    • 嗨@cbowns 我在这里有一个问题...我添加了对状态保存和恢复的支持但是由于我无法测试应用程序何时自行终止并且系统重新启动应用程序..我正在做的是杀死我的应用程序,然后当我再次启动应用程序时,我得到的 BluetoothCentralKey 为零。如果系统自行重新启动应用程序,我是否会得到我的密钥数组??跨度>
    • @sheetal 嗯。我自己还没有实现它,所以我不知道如何精确地测试它。我在 Apple 论坛和bluetooth-dev 列表上读到的所有内容都表明它很难测试。
    • @sheetal 如果您要杀死应用程序来测试事物,请注意重要的事情:devforums.apple.com/message/908637#908637 从 iOS 7.0 开始,在多任务 UI 中退出的任何应用程序都是 not 由操作系统出于任何原因重新启动,而不是用户采取操作打开应用程序(即选择主屏幕上的图标或选择推送通知)。 (devforums.apple.com/message/921969#921969 是另一种表达方式。我仍在寻找我在哪里阅读了 Apple 某人描述的这种行为。)
    • @sheetal 找到了! devforums.apple.com/message/886796#886796 来自保罗·马科斯。
    • @cbowns 非常感谢...我怀疑当系统杀死我的应用程序并再次重新启动我的应用程序时,我肯定会得到 BluetoothCentralKey 数组?你能帮我解决我如何让苹果杀死我的应用程序而不需要我明确地杀死它吗??
    【解决方案3】:

    使用IOS7 BLE状态保存与恢复

    如果您的应用由于内存压力而被 IOS 终止(这就是您的应用在几天后无法运行的原因),它就无法再处理蓝牙代理了。在这种情况下,如果您使用了 State Preservation & Restoration,您的应用程序可以重新启动到后台再次运行,同样只有 10 秒。 10s 后,它将进入暂停状态。 只有在这种情况下,才能触发CBCentralManager的willRestoreState。

    祝你好运。

    【讨论】:

    • 你有同样的演示吗?
    猜你喜欢
    • 2016-09-14
    • 2017-04-07
    • 2015-01-26
    • 2014-07-15
    • 1970-01-01
    • 1970-01-01
    • 2017-11-15
    • 1970-01-01
    • 2020-06-22
    相关资源
    最近更新 更多