Auto Layout Performance on iOS(floriankugler.com)
floriankugler.com
Auto Layout Performance on iOS
http://floriankugler.com/blog/2013/4/21/auto-layout-performance-on-ios
5 comments
I don't know much about how autolayout works, but wouldn't it be possible to solve some of the constraints at compile time? e.g when you compile your app for iphone it could try and solve as much as possible considering the known screen size, etc..
The idea is that it accounts for variations in things like string length for labels, image sizes and proportions -- things not always known at compile time.
But, for layouts where that's not the case, a compile time constraint builder would indeed be nice.
But, for layouts where that's not the case, a compile time constraint builder would indeed be nice.
Practicing latency hiding techniques might be useful here. Try grabbing a first generation iPhone and scroll really fast in Safari, for example — you’ll see a checker grid underneath the actual content. iOS interaction emphasizes movement and fluidity over visual clarity or pixel perfectness; while it is actually acceptable to drop granularity it is usually frowned upon to drop frames. Our Choice (the famous Al Gore book on iOS by Push Pop Press) does the same thing. iBooks does the same thing (PDF only; its ePUB part just chokes). Even GoodReader does the same thing.
Several general strategies off the back of my hand: a) precompute images in the background, store and decode the important bits on the fly; b) use proxy images unless the card is visible; c) a combination of both. Sounds like a fun problem (for solving it the first time).
On layout — Autolayout is slow, period. On a collection view with square cells of identical sizes, autolayout takes over five seconds to make up its mind. (This is from a random iPhone 4S.) If your design is not super flexible, it might make sense to set up a few styles up front and reuse them again and again. Even drawing unstyled text into framebuffers is heavy if you do it often on dynamically generated content. (For example, 72 small labels for a scrolling date picker chokes at <30FPS.) Sometimes it’s better to design the issue away. Even a well-written piece of software may look awkward and work clumsily when it resizes during rotation while a square thing will generally work. The last ditch is to crossfade, but I digress.
The last thing I think is very relevant: layout taking a long time is actually also not a big deal if you only do the initial layout for two or three views you end up reusing. Small, frequent memory allocation (and drawing) during human interaction kills the joy. Hopefully, if you’re using an UIPageViewController, you’re also reusing the view controllers and its views.
Side note: I have not seen a great way to cancel work halfway done or is no longer necessary on iOS at the library / framework level. NSOperation has cancellation support which is basically twiddling glorified (hopefully) thread-safe boolean flags that get checked periodically. Sometimes people decide to throw the results away in the completion handler.
Several general strategies off the back of my hand: a) precompute images in the background, store and decode the important bits on the fly; b) use proxy images unless the card is visible; c) a combination of both. Sounds like a fun problem (for solving it the first time).
On layout — Autolayout is slow, period. On a collection view with square cells of identical sizes, autolayout takes over five seconds to make up its mind. (This is from a random iPhone 4S.) If your design is not super flexible, it might make sense to set up a few styles up front and reuse them again and again. Even drawing unstyled text into framebuffers is heavy if you do it often on dynamically generated content. (For example, 72 small labels for a scrolling date picker chokes at <30FPS.) Sometimes it’s better to design the issue away. Even a well-written piece of software may look awkward and work clumsily when it resizes during rotation while a square thing will generally work. The last ditch is to crossfade, but I digress.
The last thing I think is very relevant: layout taking a long time is actually also not a big deal if you only do the initial layout for two or three views you end up reusing. Small, frequent memory allocation (and drawing) during human interaction kills the joy. Hopefully, if you’re using an UIPageViewController, you’re also reusing the view controllers and its views.
Side note: I have not seen a great way to cancel work halfway done or is no longer necessary on iOS at the library / framework level. NSOperation has cancellation support which is basically twiddling glorified (hopefully) thread-safe boolean flags that get checked periodically. Sometimes people decide to throw the results away in the completion handler.
More or less what I expected -- I thought it was common knowledge that anything code-related with "auto" in it is going to have some significant overhead, as you can pretty much guarantee that there is a ton of looping going on.
Those look like parabolas, which implies that there's something O(n^2) going on. Since autolayout has to evaluate each constraint against the other constraints, this shouldn't be too surprising.
Like other commenters, I find the 1,000 subview test runs pretty silly. (Pro tip: if you need to put thousands of things on the screen, you don't want to give each one its own view. They aren't that light no matter how you lay them out).
This stuff is pretty clearly optimized for use with a handful to a few dozen views. It would be great to see a performance comparison for that range.
Like other commenters, I find the 1,000 subview test runs pretty silly. (Pro tip: if you need to put thousands of things on the screen, you don't want to give each one its own view. They aren't that light no matter how you lay them out).
This stuff is pretty clearly optimized for use with a handful to a few dozen views. It would be great to see a performance comparison for that range.
I've found auto-layout to be less than useful much of the time, often you are left with puzzlement as to what's wrong, leading to turning it off and doing something else.
We are given no info about what constraints were used and whether the view was created in code or IB. For all we know, maybe all they needed was an extra constraint or two they to speed things up. Diving into how changing individual constraints affects overall performance would be interesting. It would be nice if Instruments had a template for inspecting autolayout performance (or does it? I haven't looked and not by my desktop).
Also, the numbers without autolayout still aren't great (hopefully that was tested on low end hardware?). I wonder why the OP didn't just pre-render the next view in the background, since he has the luxury of knowing that users will page through views in a linear fashion.