1page.title=Processes and Application Life Cycle 2@jd:body 3 4<p>In most cases, every Android application runs in its own Linux process. 5This process is created for the application when some of its code needs to 6be run, and will remain running until it is no longer needed <em>and</em> 7the system needs to reclaim its memory for use by other applications.</p> 8 9<p>An unusual and fundamental feature of Android is that an application process's 10lifetime is <em>not</em> directly controlled by the application itself. 11Instead, it is determined by the system through a combination of the parts of the application 12that the system knows are running, how important these things are to the user, 13and how much overall memory is available in the system.</p> 14 15<p>It is important that 16application developers understand how different application components 17(in particular {@link android.app.Activity}, {@link android.app.Service}, 18and {@link android.content.BroadcastReceiver}) impact the lifetime 19of the application's process. <strong>Not using these components correctly can 20result in the system killing the application's process while it is doing 21important work.</strong></p> 22 23<p>A common example of a process life-cycle bug is a 24{@link android.content.BroadcastReceiver} that starts a thread when it 25receives an Intent in its {@link android.content.BroadcastReceiver#onReceive 26BroadcastReceiver.onReceive()} 27method, and then returns from the function. Once it returns, the system 28considers the BroadcastReceiver to be no longer active, and thus, its hosting 29process no longer needed (unless other application components are active in 30it). So, the system may kill the process at any time to reclaim memory, and in doing so, 31it terminates the spawned thread running in the process. The solution to this problem 32is to start a {@link android.app.Service} from the BroadcastReceiver, so the 33system knows that there is still active work being done in the process.</p> 34 35<p>To determine which processes should be killed when low on memory, Android 36places each process into an "importance hierarchy" based on the components running in 37them and the state of those components. These process types are (in order of importance):</p> 38 39<ol> 40 41<li>A <strong>foreground process</strong> is one that is required for 42what the user is currently doing. Various application components can 43cause its containing process to be considered foreground in different 44ways. A process is considered to be in the foreground if any of the 45following conditions hold: 46 <ul> 47 <li> It is running an {@link android.app.Activity} 48 at the top of the screen that the user is interacting with (its 49 {@link android.app.Activity#onResume} method has been called).</li> 50 <li> It has a {@link android.content.BroadcastReceiver} that is currently running 51 (its {@link android.content.BroadcastReceiver#onReceive 52 BroadcastReceiver.onReceive()} method is executing).</li> 53 <li>It has a {@link android.app.Service} that is currently executing code 54 in one of its callbacks ({@link android.app.Service#onCreate Service.onCreate()}, 55 {@link android.app.Service#onStart Service.onStart()}, or 56 {@link android.app.Service#onDestroy Service.onDestroy()}).</li> 57 </ul> 58</li> 59<p>There will only ever be a few such processes in the system, and these will only 60be killed as a last resort if memory is so low that not even these processes 61can continue to run. Generally, at this point, the device has 62reached a memory paging state, so this action is required in order to keep the user 63interface responsive.</p> 64</li> 65 66<li>A <strong>visible process</strong> is one holding an {@link android.app.Activity} 67that is visible to the user on-screen but not in the foreground (its 68{@link android.app.Activity#onPause} method has been called). This may 69occur, for example, if the foreground Activity is displayed as a dialog 70that allows the previous Activity to be seen behind it. Such a 71process is considered extremely important and will not be killed unless doing so is 72required to keep all foreground processes running. 73</li> 74 75<li>A <strong>service process</strong> is one holding a {@link android.app.Service} 76that has been started with the 77{@link android.content.Context#startService startService()} method. Though these 78processes are not directly visible to the user, they are generally doing things 79that the user cares about (such as background mp3 playback or background 80network data upload or download), so the system will always keep such processes 81running unless there is not enough memory to retain all foreground and visible process. 82</li> 83 84<li>A <strong>background process</strong> is one holding an {@link android.app.Activity} 85that is not currently visible to the user (its 86{@link android.app.Activity#onStop} method has been called). These processes 87have no direct impact on the user experience. Provided they implement 88their Activity life-cycle correctly 89(see {@link android.app.Activity} for more details), the system 90can kill such processes at any time to reclaim memory for one of the three 91previous processes types. Usually there are many of these processes running, 92so they are kept in an LRU list to ensure the process that was most recently seen 93by the user is the last to be killed when running low on memory. 94</li> 95 96<li>An <strong>empty process</strong> is one that doesn't hold any active application 97components. The only reason to keep such a process around is as a cache to 98improve startup time the next time a component of its application needs to 99run. As such, the system will often kill these processes in order to 100balance overall system resources between these empty cached processes and the 101underlying kernel caches. 102</li> 103 104</ol> 105 106<p>When deciding how to classify a process, the system will base its decision on the most 107important level found among all the components currently active in the process. 108See the {@link android.app.Activity}, {@link android.app.Service}, and 109{@link android.content.BroadcastReceiver} documentation for more detail on how 110each of these components contribute to the overall life-cycle of a process. 111The documentation for each of these classes describes in more detail how 112they impact the overall life-cycle of their application.</p> 113 114<p>A process's priority may also be increased based on other dependencies 115a process has to it. For example, if process A has bound to a 116{@link android.app.Service} with 117the {@link android.content.Context#BIND_AUTO_CREATE Context.BIND_AUTO_CREATE} 118flag or is using a 119{@link android.content.ContentProvider} in process B, then process B's 120classification will always be at least as important as process A's.</p> 121