[javert]

has nothing to do with threading, and certainly has nothing to do with "real-time priority"

Well, it has everything to do with real-time priority, because in the case of Android, there is a clear priority inversion. That is, what should be considered the highest-priority work IMHO (updating the UI) is being delayed for other lower-priority work.

Absent other factors, the technically correct way of dealing with this kind of problem is using multiple threads and assigning the right OS priorities to them.

Maybe there are other constraints in iOS development that are causing the devs to wrestle with the main event loop instead.

[saurik]

Yet on iOS, if you do silly work in the main/UI thread (which is very easy to do, as that really is your main thread on which you handle all events, and is thereby something many/most applications you find actually do quite often), it will block all UI updates for that process; claiming that iOS is solving UI lag by having a dedicated UI thread that is marked "real-time priority" is, AFAIK, wrong.

In fact, it is this very property (that on iOS, all UI work must be done from the main thread) that often /causes/ UI lag, and yet somehow Android (where even this author admits using background threads for non-UI work "is the standard Android design pattern" in one of the comments on his post) is the one with the serious UI lag issues <- this mental contradiction is the key problem, and it would be awesome if someone (from Google or wherever) provides a strong explanation.

[conr]

iOS has the advantage that all apps go through an approval process. If someone is doing lots of work on the main thread and blocking the UI, the reviewer can catch it and suggest to the developer to make their code suck less.

[hack_edu]

Do people actually get any feedback like this?

[msh]

Yes, i had an app that in one place didn't asynch a webrequest and locked up the main thread. They emailed me about this.

[campnic]

If we are going to give an advantage I think it would go to Android if thats the only way you get feedback on iOS. Android pops up an Application Not Responsive message if your main thread violates responsiveness thresholds. This is a meta issue to mechanisms for debugging main thread vs. side thread coding.

[JoeAltmaier]

Agreed, sort of. The problem is, the wrong problem is addressed by operating systems.

What you may mean by "the highest-priority work (updating the UI)" is really "the lowest-latency work". What we perceive as UI quality is the latency of sucessive events - is it smooth, and fast.

But OSs only give us a big hammer to manage this - priority of threads. Which is very indirectly related to latency. E.g. priority inversion, blocking i/o, the stupid habit of putting OS threads strictly ahead of user threads, and on and on, all impact latency in a way the programmer cannot constrain.

Experimental OSs have tried to use latency as the fundnamental scheduling metric. But each time a new mainstream OS is released, lo and behold it's based on stupid old priority.

So let's acknowledge the fundamental fact, that we're not being given the tools to achieve what we need, and everything we do is a workaround that's more or less successful. It all glitches under the right (wrong) conditions, all approaches are hacks of one sort or another.

[mikeash]

It can't have anything to do with real-time priority, as iOS does not have any special priority for the main (UI) thread.