提高 iPhone UITableView 滚动性能的技巧?

我有一个可用的视图,载入相当大的图像在每个单元格和单元格的高度取决于大小的图像。滚动性能是不错的,但有时可能会出现问题。

我在 FieryRobot 博客上找到了这些建议:

带实用视图的玻璃卷动式

更玻璃化滚动与可用视图

有人有什么提高 uitableview 滚动性能的建议吗?

51871 次浏览
  1. If you are subclassing UITableViewCell, don't use a Nib, write it in code instead. It's much faster than loading Nib files.
  2. If you're using images, make sure you're caching them so you don't have to load from file more than once for each (if you have the memory -- you'd be surprised how much space images take up).
  3. Make as many elements opaque as possible. Similarly, try not and use images with transparency.
  1. Cache the height of the rows (the table view can request this frequently)
  2. Create a least-recently-used cache for the images used in the table (and invalidate all the inactive entries when you receive a memory warning)
  3. Draw everything in the UITableViewCell's drawRect: if possible avoid subviews at all costs (or if you require the standard accessibility functionality, the content view's drawRect:)
  4. Make your UITableViewCell's layer opaque (same goes for the content view if you have one)
  5. Use the reusableCellIdentifier functionality as recommended by the UITableView examples/documentation
  6. Avoid gradients/complicated graphical effects that aren't pre-baked into UIImages

The developer behind Tweetie has written extensively about this and has some code that demonstrates how it was done for that app. Basically, he/she advocates one custom view per table cell, and drawing it manually (rather than subviewing with Interface Builder, among other options).

fast-scrolling-in-tweetie-with-uitableview

Also, Apple has updated its own sample code for TableView in its TableViewSuite tutorials (maybe in response to this?)

TableViewSuite

#1 performance killer for UITableView scrolling is drawing shadows on any cell view layer, so if scrolling performance matters then don't do shadows unless basically it doesn't slow down your main thread.

thought this had to be said since none of the accepted answers made mention of shadows and layers. :+)

Any problem with UITableView scrolling performance can be solved using techniques already described in other answers. However many a times sluggish performance is caused by something inherently erroneous, or repetitive.

The fact that UITableView reuses the cells, and the fact that each cell may need its own image - together makes the solution bit complex. From how it's being solved the general way, here I summarize things that should be taken care of:

  1. Load data into data source - from REST / database. This step should be done on background, eventually using dispatch_async along with GCD queue.
  2. Create and initialize relevant data model objects and putting them inside an array
  3. [tableView reloaddata]
  4. Inside cellForRowAtIndexPath, include code that will set data (text) from correct data model object of the array.
  5. Now images maybe in the form of URL too, so this step might be little quirky because of cell reuse done by table view. The heart of the fact is to load once again image from device cache / URL using async queue, then set it to correct cell.image (whatever is your cell image property).

To avoid problems, refer to this tutorial about lazy loading of images inside table view.