-
Exploring the Activity lifecycle Every process running on the Android platform is placed on a stack. When you use an Activity in the foreground, the system process that hosts that Activity is placed at the top of the stack, and the previous process (the one hosting whatever Activity was previously in the foreground) is moved down one notch. This concept is a key point to understand. Android tries to keep processes running as long as it can, but it can’t keep every process running forever because, after all, system resources are finite. So what happens when memory starts to run low or the CPU gets too busy?39926
- 上一篇：对C# 2.0和C# 3.0的新功能概述英文文献和中文翻译
- 下一篇：钛合金加工英文文献和中文翻译
When the Android platform decides it needs to reclaim resources, it goes through a series of steps to prune processes (and the activities they host). It decides which ones to get rid of based on a simple set of priorities:
1 The process hosting the foreground Activity is the most important.
2 Any process hosting a visible but not foreground Activity is next in line.
3 Any process hosting a background Activity is next in line.
4 Any process not hosting any Activity (or Service or BroadcastReceiver) is known as an empty process and is last in line.
A useful tool for development and debugging, especially in the context of process priority, is the adb, which you first met in chapter 2. You can see the state of all the running processes in an Android device or emulator by issuing the following command: adb shell dumpsys activity.
This command will output a lot of information about all the running processes, including the package name, PID, foreground or background status, the current priority,and more.
All Activity classes have to be able to handle being stopped and shut down at any time. Remember, a user can and will change directions at will. It might be a phone call or an incoming SMS message, but the user will bounce around from one application to the next. If the process your Activity is in falls out of the foreground, it’s eligible to be killed and it’s not up to you; it’s up to the platform’s algorithm, based on available resources and relative priorities.
To manage this environment, Android application, and the Activity classes they host, must be designed differently from what you might be used to in other environments. Using a series of event-related callback type methods defined in the Activity class, you can set up and tear down the Activity state gracefully. The Activity subclasses that you implement override a set of lifecycle methods to make this happen. As we discussed in section 3.1.1, every Activity must implement the onCreate() method. This method is the starting point of the lifecycle. In addition to onCreate(), most activities will want to implement the onPause() method, where data and state can be persisted before the hosting process potentially falls out of scope.
The lifecycle methods that the Acrtivity class provides are called in a specific order by the platform as it decides to create and kill processes.Because you, as an application developer, can’t control the process, you have to rely on the callback lifecycle methods to control state in your Activity classes as they come into the foreground, move into the background, and fall away altogether. This part of the overall Android platform is both significant and clever. As the user makes choices, activities are created and paused in a defined order by the system as it starts and stops process.
Beyond onCreate() and onPause(), Android provides other distinct stages, each of which is a part of a particular phase of the life of an Activity class. The methods that you’ll encounter most and the phases for each part of the lifecycle are shown in figure 3.3.
Each of the lifecycle methods Android provides has a distinct purpose, and each happens during part of the foreground, visible, or entire lifecycle phase. In the foreground phase, the Activity is viewable on the screen and is on top of everything else (when the user is interacting with the Activity to perform a task). In the visible phase, the Activity is on the screen, but it might not be on top and interacting with the user (when a dialog or floating window is on top of the Activity, for example). The entire lifecycle phase refers to the methods that might be called when the application isn’t on the screen, before it’s created, and after it’s gone (prior to being shut down).