为什么即使包含应用程序在前台，iOS 小部件也不会及时刷新

Question

我对iOS widget刷新机制做了一些研究：

\n

1 前台包含app，widget刷新不受限制

\n

阅读苹果开发人员文档，我了解到小部件刷新是由 WidgetKit 预算控制的。正如它所说：

\n

\n

对于用户经常查看的小部件，每日预算通常包括 40 到 70 次刷新

\n

\n

但在以下情况下，重新加载不会计入 widget\xe2\x80\x99s 预算：

\n

\n
• 包含应用程序的 widget\xe2\x80\x99s 位于前台。
\n
• 包含应用程序的 widget\xe2\x80\x99s 有一个活动的音频或导航会话。
\n
• 系统区域设置发生变化。
\n
• 动态类型或辅助功能设置发生变化。
\n

\n

2 我们可以使用WidgetCenter.shared.reloadTimelines包含应用程序来刷新小部件

\n

同一个医生说：

\n

\n

在上面的游戏小部件示例中，如果应用程序收到一条推送通知，表明队友已给角色提供治疗药水，则应用程序可以告诉 WidgetKit 重新加载时间线并更新小部件\xe2\x80\x99s 内容。

\n

\n

3 我已经看到了一些很棒的实现

\n

当我收到朋友发来的帖子时， LiveIn之类的应用程序通过及时刷新小部件为我提供了流畅的用户体验（只要包含的应用程序位于前台，我猜他们可以通过后台刷新来改进这一点）。

\n

该产品不受每日 40 到 70 次刷新预算限制的限制，并且我在包含应用程序和小部件的图片显示之间有一点延迟（小到可以忽略）。

\n

4 但我还是被困在这里

\n

但是，当我尝试使用上述 API 构建应用程序WidgetCenter.shared.reloadTimelines或通知小部件使用UserDefaultsWidgetCenter.shared.reloadAllTimelines中存储的数据刷新时，我的小部件没有及时响应 API 调用。有时，可能会卡住10分钟以上，这与我上面提到的产品相差甚远，这是一个可怕的情况。

\n

5 一些黑客尝试

\n

我浏览了很多 Stackoverflow 问答和博客，确实在 iOS 小部件中发现了一些棘手的事情。例如，该View._clockHandRotationEffect(.secondHand, in: .current, anchor: .center)API 可用于无限制地刷新小部件视图（通常用于构建基于时钟的应用程序）。

\n

但它似乎与包含应用程序和小部件之间的消息通知无关（或者只是我还没有弄清楚）。

\n

6 我的问题

\n

我的问题来了。由于iOS商店中已有的一些应用程序已经具备了及时通知小部件的功能，为什么我仍然无法获得官方文档指导的流畅用户体验？我是否错过了一些重要的事情，或者他们只是使用了我看不见的其他私有 API？

\n

代码并不复杂，而且 Xcode 签名很烦人，所以我没有准备一个最小的项目来重现它。如果您想尝试一下，可以将pawello2222/WidgetExamples作为演示。任何提示或线索将不胜感激！

\n

Answer 1

最终，我们获得了流畅的用户体验。该解决方案乍一看很奇怪，但与我们之前的实现相比，它的工作方式却很有魅力。

\n

您需要做的就是在应用程序进入前台后尽快调用WidgetCenter.shared.reloadTimelines或。WidgetCenter.shared.reloadAllTimelines

\n

为什么？正如管理应用程序生命周期的文档所述：

\n

\n

前台应用程序具有用户\xe2\x80\x99的注意力，因此它优先于系统资源，包括CPU

\n

\n

文档很清楚，但时间也很重要，有一些现象我们测试是原样的，但在任何官方文档中都找不到（在发布版本中运行应用程序，而不是连接 xcode 的调试模式）：

\n

\n
• 一直在前台启动app，通过调用WidgetCenter.shared.reloadTimelines或WidgetCenter.shared.reloadAllTimelines不断的方式通知widget刷新视图，随着时间的推移延迟会明显增加
\n
• 调用时WidgetCenter.shared.reloadTimelines或WidgetCenter.shared.reloadAllTimelines应用程序启动后，小部件视图将立即刷新（几乎 100% 成功率）
\n

\n

我见过很多开发者深陷 iOS 小部件的刷新之谜，最终放弃使用它。希望我的经历能帮助其他人更好地理解并更快地做出决定。

\n