iOS *Cell Performance: Autolayout vs Frame?

Question

I'm using Auto-layout for cells (UITableViewCell and UICollectionViewCell), but noticed a significant performance drawback when the cells are re-used and I wonder what could I do to improve it.

Maybe it is due to the way I create/configure cell, in my app I need to show books as cells, and different book genres have different layout, but I only have one BookCell, I re-configure constraints when the cell is created/reused for a particular Book based on the book's genre.

From my understanding, in my case, auto-layout should be slower than fixed frame as the steps are as follows:

auto-layout

1. remove current constraints
2. re-add constraints depending on book's genre
3. set all labels / image views for the book

I think internally at step 2 iOS will re-run the constraints solver and at step 3 will re-adjust constraints (ie re-run the solver) to satisfy all labels and image views with text and images set.

fixed-layout

(have a list of different frames for labels, image views, for different genre) 1. re-set all labels', image views' frames 2. set labels' text and image views' images

It takes me some time to convert all auto-layout cells to use fixed frames, and the things I can think of, in order to improve the performance are:

1. duplicate the generic BookCell, and make one cell for each genre.
2. set all labels, image views, before setup constraints
3. not too sure about this, should I add auto-layout constraints in updateConstraints method, or in the initializer (e.g. initWithTableViewCellStyle:reusableIdentifier:)?

Thanks a lot!

Answer 1

Converting from Auto Layout to frames will be time consuming and will give you the least benefit in performance. Not to mention complications when you develop in iOS7. (See my other answer on this here).

As Kugler's study shows, Auto Layout should be fast enough. Don't forget, frames or Auto Layout, it all comes down to math calculations, something modern CPUs are pretty good at.

In your case, I would recommend quite a different approach. For a start, check that you are manipulating constraints correctly, and in the right place. That means updateConstraints and updatedViewConstraints. Adding or removing constraints is an expensive operation. But really, you should only be doing it once - via those methods - on view creation. Don't forget to check that the constraints have already been created so that you don't get exceptions by adding repeatedly.

Also, remember, you don't need to add or remove constraints if you are just updating a constant. Something you can do outside of those aforementioned methods.

Next, consider what's happening with the table view. It's scrolling fast and cellForRowAtIndexPath is asking for the next cell. In your case, the cells all look pretty different. To solve that, use a different reuseIdentifier for each variation.

As long as your data operation to populate the cell is minimal, you might see a tiny shudder on initial cell creation. However, thereafter the scrolling should be very smooth.

Answer 2

From my understanding, in my case, auto-layout should be slower than fixed frame

Auto Layout is almost always slower. But in most situations the difference between using Auto Layout and fixed layout shouldn't be noticeable.

If you have only five different genres, it's fine to use different unique cell reuse identifiers for each genre/layout. It'll remove the need of adding/removing constraints after every dequeue operation. See this great answer for more information: https://stackoverflow.com/a/18746930/1990236