当 numberOfRows 返回一个大数时，UITableView 需要更长的时间来加载 [英] UITableView takes much longer to load when numberOfRows returns a large number

问题描述

为什么UITableView在行数大的情况下加载时间会变长?viewDidLoad 和第一个 cellForRowAtIndexPath 函数调用之间需要多少时间?

Why does UITableView take more time to load when the number of rows is large? What is it that takes time between viewDidLoad and the first cellForRowAtIndexPath function call?

这些是 numberOfRows 返回 100,000 时的日志语句(注意时间(延迟 5 秒)):

These are the log statements when numberOfRows returns 100,000 (notice the time (5 seconds delay)):

2014-02-05 20:51:22.806 TableViewTest[3995:60b] View Did Load
2014-02-05 20:51:27.526 TableViewTest[3995:60b] Cell for row at indexpath.row: 0

这些是 numberOfRows 返回 10,000 时的日志语句(注意时间(1 秒延迟)):

These are the log statements when numberOfRows returns 10,000 (notice the time (1 second delay)):

2014-02-05 20:54:50.793 TableViewTest[4007:60b] View Did Load
2014-02-05 20:54:51.846 TableViewTest[4007:60b] Cell for row at indexpath.row: 0

推荐答案

如果你在你的 table view 中实现了 heightForRowAtIndexPath: ，那么 iOS 会去检查每个单元格的高度，我想画滚动条.因此，如果可能，让该调用非常快是值得的.

If you implement heightForRowAtIndexPath: in your table view, then iOS will go and check the height of each cell, I think to draw the scroll bar. So it's worth it to make that call very fast if possible.

如果你支持 iOS 7，那么考虑实现 tableView:estimatedHeightForRowAtIndexPath: 它可以只返回一个常量(或者可能是非常快速的逻辑)来猜测高度.当 heightForRowAtIndexPath: 被调用时，这将延迟到实际查看单元格之前，并且应该会大大加快速度.

If you are supporting iOS 7, then consider implementing tableView: estimatedHeightForRowAtIndexPath: which can just return a constant (or maybe very quick logic) to guess at the height. This will delay when heightForRowAtIndexPath: is called until right before the cell is actually viewed and should speed things up a lot.

这篇关于当 numberOfRows 返回一个大数时，UITableView 需要更长的时间来加载的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！