Wednesday, April 24, 2013 [Tweets] [Favorites]

Auto Layout Performance on iOS

Florian Kugler:

For views where the amount of time it takes to create them is crucial (like the contents of table view & collection view cells, paging views, etc.) you have to keep the view hierarchy very simple and closely watch the performance impact of Auto Layout. In these cases it might be worthwhile to try disabling Auto Layout before you go straight to drawing everything manually with Core Graphics.

1 Comment

Sounds like slapdash system design and non-existent stress testing on Apple's part. (Why am I no longer surprised by this...)

Or maybe Apple are knowingly a technology they know is immature and incomplete, but not informing third-party devs that these are the current known limitations which will be addressed in a future release due to their pathological secrecy culture. (That wouldn't surprise me either.)

Yes, the iOS-based GUI needs to adapt to all sorts of different screen sizes and orientations, but it only needs to do that *once* for each device it is installed on. It's not like a WIMP-based web browser where the HTML layout engine must be able to recalculate on the fly every time the user resizes the window. Therefore, most or all of a given layout's positioning should only need calculated once - the first time it is used on a device - and that information cached for reuse all on subsequent runs.

Implement that caching, either as a third-party extension or, ideally, within the AutoLayout framework itself, and it doesn't matter how long it takes to calculate a layout (as long as it isn't wholly intolerable). Trying to reduce the calculation time itself is totally the wrong approach: a classic case of premature optimization.

Implement a caching mechanism first, re-profile the app in real-world use, and don't even worry about initial calculation speed unless the *total* user experience is still unacceptably degraded. And even if it is, it may be that other approaches will address the user experience far more easily than painfully trying to scrape an occasional LOG N off an inevitably O(N*N*...) algorithm. (e.g. Pre-calculate layouts on a background thread before they are first requested. Or just calculate some reasonable presets and/or hinting for all current screen sizes during the development phase and include those tables in the app bundle as a starting point.)

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment