[saurik]

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" <- AFAIK this is simply wrong: the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one. The reason things block is because of the way the event loop on that thread is managed (and in fact is directly caused by all of that activity operating on the main thread, which we even often call the "UI thread"), and has nothing to do with threading, and certainly has nothing to do with "real-time priority".

"""On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. The update of the display for the installation progress might (...might) stop, as that's happening in the UI (aka, "main") thread of SpringBoard (and the event loop management might ignore incoming events that are not related to the touch event until after the gesture completes), but the installation itself is being managed by a background daemon (installd) and will not stop because someone is touching the screen. The operating system is /not/ doing something hilariously insane here, throwing out all computation on the device because someone is accidentally touching it.

[martingordon]

He seems like a smart kid, but he's clearly not developed anything on iOS. One of the key things you learn as you're learning how to build an iOS app is that all UI code must be run on the main thread. It even says so right there in the [UIView class reference](http://developer.apple.com/library/ios/#documentation/uikit/...):

> Threading Considerations Manipulations to your application’s user interface must occur on the main thread. Thus, you should always call the methods of the UIView class from code running in the main thread of your application. The only time this may not be strictly necessary is when creating the view object itself but all other manipulations should occur on the main thread.

[buymorechuck]

On iOS, updates to the UI happen on the main thread, but all animation, surface compositing, and rendered graphics run on the dedicated Core Animation rendering thread.

[saurik]

The user complaints are with regards to delays in event processing ("sloppy" or "laggy" touch events), not general animation that does not involve user input; the specific examples in this article demonstrating how this "dedicated" UI thread with "real-time priority" exists detail touching the screen and watching the system lock up as it is now busy handling the scroll events.

Also, it is my understanding that surface compositing is done in hardware using surface-backed textures, with any software rendering of those surfaces being done on the main UI thread while responding to messages such as drawRect, using CoreGraphics (not CoreAnimation). The only thing that gets shoved to background threads are, AFAIK, animations that are specified in code but then "set free" into the CoreAnimation backend.

I thereby don't feel like these comments adequately defend the statements made in the article: the things it claims are benefits of iOS's graphics architecture either A) work the same on Android (per the post it is responding to from the Android developer regarding the myths of Android hardware surface compositing) or B) actually happen in software on the main/UI thread on iOS. I think we need to look elsewhere for the real cause of Android's horrible touch response. ;(

[dlikhten]

"The user complaints are with regards to delays in event processing ("sloppy" or "laggy" touch events), not general animation that does not involve user input;"

Obviously you never went through tunnels. When I am playing a 100% offline game (without internet access) and my bus goes in the tunnel, everything stops. Who cares about this "game" when I have tons of networking to do. Networking takes precedence over animation so what happens is any touch events or animation or anything is heavily delayed.

What about the phone? When the call is ending, it can't render a UI update that the button was touched, thus just a delay. It even delays processing the next input event until after the screen switches states. End result? I make a call when I try to hang up or vice versa. Point being that these problems are not exclusive, but the iOS solution is significantly better for these edge cases which are the ones that cause the biggest headaches, they still happen in iOS but very infrequently vs consistently bad every other time.

[freemarketteddy]

I think one subtle difference is that in iOS there is some degree of parallelism even in the UI Updates as they happen in the NSRunLoop of the main thread(main NSRunLoop).

So that an UI Update that is waiting for hardware can be delayed and the next UI update in the loop can be processed.

I dont seem to recall any such pattern for Java main thread UI Updates.

[saurik]

An NSRunLoop is normally a CFRunLoop, and a CFRunLoop is pretty much just "get next task; run that task; loop": if one task blocks, it cannot run the next one; the only way for it to look like it is doing multiple things at once is for code to reenter the runloop using CFRunLoopRun(), which is hardly ever used (it increases the size of the stack pretty quickly and breaks assumptions about single-threaded concurrency). Any concurrency with hardware compositing is going to happen at the kernel or hardware levels, not in the app.

[hedgehog]

You're right in general but starting in iOS4:

"Drawing to a graphics context in UIKit is now thread-safe." http://developer.apple.com/library/ios/#releasenotes/General...

Some things won't work (notably UIWebView which also gets used in UITextView) but you actually can build a view in a NSOperation.

[beatle]

Here's another problem with HeapWorker.c (The android code that does garbage collection, etc.). This is just poor programming imo. Android's thread management is stuck in the 90s. With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector, not to mention the possibility of bugs and deadlocks. (see actual android code below). iOS has been migrating away from threads and using dispatch and operation queues (Grand Central Dispatch) instead, which eliminates most of the blocking and possibilities for deadlocks. sometimes performance issues are just results of poor programming.

dvmLockMutex(&gDvm.heapWorkerLock);

//BUG: If a GC happens in here or in the new thread while we hold the lock,

// the GC will deadlock when trying to acquire heapWorkerLock.

if (!dvmCreateInternalThread(&gDvm.heapWorkerHandle, "HeapWorker", heapWorkerThreadStart, NULL))

{ dvmUnlockMutex(&gDvm.heapWorkerLock);

        return false;
    

}

// Block until all pending heap worker work has finished.

void dvmWaitForHeapWorkerIdle() { int cc;

    assert(gDvm.heapWorkerReady);

    dvmChangeStatus(NULL, THREAD_VMWAIT);

    dvmLockMutex(&gDvm.heapWorkerLock);

    /* Wake up the heap worker and wait for it to finish. */
    //TODO(http://b/issue?id=699704): This will deadlock if
    //     called from finalize(), enqueue(), or clear().  We
    //     need to detect when this is called from the HeapWorker
    //     context and just give up.
    dvmSignalHeapWorker(false);
    cc = pthread_cond_wait(&gDvm.heapWorkerIdleCond, &gDvm.heapWorkerLock);
    assert(cc == 0);

    dvmUnlockMutex(&gDvm.heapWorkerLock);

    dvmChangeStatus(NULL, THREAD_RUNNING);

}

[blinkingled]

With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector

Android runs on Linux. Linux uses Futexes (Fast Userspace Mutexes) for locking abstractions like semaphores and mutexes. From Wikipedia -

"A futex consists of a kernelspace wait queue that is attached to an aligned integer in userspace. Multiple processes or threads operate on the integer entirely in user space (using atomic operations to avoid interfering with one another), and only resort to relatively expensive system calls to request operations on the wait queue (for example to wake up waiting processes, or to put the current process on the wait queue). A properly programmed futex-based lock will not use system calls except when the lock is contended; since most operations do not require arbitration between processes, this will not happen in most cases."

[beatle]

Android's garbage collection is handled by Dalvik.

[blinkingled]

Huh?

thread management they're required to trap into the kernel to acquire a mutex.

Of course GC is handled by the VM. That's not the point here though - the point I thought you made was that the GC uses mutexes and they're required to trap into the kernel. (At least that's how it reads above) That's not the case on Linux. GC uses mutexes which are implemented as futexes[1] that stay in user space for most of the time.

[1] http://www.mail-archive.com/[e-mail]/msg02787.html

[eridius]

Agreed. The writer here doesn't seem to know what he's talking about. The reason things like WebKit tiles and images in tables don't populate while you're actively scrolling is because of an intentional choice on the part of the programmer. When you're touching the screen the run loop is put into a different mode than the default, and authors tend to write code such that expensive operations (like populating thumbnails in a table) simply don't occur unless the run loop is in the default mode. In fact, a naïve implementation of a tableview with thumbnails will populate those thumbnails as you scroll, and this has a noticeable effect on frame rates.

[podperson]

Right -- the first thing I did after reading a few paragraphs was load a complex web page and try scrolling it -- it continues to render just fine (on a single core iPhone 4). I've got a very old iPod Touch which does seem to lock up page draw when I scroll.

I think that the simple answer is that there's no simple answer -- which is what the earlier post was pretty much saying.

[seanp2k2]

There is a simple answer, but it's not one that most people who are in a position to fix it will like; "it sucks now and I couldn't care less why. Fix it ASAP because it's killing your UX"

And as far as the author of this article goes…maybe he is off on the technical stuff, but he understands the most important, which is that UX is broken in Android for this, among a few other reasons.

Someone open a big report against AOSP? All versions, high priority; "UI Anmations Broken"

[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.

[Groxx]

On the second point, you're correct for 5.0 at the very least - I just tried it. Touching and even actively panning back and forth (never releasing) doesn't even pause the loading-bar updating, and I even discovered badges update during this as well.

For 4.x, if I remember correctly, it would pause the rendering. But I experimented a little then too, and it didn't pause the install at all - it'd just jump when you released.

[waqf]

I'm totally confused. When you say "the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one" are you talking about iOS or Android? I can't make sense of your post either way.

[wooster]

saurik is talking about iOS.

[illumin8]

+1 I think this Saurik guy knows what he's talking about... Now where have I heard that name before? (hint his software runs on over 2 million devices)