Unlike most traditional environments, Android applications have no control over their own life cycles.Instead, application components must listen for changes in the application state and react accordingly,taking particular care to be prepared for untimely termination.
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s 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.
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.
- Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
- Services that are executing an onStart, onCreate, or onDestroy event handler.
-Visible Processes: Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t 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 they’ll 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 don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
- Background Processes: Processes hosting Activities that aren’t visible and that don’t 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 pattern 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 they’re re-launched. These processes are routinely killed as required.
- onCreate Called when the application is created. Override this method to initialize your application singleton and create and initialize any application state variables or shared resources.
- onTerminate: Can be called when the application object is terminated. Note that there is no guarantee of this method handler’s being called. If the application is terminated by the kernel in order to free resources for other applications, the process will be terminated without warning and without a call to the application object’s onTerminate handler.
- onLowMemory: Provides an opportunity for well-behaved applications to free additional memory when the system is running low on resources. This will generally only be called when background processes have already been terminated and the current foreground applications are still low on memory. Override this handler to clear caches or release unnecessary resources.
- onConfigurationChanged: Unlike with Activities, your application object is not killed and restarted for configuration changes. Override this handler if it is necessary to handle configuration changes at an application level.
The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s 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.
Active processes include:
- Activities in an “active” state; that is, they are in the foreground and responding to user events.
- Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
- Services that are executing an onStart, onCreate, or onDestroy event handler.
-Visible Processes: Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t 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 they’ll 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 don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
- Background Processes: Processes hosting Activities that aren’t visible and that don’t 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 pattern 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 they’re re-launched. These processes are routinely killed as required.
------------------------------------------------------------------------------------------------
The Application class also provides event handlers for application creation and termination, low available memory, and configuration changes. By overriding these methods you can implement your own application-specific behavior for each of these circumstances:- onCreate Called when the application is created. Override this method to initialize your application singleton and create and initialize any application state variables or shared resources.
- onTerminate: Can be called when the application object is terminated. Note that there is no guarantee of this method handler’s being called. If the application is terminated by the kernel in order to free resources for other applications, the process will be terminated without warning and without a call to the application object’s onTerminate handler.
- onLowMemory: Provides an opportunity for well-behaved applications to free additional memory when the system is running low on resources. This will generally only be called when background processes have already been terminated and the current foreground applications are still low on memory. Override this handler to clear caches or release unnecessary resources.
- onConfigurationChanged: Unlike with Activities, your application object is not killed and restarted for configuration changes. Override this handler if it is necessary to handle configuration changes at an application level.
No comments:
Post a Comment