ios - UITableViewDelegate 方法的确切顺序是什么 - 奇怪的行为

Question

我正在做一些研究以获得 tableview 委托(delegate)方法的准确执行顺序。

情况 1:行数 - 对于小值

所以首先我创建了 100 行并发现执行流程如下。

1. numberOfSectionsInTableView
2. numberOfRowsInSection
3. cellForRowAtIndexPath

情况 2:行数 - 超出 Int 限制

我尝试返回大于 int 限制的值

然后发现抛出异常。效果很好。

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException',
 reason: 'Failed to allocate data stores for 402337200000000 rows in section 0.
 Consider using fewer rows'

情况 3:行数 - Int 值但更高

之后，我将行数更改为 4023372000000 一个理想值，但确认返回类型为 Int。

当时它需要超过 5 分钟，任何委托(delegate)方法在它崩溃后被调用。在调用 cellForRowAt 之前卡住了。我的系统也卡住了那么长时间。没有崩溃日志。

卡住时的内存使用情况

内存使用率变高

可用空间= -50GB(也使用我的系统内存)使用百分比 = 600%

如果他们确定它会崩溃，那么这个范围应该包含在异常情况中。

他们在那段时间做了其他事情吗？

在情况 3 中，编译器正在做其他事情，并且“只有要在屏幕上显示的单元格才会为 tableview 加载”的概念失败了。

Answer 1

您的问题标题“UITableViewDelegate 方法的确切顺序是什么”假定存在已定义的顺序。您确定的方法:

• 表格 View 中的节数:
• 编号的行数:
• cellForRowAt:

实际上是在 UITableViewDataSource protocol 中定义的其中没有提及调用方法的顺序。似乎存在一个“逻辑”顺序，这与您在案例 1 中观察到的大致相同。但是，也有异常(exception):在我的测试中，numberOfSectionsInTableView: 被连续调用两次，中间没有调用其他方法。

在您的案例 2 中，您指定了大量的行，因此 tableView 会抛出异常。这似乎可以理解:tableView 无法为所有这些行“分配数据存储”。如果它为每一行存储 1 位信息，那就是 46 TB。它抛出异常并不奇怪。

您的案例 3 显然是中间立场。为什么没有立即异常(exception)？谁知道。空间需求为 468 GB，远远超过当前的任何设备，但在几年后的可信度范围内。鉴于 iOS 在许多不同的设备上运行，具有不同的内存大小，一些 32 位，一些 64 位等，Apple 开发人员不能，对于任何给定的行数，“确定它会崩溃”。很明显，他们已经决定/默认尝试。

那么在调用 numberOfRowsInSection 之后和调用 cellForRowAt 之前发生了什么(或崩溃)？ tableView 显然正在做一些事情来尝试满足对这些行的请求。

UITableViewDelegate protocol在“Configuring Rows for the Table View”标题下定义了几个方法:

• 行高度:
• estimatedHeightForRowAt:
• indentationLevelForRowAt:
• willDisplay:forRowAt:
• shouldSpringLoadRowAt:with:

这些都是可选的方法，但是实现它们可能会提供一些关于正在发生的事情的线索。据我所见，heightForRowAt 在 cellForRowAt 之后调用(因此仅当单元格已分配给特定行时)。但看起来 estimatedHeightForRowAt 是在 numberOfRowsInSection 之后和 cellForRowAt 之前为每一行单独调用的。

为什么 tableView 想要知道所有行的估计高度，甚至在为其中一行加载单元格之前？我的猜测是 tableView 试图确定其总体 contentSize:将所有行的高度相加以获得总高度。实现 estimatedHeightForRowAt 显然会增加 tableView 的工作量并因此减慢它的速度，但即使您没有实现该方法，tableView 也必须做一些事情来计算每一行的高度:这需要时间和内存。

转向您的结论，“'只有要在屏幕上显示的单元格才会被加载到 tableview' 的概念是失败的”:请注意正在使用的内存和花费的时间与 的数量有关行数，而不是单元格数。方法名称均引用 ...*row*At。即使是案例 2 中的异常(exception)情况也涉及行 的数据存储。如果您登录 cellForRowAt，您会看到它只针对屏幕上显示的行数调用，在您滚动之前，可以有几行。滚动会导致单元格离开屏幕，此时 tableView 将它们放入队列中，准备好为即将出现在屏幕上的行重新使用(“出队”)。因此，您的结论是错误的:单元格 仅针对出现在屏幕上的行加载。