480 CHAPTER 13: Android Service Class and Threads: Background Processing
used by your process is required by other processes that have a higher priority level or are receiving
more usage (attention) from the end-user.
Application components running inside of a process that gets terminated by the Android OS are
subsequently destroyed and are removed from memory. Not to worry, as any of these processes
can be restarted again, at a later time, for any of those application components that still require
something be accomplished for or by a user. In fact, that is exactly why that savedInstanceState
Bundle object that you are now familiar with is always utilized!
When deciding which processes to kill, the Android system weighs their relative importance to the
user. For example, it more readily shuts down processes that are hosting Activity subclasses that are
no longer visible on screen, compared to a process hosting a visible Activity that is being used. The
decision as to whether to terminate a process, therefore, depends on the state of the components
running in that process. Since the rules Android uses to decide which processes to terminate are
important to understand, you will read about them next.
The Process Lifecycle: Keeping a Process Alive
The Android OS will try to keep your application process in its system memory for as long as it can.
However, it sometimes will need to destroy the older processes running in the OS. This is done in
order to reclaim the system’s memory resources for newer or higher priority processes. After all, so
many Android devices ship with only one or at most two gigabytes of main system memory; this
system memory can fill up fairly quickly, as users play games, launch apps, read eBooks, stream
music, and place phone calls as the day goes on.
Even when devices start to ship with three gigabytes of main memory, you will still have memory
management issues, and using processes and threads provide the tools for optimizing these
memory management issues, so it is important that you understand how processes are handled in
the Android OS. In case you are wondering, four megabytes of memory space in an Android device
is out of the question, until Android releases the 64-bit version of its Android 5 OS, based on 64-bit
Linux and 64-bit Java 7. This is because a 32-bit OS will only address 3.24MB of system memory.
The way that the Android OS determines which of its processes to keep and which of its processes
to terminate is via a priority hierarchy. Android will place each running process into this priority
hierarchy, which is based on each of the components running in the process queue, as well as the
current status (running, idle, or stopped) of those application components. The way that Android
removes processes from the process priority hierarchy, which is ultimately how memory is cleared and
reallocated for the Android device, is that the process with the lowest priority (or least importance) is
terminated first. Then the next lowest priority process is terminated, then the next lowest, until system
resources that are needed for a higher priority process have been recovered for use.
There are five process priority levels within this priority hierarchy. Once you know what these are,
you will see how practical the process priority hierarchy is, and you will also have a good overview
of how Service subclasses (asynchronous background processing) or Activity subclasses (user
interfaces) fit into a process priority schema, which is very important to understand as an Android
developer, even if you don’t implement custom processes. The five process priority levels are
summarized in Table 13-1 for your quick reference.