Tom*_*yer 6 ios core-bluetooth bluetooth-lowenergy swift
我有一个BLE设备(外围设备)和iOS应用程序,它们使用CoreBluetooth.framework(连接,断开连接,订阅,通知服务)相互通信.以下是几个场景:
这也显示了用户的App Force Quit,应用程序不会重新启动或使用状态保存和恢复活动.
"如果您需要在应用程序未运行时执行代码,则根据您要执行的操作,有几个选项可供您使用. - 后台提取将让您的应用程序在预定的时间间隔内在后台运行约30秒这样做的目的是获取数据并为应用程序下次运行时准备用户界面. - 推送通知让您的应用程序从服务器获取新数据.如果需要,您可以在设备上显示消息,但这不是必需的- 静音推送通知让您跳过该部分. - 本地通知让您向用户显示警报,以及您想要的任何媒体附件以及供用户选择的一些选项.如果他们选择这些选项,那么您的应用可以启动在前台或后台处理它们."
我尝试使用Background Fetch,但是当应用程序终止时它也没有醒来.
我实现的唯一目标是"当应用程序被用户终止或终止时,每当连接BLE设备时,应该在前台/后台调用应用程序,以便我执行一些操作,例如从BLE设备获取数据并保存它"
如何在不使用推送通知或静默通知的情况下实现此目的 如果CoreBluetooth框架中的任何内容在终止后应用程序唤醒,请告诉我?
简短的回答是,你不能。
该文档明确指出,当您的应用程序被用户明确终止时,它不会重新启动。
对于无声通知也是如此 - 如果用户强制终止您的应用程序(或者设备电池状态低于 20%,顺便说一句),这些通知不会唤醒您的应用程序。
您对此的选择是有限的,可能包括建议用户不要强制终止您的应用程序,或使用基于位置的区域检测来重新启动您的应用程序。
您链接的教程之一显示了一个 iBeacon 示例,用于检测进入和超出 iBeacons 的范围,并且与后台权限结合使用时可以重新启动您的应用程序,但同样 - 这并不是您明确要求的,而是不是您所描述问题的真正解决方案。
苹果的逻辑很简单——如果用户杀死了你的应用程序,用户就不希望它再次运行,这是有道理的。
问题是,许多用户认为杀死应用程序是提高设备响应速度的标准方法,对此存在很大的争论(更糟糕的是让操作系统冷启动应用程序还是允许应用程序在后台通过无声通知做有趣的事情)等等)我不会参与这场辩论,事情就是这样。