UITableView Best Practices [closed]

Question

What are the best practices when dealing with UITableViews in order to improve the performance, speed up the development and maintenance when dealing with UITableViews?

Answer 1

This isn't the first time this question has been asked on SO. Here's my previous answer on the matter:

• Dynamic row height is expensive, because it cannot cache the rendered views efficiently, as the runtime doesn't know what height you're going to return for a given cell until it makes the call. Don't use it if at all possible. I was told by Apple Engineers that it's more efficient to draw all the cells a little taller than necessary to account for a few larger rows, than to use dynamic height.
• Only fetch the array item once [items objectAtIndex:indexPath.row] in the -tableView:cellForRowAtIndexPath: method
• Use a cache for any images or other network resources. Try the EGOImageView stack, it caches it's image efficiently, and is some pretty slick code.
• While you're in the EGO github code, grab their EGOCache and use it to cache any other objects you need to manipulate, such as strings that are parsed and modified
• If any of your views on that cell are transparent, watch the WWDC 2011 video on UIKit performance. They have a much more efficient method to draw transparency on tableview cells
• If you're using Core Data, use the NSFetchedResultsController in your table view. It handles loading faults, caching indexes, and other efficiencies specific to table ivews.

Also watch the WWDC video on using instruments, they go over how to find where drawing code is killing performance. This year had some (some, not all) really great sessions.

Answer 2

Optimize last, so subclass UITableViewCell if you need custom cells - and if you someday want to improve rendering performance you might want to render the content using drawRect: instead.