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