Splitting up the work for the UI thread
Posted by Dion Almaer 11 months ago on performance responsiveness ui
“Don’t do CPU intensive work on the main thread!”
The age old advise. If you want a responsive application you can’t tie up the main UI thread. This is why we got Workers in the world of the Web.
The inner workings of such architectures are incredibly important. One of the features of iOS is how well their world is architected. Views backed by the GPU and all that. The system + a ton of hard work has resulted in a very responsive experience (not that you can’t screw it up).
This reminds me of a series of threads on iOS vs. Android, where a lot of misinformation was thrown around.
Bob Lee (CTO of Square and awesomely Crazy) had a nice follow up, in which he did talk about some core differences:
As for the differences, iOS’s Core Animation framework tweens animations in a background thread while Android does the same in the main thread. On iOS animations continue running, even when the application accidentally blocks the main thread. In addition, when scrolling, iOS’s main thread goes into a “tracking” mode where it filters out certain types of events that might result in redrawing or other performance degradations. This has no affect on background operations. Nothing technically prevents Android from supporting these features, but their absence doesn’t preclude smooth UIs on Android either. Hardware acceleration is far more important.
Back to the Web, Benoit Girard talks about off main thread composition in Fennec (and Firefox in general) and the advantages of chopping up the work. I believe that the end of this work will be less times that some bad JS results in lost frames and the like. Great to see, and fun to revisit the topic.