The Android operating system has, at its heart, a heavily modified Linux kernel designed to securely and efficiently run many process virtual machines on devices with relatively limited resources.
To build Android applications that run smoothly and responsively in these resource-constrained environments, we need to arm ourselves with an understanding of the options available, and how, when, and why to use them—this is the essence of this book.
However, before we do that, we'll briefly consider why we need to concern ourselves at all. We'll see how serious Google is about the efficiency of the platform, explore the Android process model and its implications for programmers and end users, and examine some of the measures that the Android team have put in place to protect users from apps that behave badly.
To conclude, we'll discuss the general approach used throughout the rest of the book to keep applications responsive using asynchronous programming and concurrency, and its associated challenges and benefits.
In this chapter, we will cover the following topics:
- Introducing the Dalvik Virtual Machine
- Memory sharing and the Zygote
- Understanding the Android thread model
- The main thread
- Unresponsive apps and the ANR dialog
- Maintaining responsiveness
- Concurrency in Android
Android applications are typically programmed using the Java language, but the virtual machines in the Android stack are not instances of the Java Virtual Machine (JVM). Instead, the Java source is compiled to Java byte-code and translated into a Dalvik executable file (DEX) for execution on a Dalvik Virtual Machine (DVM).
It is no accident that Google chose Java as the primary language, allowing a vast pool of developer talent to quickly get to work on building apps, but why not simply run Android applications directly on a JVM?
Dalvik was created specifically for Android, and as such, was designed to operate in environments where memory, processor, and electrical power are limited, for example, mobile devices. Satisfying these design constraints resulted in a very different virtual machine than the typical JVM's that we know from desktop and server environments.
Dalvik goes to great lengths to improve the efficiency of the JVM, involving a range of optimizations to simplify and speed up interpretation and reduce the memory footprint of a running program. The most fundamental difference between the two VM architectures is that the JVM is a stack-based machine, whereas the DVM is register-based.
A stack-based virtual machine must transfer data from registers to the operand stack before manipulating them. In contrast, a register-based VM operates by directly using virtual registers. This increases the relative size of instructions because they must specify which registers to use, but reduces the number of instructions that must be executed to achieve the same result.
Dalvik's creators claim that the net result is in Dalvik's favour and that the DVM is on average around 30 percent more efficient than the JVM. Clearly, Google has gone to great lengths to squeeze every last drop of performance out of each mobile device to help developers build responsive applications!
Another huge efficiency of the platform is brought about by the way in which a new DVM instance is created and managed.
A special process called the Zygote is launched when Android initially boots. The Zygote starts up a virtual machine, preloads the core libraries, and initializes various shared structures. It then waits for instructions by listening on a socket.
When a new Android application is launched, the Zygote receives a command to create a virtual machine to run the application on. It does this by forking its prewarmed VM process and creating a new child process that shares its memory with the parent, using a technique called Copy-On-Write. This has some fantastic benefits:
- First, the virtual machine and core libraries are already loaded into the memory. Not having to read this significant chunk of data to initialize the virtual machine drastically reduces the startup overhead.
- Second, the memory in which these core libraries and common structures reside is shared by the Zygote with all other applications, resulting in saving a lot of memory when the user is running multiple apps.