Memory Management in Android
Memory Management in Android
All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation. The Dalvik VM executes Dalvik executable files, a format optimized to ensure minimal memory foot- print. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK. Understanding Application Priority and Process States The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An applications priority is equal to its highest-priority component. Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports. All Android applications will remain running and in memory until the system needs its resources for other applications.
Its important to structure your application correctly to ensure that its priority is appropriate for the work its doing. If you dont, your application could be killed while its in the middle of something important. The following list details each of the application states shown in Figure , explaining how the state is determined by the application components comprising it: Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort. Active processes include:
Activities in an active state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter. Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
A7, Stephanos Tower, Eachamukku, Kakkanadu,Kochi
Visible Processes Visible, but inactive processes are those hosting visible Activities. As the name suggests, visible Activities are visible, but they arent in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and theyll only be killed in extreme circumstances to allow active processes to continue. Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services dont interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and wont be killed unless resources are needed for active or visible processes. Background Processes Processes hosting Activities that arent visible and that dont have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pat- tern to obtain resources for foreground processes. Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when theyre re-launched. These processes are rou- tinely killed as required.