我以为我已经阅读了一个UITableView不会heightForRowAtIndexPath在所有行上调用的内容，而只是在那些可见的行上。然而，这不是我所看到的。例如，我看到数百个电话要求heightForRowAtIndexPath更改 iPhone 的方向这一简单情况。
因此，我在这里假设对于已实现的 a UITableView，heightForRowAtIndexPath它确实（即heightForRowAtIndexPath）被所有行（不仅仅是可见行）调用...如果这不是很正确，请告诉我。
问题：鉴于上述情况，在通常发生性能问题之前，您可以拥有多少行UITableView（在哪里实现）？heightForRowAtIndexPath
有没有办法解决性能问题？即为每行设置一个标称/标准高度而不是实现heightForRowAtIndexPath，但是只有在显示时正确设置每行高度并在此处正确设置...但是哪种方法可以做到这一点？
查看tableView:heightForRowAtIndexPath:文档中的讨论部分
该方法允许委托指定具有不同高度的行。如果实现了此方法，它返回的值将覆盖为给定行的 UITableView 的 rowHeight 属性指定的值。
使用 tableView:heightForRowAtIndexPath: 代替 rowHeight 属性会影响性能。每次显示表视图时，它都会在委托上为其每一行调用 tableView:heightForRowAtIndexPath:，这可能会导致具有大量行（大约 1000 或更多）的表视图出现严重的性能问题。
所以你应该使用rowHeightUITableView 的属性。如果您需要不同的高度，那您就不走运了，因为您必须使用tableView:heightForRowAtIndexPath:.
AFAIK 无法更改显示时的行高。
tableview 之前必须知道正确的大小，否则会一直出现难看的位置偏移。
我想我找到了解决办法。
在 iOS 7 苹果引入了一些新的 tableview 属性。其中之一是：
tableView:estimatedHeightForRowAtIndexPath:
因此，如果您提供估计的行高，例如，当 tableView:heightForRowAtIndexPath: 在表格显示之前被重复调用时，它只会为表格的可见单元格调用；对于剩余的单元格，使用估计的高度。
天哪，我花了一个多小时试图找到我的性能问题的根源！
最后，我还发现了数百个对 heightForRowAtIndexPath 的调用，并且搜索得到了这个线程。这真的很烦人。仅显示 250 个项目时，性能已经下降。谢天谢地，我现在要显示的单元格都具有相同的大小。但我可以想象有人想为一个超过 200 个项目的 tableView 显示一些不同的单元格！
修好这个苹果！
干杯
在具有大量行和动态单元格高度的 tableViews 中提高性能的一种方法是在第一次计算单元格时缓存单元格的高度。
实现此目的的一种简单方法是保留 a NSMutableDictionary，其中键是单元格中记录的 id （或您可能拥有的任何其他标识符），值是NSNumber带有行高的 a 。首次计算高度后，将其存储NSMutableDictionary为记录 ID。在 中tableView:heightForRowAtIndexPath，tableView:estimatedHeightForRowAtIndexPath:您检查字典中的缓存高度，如果找到则返回。如果没有找到，则计算高度，并在返回高度之前存储在缓存中。
您可能必须小心使更改高度的行的缓存无效。例如，如果您的一个单元格中有一个展开按钮，则需要在点击展开按钮后从缓存中删除该单元格的高度委托方法调用高度。
如果您尝试在表格显示时一次显示 1000 个单元格，您可能仍然会受到性能影响，因为它可能会为每一行调用 height 方法。解决此问题的方法是，如果可能的话，在后台任务中首先预热缓存，然后再显示单元格。