重新加载 tableview 部分时的性能问题答案

【问题标题】：Performance issue when reloading tableview section重新加载 tableview 部分时的性能问题
【发布时间】：2013-07-30 20:55:06
【问题描述】：

当我的应用程序接收到新数据时，我的视图控制器会发送和接收通知。视图控制器然后重新加载其 tableview 的部分之一。这通常只需要 40 毫秒左右。

但是，如果我推送了另一个视图，通知仍由原始控制器处理，但重新加载 tableview 需要大约 10-20 倍的时间。

我当然可以努力提高我的 tableview 性能，但首先我需要了解导致这种情况的原因。也将感谢使用 Instruments 帮助我自己调试它。到目前为止，我已经运行了“时间分析器”仪器，看起来大部分精力都花在了系统方法“[UIView(Hierarchy) layoutIfNeeded]”上。这对我来说意义不大。

【问题讨论】：

当控制器不在屏幕上时，您还在表格视图上调用 reloadSections:withRowAnimation: 吗？
控制器仍在以正常方式响应这些通知，是的。这个想法是，如果用户在其他地方时发生了一些变化，则 tableview 会更新。
当视图不在屏幕上时，我不确定这是一个好主意。也许您可以将数据源的更新（将由通知完成）与表格视图的更新分开，并且只有在视图在屏幕上时才执行后者。
这可能会有所帮助。除了我必须在 viewWillAppear 中手动重新加载，这会破坏一些动画（例如选定的单元格）。我想如果数据在屏幕外发生更新，无论如何都会发生这种情况。我想如果我走这条路，我可能会在不在主控制器上时完全停止检查更新。不过，我主要对为什么相同的操作在屏幕上花费的时间只是一小部分感兴趣。

标签： ios performance cocoa-touch uitableview instruments

【解决方案1】：

您绝对不需要在不在屏幕上的元素上更新 UI。 UI 更新将在主线程中进行，这将对用户体验产生负面影响。

更新您的数据源（在后台线程中）应该足够了，然后您可以在下次向用户显示 tableview 时更新它。

【讨论】：

如果这是我采取的方法，我想我会在消失时完全取消订阅通知并在出现时重新订阅。否则我必须围绕一些边缘情况编写代码。但我最想了解根本原因 - 为什么当视图在屏幕外而不是在屏幕上时，相同的方法需要更长的时间。
我猜这是因为当视图离开屏幕时，主线程忙于处理用户交互并在显示的视图上进行 UI 更新，并且您的代码也试图在主线程中运行。但是，如果不看到它就无法判断。