我一直在强调这个问题大约一个星期,试图指出缓慢但稳定的Apple Watch应用程序性能下降的根源。在大约两天的时间里,我的应用程序的用户界面将变得越来越迟钝。我已将其缩小为复杂的更新代码。即使我将并发症更新删除到绝对最低限度,这个问题仍然会发生,尽管比我用一些实际数据更新并发症要慢。我每10分钟更新一次并发症。一旦新数据出现,我只需执行
for (CLKComplication *comp in [CLKComplicationServer sharedInstance].activeComplications) {
[[CLKComplicationServer sharedInstance] reloadTimelineForComplication:comp];
}
反过来调用:
- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {
...
}
这很好用,新数据显示,但是当重复几十次时,主应用的UI响应性开始显着降低,并且当它重复大约一百次时(在不到一天的时间内发生10次)用户界面确实显着减慢了。
我对复杂化结构一无所知 - 没有时间旅行,只显示当前数据,一切都是为此设置的。为了确保我没有找错地方,我做了一个测试,每秒重新加载时间轴,在这个测试中,我的getCurrentTimelineEntryForComplication看起来像这样:
- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {
handler(nil);
}
所以几乎什么都没有,只需发回空处理程序。然而,即使在这种情况下,经过一百左右的时间线重新加载,主应用程序的用户界面显然会明显减慢。
其他一些注意事项:
如果我没有更新复杂功能,应用程序的UI性能永远不会降低,无论我打开它多少次,或者我使用它多长时间,或者数据提取代码在后台运行多少次
在模拟器中对此进行测试时,我无法实现性能下降,但我可以始终看到来自并发症更新的内存泄漏很小但是稳定(同样,这种情况无论如何都会发生我在getCurrentTimelineEntryForComplication方法中做了多么简单的更新。
有没有人注意到这一点,有没有希望处理它?难道我做错了什么?目前我确保只在数据发生变化时才更新并发症,但这只是推迟了问题,而不是解决问题。
10月24日编辑
我在一块真正的手表上做了更仔细的测试,虽然之前由于某些原因我没有注意到真实手表上与此相关的内存泄漏,我现在肯定已经看到它发生了。真实设备完全反映了在模拟器上看到的问题,只是使用了不同的初始内存分配量。
同样,我所做的只是在一个常量循环上调用reloadTimelineForComplication,并且使用来自缓存数据对象的单行文本更新复杂性,并且复杂化控制器被剥离到最低限度。当从表盘上移除并发症时,内存泄漏可以预测地停止。
我的主要项目是用ObjectiveC编写的,但是我已经用Swift中的测试项目重复了测试,并没有区别。此外,最新的XCode 8.1 GM和随附的模拟器提供的watchOS 3.1 beta以及在安装了watchOS3.1的真实手表上运行时,问题仍然存在。
2017年1月24日编辑
可悲的是,watchOS 3.1.3中的问题仍然存在,完全没有改变。与此同时,我已经联系了Apple的代码级支持,向他们发送了示例代码,他们已经确认问题存在,并告诉我提交错误报告。两个月前我确实提交了一份错误报告,但直到现在它还没有分类,我想这意味着没有人看过它。
2017年1月31日编辑
Apple修复了watchOS3.2 beta 1中的问题。我一直在模拟器和真实手表上测试它。一切都很好,没有内存泄漏或性能下降。最后没有解决方法,直到他们决定修复它。
答案 0 :(得分:4)
Apple修复了watchOS3.2 beta 1中的问题。我已经在模拟器和真实手表上测试了它。一切都很好,没有内存泄漏或性能下降。最后没有解决方法,直到他们决定修复它。
答案 1 :(得分:0)
我注意到使用原生日历复杂功能我所做的一切都变得非常缓慢。也许这是新手表操作系统中的一个错误。 使用日历复杂功能几天后,无法使用该表盘。即使我改为另一个复杂功能并切换回日历,它也不会“重置”性能。解决的唯一问题是重启手表。 (或忘记日历并改为使用其他复杂功能)