1

我正在为 WatchOS 2 编写 Apple Watch 复杂功能。我尝试显示的特定数据（通过网络请求）以 3-6 分钟的时间间隔给出。我有一个预测算法，可以预测数据值的样子。这给我带来了一个问题。

因为我想显示我的预测算法在时间旅行中必须提供的数据，所以我想使用 getTimelineEntriesForComplication（在特定日期之后要求数据的版本）来提供我的算法认为对时间线正确的未来值. 然而，当时间向前移动（正如它倾向于做的那样）并且我们到达这些预测数据点之一被设置为发生的时间时，预测值不再准确。

例如，假设现在是下午 12:00，我目前有一个（准确的）数据值 A。预测算法可能会预测接下来两个小时的以下数据值：

  • 下午 12:30 | 乙
  • 下午 1:00 | C
  • 下午 1:30 | D
  • 下午 2:00 | 乙

但是，当 12:30 PM 实际到来时，实际数据值可能是 F。此外，该算法将生成一组新的预测，一直到下午 2:30。我知道我可以用它updateTimelineForComplication来表示必须重建时间线，但是这种方法有两个问题：

  1. 我担心我会很快超过执行时间限制
  2. updateTimelineForComplication刷新整个时间线，考虑到所有过去的数据都是完全有效的，这对我来说似乎很浪费，它只是接下来需要更新的 4 个左右的值。

有没有更好的方法来处理这个问题？

4

1 回答 1

3

目前，在不重新加载整个时间线的情况下，无法更改特定时间线条目。您可以向 Apple 提交功能请求。

概括

总结以下细节，即使您的服务器每 3-6 分钟更新一次预测，复杂功能服务器也只会每隔 10 分钟更新一次，从一小时开始。重新加载时间线是您唯一的选择，因为它可以保证您的所有预测都在 10 分钟内更新并准确无误。

具体发现

我在过去涉及extendTimelineForComplication:使用最小 10 分钟更新间隔的测试中发现，在基于当前时间的滑动窗口之前和之后要求数据源输入 100 个条目。

滑动窗口不以当前时间为中心。对于 watchOS 2.0.1，它似乎倾向于要求更多最近的未来条目（在未来约 14-27 分钟之后），以及较少最近的过去条目（在过去约 100 分钟之前）。

重新加载是更新落在约两小时滑动窗口内的任何条目的唯一方法。

问题

根据我的经验，extendTimelineForComplication它不如重新加载时间线可靠，因为需要修剪从未重新加载的时间线以丢弃条目。每小时的条目数越少，这种情况发生的频率就越低，但是一旦时间线缓存增长到足够大，SDK 似乎会积极丢弃缓存头部和尾部的条目，即使这些条目在 72 小时内-旅行窗口。我见过的最糟糕的情况是只能向前穿越 30 个条目，而不是 100 个。

提供了这些细节后，我不建议任何人尝试利用未来可能改变的任何行为。

每日预算和电池寿命

至于每日预算，这听起来比实际更不祥，但我认为你必须在复杂服务器切断你之前进行一些激烈的计算。即使有十分钟的更新，我也从未超出预算。真正的问题是电池使用。您会发现，频繁的更新可能会在一天结束之前耗尽您的电池电量。这可能是苹果推荐的最重要原因：

并发症应在每个更新周期内提供尽可能多的数据，因此请尽可能指定未来的日期。不要要求系统在几分钟内更新您的并发症。提供持续数小时或一整天的数据。

于 2015-11-30T06:58:20.010 回答