根据下面的数据，ClockKit生成一次未来的CLKComplicationTimelineEntry项，但对于过去的时间点，会进行24次调用！为什么会这样？
更多详细信息：
我注意到我的Apple Watch复杂功能中有一个奇怪的行为。
它支持时间旅行——我提供过去1天和未来4天的数据。我目前正在努力成为一个好公民，减少打电话来重新生成我的并发症数据。
为了了解某些调用的频率，我在输出before/after参数的getTimelineEntries(for:before:limit:withHandler:)和getTimelineEntries(for:after:limit:withHandler:)中都放置了一个简单的print。
当我在模拟器中启动应用程序/并发症时，我会得到以下输出：
generate future timeline entries (after date:2016-07-23 10:33:31 +0000)
generate past timeline entries (before date:2016-07-23 10:33:31 +0000)
generate past timeline entries (before date:2016-07-23 09:33:31 +0000)
generate past timeline entries (before date:2016-07-23 08:33:31 +0000)
generate past timeline entries (before date:2016-07-23 07:33:31 +0000)
generate past timeline entries (before date:2016-07-23 06:33:31 +0000)
generate past timeline entries (before date:2016-07-23 05:33:31 +0000)
generate past timeline entries (before date:2016-07-23 04:33:31 +0000)
generate past timeline entries (before date:2016-07-23 03:33:31 +0000)
generate past timeline entries (before date:2016-07-23 02:33:31 +0000)
generate past timeline entries (before date:2016-07-23 01:33:31 +0000)
generate past timeline entries (before date:2016-07-23 00:33:31 +0000)
generate past timeline entries (before date:2016-07-22 23:33:31 +0000)
generate past timeline entries (before date:2016-07-22 22:33:31 +0000)
generate past timeline entries (before date:2016-07-22 21:33:31 +0000)
generate past timeline entries (before date:2016-07-22 20:33:31 +0000)
generate past timeline entries (before date:2016-07-22 19:33:31 +0000)
generate past timeline entries (before date:2016-07-22 18:33:31 +0000)
generate past timeline entries (before date:2016-07-22 17:33:31 +0000)
generate past timeline entries (before date:2016-07-22 16:33:31 +0000)
generate past timeline entries (before date:2016-07-22 15:33:31 +0000)
generate past timeline entries (before date:2016-07-22 14:33:31 +0000)
generate past timeline entries (before date:2016-07-22 13:33:31 +0000)
generate past timeline entries (before date:2016-07-22 12:33:31 +0000)
generate past timeline entries (before date:2016-07-22 11:33:31 +0000)
没有规定数据源方法只被调用一次。您只需要做好处理请求的准备。
为什么它处理过去的条目与处理未来的条目不同
我相信这是一个优化，旨在优先考虑即将到来的时间线条目（相对于最近的过去条目）。
回到watchOS 2.0.1，复杂服务器首先用未来的条目填充时间线，然后用过去的条目填充时间表。当然，苹果可能会选择批量处理过去的条目，以优先考虑最近的条目而不是更远的条目，这是可以理解的。
虽然苹果从那时起肯定调整了代码，但同样的关注度和细节很可能会继续应用于当前版本的watchOS。
如果这对我来说是一项昂贵的手术怎么办
如果您需要做的不仅仅是简单地使用现有的复杂数据，而且您的数据检索与系统发出的特定请求有关，那么您应该重构代码，将其转移到该方法之外。
通常，您希望手头已有预取的数据，这些数据可以直接转换为时间线条目。
这在watchOS3中变得更加重要，因为你不仅要更新复杂的应用程序，还要在后台更新你的应用程序。即使你现在仍然需要支持watchOS 2，你也应该设计如何获取数据和更新复杂情况，以了解watchOS 3如何完成整个应用程序的更新
为什么它多次调用我的数据源方法
苹果使用各种技术来优化复杂服务器（或操作系统的其他部分）的工作方式。你所能做的就是相信这个系统是为了减少内存和能源使用而调整的，而且它这样做是有充分理由的。
这实际上已经是多年来的标准做法，并且在UITableViewDataSource中很常见，其中像numberOfSectionsInTableView这样的方法可能会被调用多次。
正如另一位海报所写，一个方法的调用次数可以在不同版本的操作系统之间变化。
如果是个bug怎么办
它很可能按预期工作，但如果你认为这是一个错误，你可以创建一个最小的示例项目，并将其与错误报告一起提交给苹果。
关于时间旅行的无关注释
我注意到你想提供4天的未来时间旅行条目。这将超过时间旅行滑动窗口。
为了提高效率，您可能需要考虑latestTimeTravelDate:
在构建时间线时，不要在此日期之后创建任何条目。这样做是浪费时间，因为这些条目不会立即显示。
我几乎可以肯定，这实际上与我在watchOS应用程序中遇到的问题相同；我的代码生成了一个从最新到最不新的时间线条目数组，而Complication服务器希望条目按最近到最近顺序排列。
因此，复杂服务器使除我生成的第一个条目外的所有条目无效，并在该条目之前立即请求更多更新。
我的修复方法是将getTimelineEntries(for:after:limit:withHandler:)函数从appending条目更改为索引0处的inserting。