Android Lifecycle In-depth analysis (ii) _android

In Android, in most cases, each program runs in its own stand-alone Linux process. When a program or some part of it is requested, its process is "born", and the process is "dead" when the program does not need to run and the system needs to recycle the memory of the process for other programs. As can be seen, the lifecycle of the Android program is controlled by the system rather than by the program itself. This is different from the way we think when we write a desktop application, and a desktop application process is created when other processes or user requests are made, but often the process ends when the program itself receives a shutdown request and executes a specific action, such as return from the main function. In order to do a certain type of program or a platform for the development of the program, the most important thing is to find out this type of program or the entire platform under the general working mode of the program and to memorize in mind. In Android, the lifecycle control of a program is within this category--my personal understanding:

In an Android system, when an activity calls StartActivity (Myintent), the system starts the process by looking for its intent filter and myintent one of the most matched activity in all installed programs, and give this intent notice to the activity. This is the "Life" of a program. For example, when we select "Web browser" in home application, the system will find and launch the Web browser program based on this intent, displaying an activity on the Web browser for us to browse the Web page (this startup process has a bit of class It's like we're on a personal computer. Double-click an icon on the desktop to start an application. In Android, all apps are "born equal", so not only Android's core programs, but even third-party programs can emit a intent to start an activity in another program. This design of Android is very beneficial to the reuse of "program parts".

When did the process of an Android program end up in the system? In layman's terms, a program that is about to be shut down by the system is the "victim" chosen by the system on the "level of importance" when there is not enough memory (low memory). The importance of a process is determined by the state of the parts and parts in which it is run. The various processes are ranked from highest to lowest in importance:
1. The foreground process. Such a process has an activity that is displayed on the screen and interacts with the user or one of its intentreciver is running. Such programs are of the highest importance and will only end if the system has very low memory.
2. Visible process. A program that appears on the screen but is not in the foreground. For example, a foreground process appears in front of the process as a dialog box. Such processes are also important and will only end if the system does not have enough memory to run all foreground processes.
3. Service process. Such processes continue to run in the background, such as background music playback, background data upload and download. Such a process is generally useful to users, so it will only end if the system does not have enough memory to maintain all foreground and visible processes.
4. Background process. Such a program has an activity that is not visible to the user. Such programs are terminated in LRU order when the system is low on memory.
5. Empty process. Such a process does not contain any active program parts. The system may close such processes at any time.

In a sense, the garbage collection mechanism frees programmers from "Memory management Nightmares," and Android's process lifecycle management frees users from "mission Management nightmares." I've seen some Nokia S60 users and Windows Mobile users either cause the system to slow down because they don't shut down redundant applications for long periods of time, or they can affect the usage experience by looking at the list of applications occasionally. Android uses Java as an application API and combines its unique lifecycle management mechanism to provide maximum convenience to both developers and users.

There are three basic states of activity lifecycle activity：

active: In the foreground of the screen (the current task's top activity is active), only one activity can be active at the same time; paused state: In the background screen state, lost focus, but still active state; Stopped: not visible, but still maintains all state and memory information.

You can call finish () to end an activity that handles paused or stopped states.

transitions between various states through the following function calls：

void onCreate(Bundle savedInstanceState)
void onStart()
void onRestart()
void onResume()
void onPause()
void onStop()
void onDestroy()

The life cycle of an activity can be divided into three groups: the entire LifetimeAn activity happens between the ' the ' onCreate()Through to a in final call to onDestroy().

The visible lifetime of the activity happens between a call to onStart() until a corresponding call to onStop() .

The foreground lifetime of the activity happens between a call to onResume() until a corresponding call to onPause() .

Save Activity status

To capture this state before the activity is killed, can implement a onsaveinstancestate () to the activity. Android calls this method before making the activity vulnerable to being destroyed-that is, before OnPause () is called. It passes the "method a" Bundle object where you can record the dynamic state of the activity as Name-value Pai Rs. When the "is" again started, the Bundle is passed both to OnCreate () and to "a" of that ' s called aft ER onStart () , onrestoreinstancestate () , so, either or both of them can Recreate the captured state.

Unlike OnPause () and the other methods discussed earlier, onsaveinstancestate () and Onrestoreinstancestate () are not lifecycle methods. They are not always called. because onsaveinstancestate () is not always called, and you are should use it in the the transient St Ate of the activity, not to store persistent data. use onpause () for that purpose instead. procedure to start another activity The current activity ' s onpause () is called. Next, the starting activity ' s onCreate () , OnStart () , and Onresume () methods are called in sequence. Then, if the starting is no longer visible on screen, its onStop () is called. Service life cycle

A service can is used in two ways:it can is started and allowed to run until someone stops it or it stops itself. In this mode, it's started by calling Context.startservice () and stopped by calling Context.stopservice () . It can stop itself by calling service.stopself () or service.stopselfresult () . Only one StopService () the call are needed to stop the service, no matter how many times startservice () was called.

It can be operated programmatically using a interface that it defines and exports. Clients establish a connection to the service object and with that connection to call into the service. The connection is established by calling Context.bindService() , and are closed by calling Context.unbindService() . Multiple clients can bind to the same service. If The service has not already been launched, bindService() can optionally launch it.

Related methods:

void onCreate()
void onStart(Intent intent)
void onDestroy()

onCreate() onDestroy() The and methods are called for all services, whether they ' re started by Context.startService() or Context.bindService() . However, is called only for onStart() services started by startService() .

If a service permits others to bind to it, there are additional callback for it to methods:

IBinder onBind(Intent intent)
boolean onUnbind(Intent intent)
void onRebind(Intent intent)

Broadcast receiver Lifecycle

There is only one method: void OnReceive (Context curcontext, Intent broadcastmsg)

A process with an active broadcast receiver is protected from being killed. But a process with only inactive components can to killed by the ' system at no time ', when the memory it consumes is needed By the other processes.

This presents a problem then the response to a broadcast message is time consuming and, therefore, something that should b e do in a separate thread, away from the main thread where other components of the user interface run. If onReceive() spawns the thread and then returns, the entire process, including the new thread, is judged to be inactive (unless The other application components are active in the process) putting it in jeopardy of being killed. The solution to this problem onReceive() are for to start a service and let the service does the job, so the system knows that ther E is still active work being do in the process. The life cycle of a process

Android removes the process of least importance, in keeping with its importance. The importance from high to low for:

foreground process visible process service process background process empty process

Note : Because a process running a service is ranked higher than one with background activities Tiates a long-running operation might do-start a service for "operation, rather than simply spawn a thread-p Articularly if the operation would likely outlast the activity. For example, when playing MP3, a service should be started.