为什么iOS小部件即使在前台有包含应用程序的情况下也不能及时刷新

最后,我们获得了流畅的用户体验。乍一看,这个解决方案很奇怪,但与我们早期的实现相比,它的工作方式很有魅力。

你所需要做的就是打电话 WidgetCenter.shared.reloadTimelines 或 WidgetCenter.shared.reloadAllTimelines 在应用程序尽快进入前台之后。

为什么?作为医生 Managing Your App's Life Cycle 状态:

前台应用程序吸引了用户的注意力,因此它优先于系统资源,包括CPU

文档很清楚,但时间也很重要,我们测试了一些现象,但在任何官方文档中都找不到(在发布时运行应用程序,而不是连接xcode的调试模式):

• 始终在前台启动应用程序,通过调用通知小部件刷新视图 小工具中心共享加载时间线 或 小工具中心共享加载所有时间线 随着时间的推移,延迟会不断增加
• 打电话时 小工具中心共享加载时间线 或 小工具中心共享加载所有时间线 应用程序尽快启动后,小部件视图将立即刷新(几乎100%的成功率)

我看到许多开发人员陷入了iOS小部件的刷新之谜,最终放弃了使用它。希望我的经历能帮助其他人更好地理解并更快地做出决定。

@Lebecca我只是想从我这边补充更多的见解。希望你觉得它有帮助。

在我的应用程序中,我在应用程序进入后台之前调用WidgetCenter.shared.loadAllTimelines。我对这个重新加载没有任何问题。重新加载成功率为100%。

根据我的经验,当应用程序进入后台时,你有几秒钟的时间来做一些工作,然后这个过程就会终止。您的小部件可能需要比允许的时间更多的时间来重新加载。这就是为什么您看不到“重新加载”的一致性。您在应用程序进入前台后立即调用WidgetCenter.shared.loadTimelines的解决方案解决了这一问题,因为您给了小部件“更多”的时间来完成重新加载。(当应用程序处于前台时,您对处理时间没有限制。)

有3个部分涉及小部件重新加载。

1. 小工具的数据:如果你的应用程序需要运行一些代码或从网络中检索一些信息。请确保它不会花费太长时间,否则小部件重新加载过程可能会被终止。

2. 小部件的复杂性:这里我指的是您的小部件视图是否复杂。许多堆栈、许多元素可能会导致小部件重新加载失败。

3. 你有多少时间线条目:假设你一天有100个时间线条目,这也可能会导致一些问题。你需要找到时间线条目和你计划在一天内运行的重新加载次数的平衡。

4. 小工具重新加载预算。为了安全起见,我总是尽量每天保持40-50次左右。

小工具真的是个谜。以上都是我的经验。