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(activities, services, content providers, etc) work within these processes.
When Processes Are Created
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:
- A copy of the VM (Dalvik or ART), shared among all such processes via Linux copy-on-write memory sharing
- A copy of the Android framework classes, like Activity and Button, also shared via copy-on-write memory
- A copy of your own classes, loaded out of your APK
- Any objects created by you or the framework classes, such as the instance of your Activity subclass
BACK, HOME, and Your Process
Suppose 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.
BACK – Foreground activity is destroyed. Control will return to whatever preceded.
Press BACK – 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 fork a completely new copy of the process. This does not mean that your process will live forever;
Press HOME – 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.
BACK vs HOME :
When the user presses BACK, your foreground activity is destroyed. The key 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).
Pressing HOME would keep the process around perhaps a bit longer than would pressing BACK.
When the user presses BACK, your one and only activity is destroyed. When the user presses HOME, your activity is not destroyed.
Android’s algorithms for determining when to get rid of what processes are baked into the OS. 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.
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.
Learn to code Android 