优化 scrollView 性能（tableView）

最新推荐文章于 2025-06-12 09:29:42 发布

转载最新推荐文章于 2025-06-12 09:29:42 发布 · 2.5k 阅读

文章标签：

1 篇文章

订阅专栏

本文探讨了优化UITableView滚动性能的方法，包括减少cell子视图数量、使用drawInRect替代子视图布局、避免使用透明效果等策略，并分析了这些方法对性能的影响。

关键字: scroll 性能 performance tableview

曾经尝试各种方法优化滚动视图的性能，都没什么好的效果。

今天在官方文档的 tableView 一章节找到些内容。

大致内容是：

具体效果如何，测试中。

原文如下

Draw the entire cell only when appropriate . Your subclass of UITableViewCell could draw all of its content in its drawRect: method, but you should be aware of the potential drawbacks of this approach. Custom drawing applies to the cell’s layer, which can be obscured by any views placed over it. For example, in table views in the grouped style, the background view (the backgroundView property) obscures any drawing performed in drawRect:. The blue selection background will also obscure any drawing. Moreover, custom drawing that occurs during animation (such as when the table view enters and exits editing mode) drastically decreases performance.

An alternative is a subclass that composes the content of the cell from subviews, laying those views out in the desired way. Because those views are cached, they can simply be moved around (when, for instance, the cell goes into editing mode). “Programmatically Adding Subviews to a Cell’s Content View” illustrates one such approach and notes another.

However, if the content of a cell is composed of more than three or four subviews, scrolling performance might suffer. In this case (and especially if the cell is not editable), consider drawing directly in one subview of the cell’s content view. The gist of this guideline is that, when implementing custom table-view cells, be aware that there is a tradeoff between optimal scrolling performance and optimal editing or reordering performance.

Avoid transparency . Subviews of table-view cells have a compositing cost that you can largely mitigate by making the views opaque. Even one transparent subview per cell impacts scrolling performance. Always use opaque subviews if at all possible.

Mark the cell as needing display when viewable properties change . If you have a custom reusable table cell and it displays a custom property as part of the cell content, you must be sure to send a setNeedsDisplay message to the cell if the value of the property changes. Otherwise UIKit doesn’t know that the cell is “dirty” and therefore won’t invoke the cell’s drawRect: method to have it redraw itself with the new value. A good place to call setNeedsDisplay is in a (non-synthesized) setter method associated with the property.