Question

Could anyone tell me the tradeoff in performance/memory usage between using static and dynamic cells in a UITableView?

Here’s my situation: I have a TableView with 6 different sections. The first section is the only section in my tableView that holds a different number of cells each time the view loads, depending on the current state of the app. i.e. I have declared 12 static cells for that section in interface builder, however I only display a certain number of those cells depending on the user’s interaction with the app thus far. The other 5 tableView sections all contain UISwitches and textFields that never change.

So say I statically allocated 50 cells for that first section, but still only displayed maybe just half of them depending on the state of the app. I would want to be able to display up to 50 cells though. How would this affect the speed or performance of my app? Would doing the entire tableView dynamically and redrawing the switches and textFields for the other sections each time lead to a better application performance?

Answer 1

UITableView itself is only tangentially related to performance in this situation. The real issue is how and when you allocate new cells.

If you have static cells whose contents never change, and you create them using the interface builder (née Interface Builder), you will see that allocation happening only once, usually in -viewDidLoad, and for the lifetime of that table (or at least until -viewDidUnload) these cells will exist and not need to be reallocated.

But this is a trade-off. Now your cells will load faster, but your app will have more memory. You’ll just have to decide on a case-by-case basis whether this is slowing down your app dramatically, in which case you may want to lazily load your static cells the typical “dynamic” style in your data source cell-fetching method.