Each forked application process runs independently and is scheduled frequent, small amounts of CPU time by the operating system. This time-slicing approach means that even a single-processor device can appear to be actively working in more than one application at the same time, when in fact, each application is taking very short turns on the CPU.
Within a process, there may be many threads of execution. Each thread is a separate sequential flow of control within the overall program—it executes its instructions in order, one after the other. These threads are also allocated slices of CPU time by the operating system.
While the application process is started by the system and prevented from directly interfering with data in the memory address space of other processes, threads may be started by application code and can communicate and share data with other threads within the same process.
Within each DVM process, the system starts a number of threads to perform important duties such as garbage collection, but of particular importance to application developers is the single thread of execution known as the main or UI thread. By default, any code that we write in our applications will be executed by the main thread.
For example, when we write code in an onCreate method in the Activity class, it will be executed on the main thread. Likewise, when we attach listeners to user-interface components to handle taps and other user-input gestures, the listener callback executes on the main thread.
For apps that do little I/O or processing, this single thread model is fine. However, if we need to do CPU-intensive calculations, read or write files from permanent storage, or talk to a web service, any further events that arrive while we're doing this work will be blocked until we're finished.
As you can imagine, if the main thread is busy with a heavy calculation or reading data from a network socket, it cannot immediately respond to user input such as a tap or swipe.
An app that doesn't respond quickly to user interaction will feel unresponsive—anything more than a couple of hundred milliseconds delay is noticeable. This is such a pernicious problem that the Android platform protects users from applications that do too much on the main thread.
Android works hard to synchronize user interface redraws with the hardware refresh rate. This means that it aims to redraw at 60 frames per second—that's just 16.67 ms per frame. If we do work on the main thread that takes anywhere near 16 ms, we risk affecting the frame rate, resulting in jank—stuttering animations, jerky scrolling, and so on.
At API level 16, Android introduced a new entity, the Choreographer, to oversee timing issues. It will start issuing dropped-frame warnings in the log if you drop more than 30 consecutive frames.
Ideally, of course, we don't want to drop a single frame. Jank, unresponsiveness, and especially the ANR, offer a very poor user experience and translate into bad reviews and an unpopular application. A rule to live by when building Android applications is: do not block the main thread!
Further protection was added to the platform in Honeycomb (API level 11) with the introduction of a new Exception class, NetworkOnMainThreadException, a subclass of RuntimeException that is thrown if the system detects network activity initiated on the main thread.
Ideally then, we want to offload long-running operations from the main thread so that they can be handled in the background, and the main thread can continue to process user interface updates smoothly and respond in a timely fashion to user interaction.
For this to be useful, we must be able to coordinate work and safely pass data between cooperating threads—especially between background threads and the main thread.
We also want to execute many background tasks at the same time and take advantage of additional CPU cores to churn through heavy processing tasks quickly.
This simultaneous execution of separate code paths is known as concurrency.
The low-level constructs of concurrency in Android are those provided by the Java language: java.lang.Thread, java.lang.Runnable, and the synchronized and volatile keywords.
Higher-level mechanisms introduced to Java 5 in the java.util.concurrent package, such as Executors, atomic wrapper classes, locking constructs, and concurrent collections, are also available for use in Android applications.
We can start new threads of execution in our Android applications just as we would in any other Java application, and the operating system will schedule some CPU time for those threads.
To do some work off the main thread, we can simply create a new instance of java.lang.Thread, override its run() method with the code we want it to execute, and invoke its
start() method.
While starting new threads is easy, concurrency is actually a very difficult thing to do well. Concurrent software faces many issues that fall into the two broad categories: correctness (producing consistent and correct results) and liveness (making progress towards completion).
A common example of a correctness problem occurs when two threads need to modify the value of the same variable based on its current value. Let's imagine that we have an integer variable myInt with the current value of 2.
In order to increment myInt, we first need to read its current value and then add 1 to it. In a single threaded world, the two increments would happen in a strict sequence—we read the initial value 2, add 1 to it, set the new value back to the variable, then repeat the sequence. After the two increments, myInt holds the value 4.
In a multithreaded environment, we run into potential timing issues. It is possible that two threads trying to increment the variable would both read the same initial value (2), add 1 to it, and set the result (in both cases, 3) back to the variable.
Both threads have behaved correctly in their localized view of the world, but in terms of the overall program, we clearly have a correctness problem; 2 + 2 should not equal 3! This kind of timing issue is known as a race condition.
A common solution to correctness problems such as race conditions is mutual exclusion—preventing multiple threads from accessing certain resources at the same time. Typically, this is achieved by ensuring that threads acquire an exclusive lock before reading or updating shared data.
Liveness can be thought of as the ability of the application to do useful work and make progress towards goals. Liveness problems tend to be an unfortunate side effect of the solution to correctness problems. By locking access to data or system resources, it is possible to create bottlenecks where many threads are contending for access to a single lock, leading to potentially significant delays.
Worse, where multiple locks are used, it is possible to create a situation where no thread can make progress because each requires exclusive access to a lock that another thread currently owns—a situation known as a deadlock.
There are two additional problems facing developers of concurrent Android applications which are specific to Android.
Android applications are typically composed of one or more subclasses of android.app.Activity. An Activity instance has a very well-defined lifecycle that the system manages through the execution of lifecycle method callbacks, all of which are executed on the main thread.
An Activity instance that has been completed should be eligible for garbage collection, but background threads that refer to the Activity or part of its view hierarchy can prevent garbage collection and create a memory leak.
Similarly, it is easy to waste CPU cycles (and battery life) by continuing to do background work when the result can never be displayed because Activity has finished.
Finally, the Android platform is free at any time to kill processes that are not the user's current focus. This means that if we have long-running operations to complete, we need some way of letting the system know not to kill our process yet!
All of this complicates the do-not-block–the-main-thread rule because we need to worry about canceling background work in a timely fashion or decoupling it from the Activity lifecycle where appropriate.
The other Android-specific problem lies not in what you can do from the UI thread, but in what you cannot do:
This is because the user-interface toolkit is not thread-safe, that is, accessing it from multiple threads may cause correctness problems. In fact, the user-interface toolkit protects itself from potential problems by actively denying access to user-interface components from threads other than the one that originally created those components.
The final challenge then lies in safely synchronizing background threads with the main thread so that the main thread can update the user interface with the results of the background work.
The good news is that the Android platform provides specific constructs to address the general issues of concurrency, and to solve the specific problems presented by Android.
There are constructs that allow us to defer tasks to run later on the main thread, to communicate easily between cooperating threads, and to issue work to managed pools of worker threads and re-integrate the results.
There are solutions to the constraints of the Activity lifecycle both for medium-term operations that closely involve the user-interface and for longer-term work that must be completed even if the user leaves the application.
While some of these constructs were only introduced with newer releases of the Android platform, all are available through the support libraries and, with a few exceptions, the examples in this book target devices that run API level 7 (Android 2.1) and above.
The rest of this book discusses these Android-specific constructs and their usage and applications.