So far, we have been treating our activity like it is our entire application. Soon, we will start to get into more complex scenarios, involving multiple activities and other types of components, like services and content providers.
But, before we get into a lot of that, it is useful to understand how all of this ties into the actual OS itself. Android is based on Linux, and Linux applications run in OS processes. Understanding a bit about how Android and Linux processes inter-relate will be useful in understanding how our mixed bag of components work within these processes.
A user installs your app, goes to their home screen’s launcher, and taps on an icon representing your activity. Your activity dutifully appears on the screen.
Behind the scenes, what happened is that Android forked a copy of a process
known as the zygote. As a result of the way your process is forked
from the zygote, your process contains:
Activity and Button,
also shared via copy-on-write memoryActivity subclassSuppose that you have an app with just one activity. From the home screen’s launcher, the user taps on the icon associated with your app’s activity. Then, with your activity in the foreground, the user presses BACK.
At this point, the user is telling the OS that she is done with your activity. Control will return to whatever preceded that activity — in this case, the home screen’s launcher.
You might think that this would cause your process to be terminated. After all, that is how most desktop operating systems work. Once the user closes the last window of the application, the process hosting that application is terminated.
However, that is not how Android works. Android will keep your process around, for a little while at least. This is done for speed and power: if the user happens to want to return to your app sooner rather than later, it is more efficient to simply bring up another copy of your activity again in the existing process than it is to go set up a completely new copy of the process. This does not mean that your process will live forever; we will discuss when your process will go away later in this chapter.
Now, instead of the user pressing BACK, let’s say that the user pressed HOME instead. Visually, there is little difference: the home screen re-appears. Depending on the home screen implementation there may be a visible difference, as BACK might return to a launcher whereas HOME might return to something else on the home screen. However, in general, they feel like very similar operations.
The difference is what happens to your activity.
When the user presses BACK, your foreground activity is destroyed. We will
get into more of what that means in the next chapter. However, the key feature
is that the activity itself — the instance of your subclass of Activity –
will never be used again, and hopefully is garbage collected.
When the user presses HOME, your foreground activity is not destroyed… at least, not immediately. It remains in memory. If the user launches your app again from the home screen launcher, and if your process is still around, Android will simply bring your existing activity instance back to the foreground, rather than having to create a brand-new one (as is the case if the user pressed BACK and destroyed your activity).
What HOME literally is doing is bringing the home screen activity back to the foreground, not otherwise directly affecting your process much.
Processes cannot live forever. They take up a chunk of RAM, for your classes and objects, and these mobile devices only have so much RAM to work with. Eventually, therefore, Android has to get rid of your process, to free up memory for other applications.
How long your process will stick around depends on a variety of factors, including:
Going back to the scenario from above, we have an application with a single activity launched from the home screen, where the user can return to the home screen either by pressing BACK or by pressing HOME. You might think that this makes no difference at all on when the process would be terminated, but that would be incorrect. Pressing HOME would keep the process around perhaps a bit longer than would pressing BACK.
Why?
When the user presses BACK, your one and only activity is destroyed. When the user presses HOME, your activity is not destroyed. Android will tend to keep processes around longer if they have active (i.e., not destroyed) components in them.
The key word there is “tend”. Android’s algorithms for determining when to get rid of what processes are baked into the OS and are, at best, lightly documented. There is evidence to suggest that other criteria, such as process age, are also taken into account, and so there may be times when a process that has an activity running (but not in the foreground) might be terminated where a process with no running activity might not. However, in general, processes with active (not destroyed) components will stick around a bit longer than processes without such components.
Just because Android terminates processes to free up memory does not mean that it will terminate just any process to free up memory. A foreground process – the most common of which is a process that has an activity in the foreground – is the least likely of all to be terminated. In fact, you can pretty much assume that if Android has to kill off the foreground process, that the phone is very sick and will crash in a matter of moments.
(and, fortunately, that does not happen very often)
So, if you are in the foreground, you are safe. It is only when you are not in the foreground that you are at risk of having the process be terminated.
Processes take up RAM. A significant chunk of that RAM represents the objects you create (a.k.a., “the heap”).
Those of you with significant Java backgrounds know that the Java VM loves RAM
(“can’t get enough of it!”). Java VMs routinely grab 64MB or 128MB of heap
space upon creating the process and will grow as big as you wish to let them
(e.g., -Xmx switch to the java command).
Android heap sizes are not that big, because Android is designed to run on mobile devices with constrained amounts of RAM.
Your heap limit may be as low as 16MB, though values in the 32-48MB range are more typical with current-generation devices. How much the heap limit will be depends a bit on what version of Android is on the device. It depends quite a lot, though, on the screen size, as bigger screens will tend to want to display bigger bitmap images, and bitmap images can consume quite a bit of RAM.
The key is that the heap is small, and (generally speaking) you cannot adjust it yourself. It is what it is. Small applications will rarely run into a problem with heap space, but larger applications might. We will discuss tools and techniques for measuring and coping with memory problems later in this book.