Develop series-API Guides-application components-Activities,-api-activities
Activities Lifecycle
Essentially, activity A has three states:
- Resumed: A is at the beginning and has the user focus. This status is generally called running.
- Paused: activity B is at the beginning and has the user focus, but A is still visible. That is to say, B is either transparent or not completely covered by. The activity object in this status is still in memory, maintains all status and member information, and is still attached to window manager, which may be destroyed by the system.
- Stopped: A is completely overwritten by B. The activity object in this state is still in the memory and maintains all States and member information, but no window manager is attached, invisible and possibly destroyed by the system at any time.
public class ExampleActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // The activity is being created. } @Override protected void onStart() { super.onStart(); // The activity is about to become visible. } @Override protected void onResume() { super.onResume(); // The activity has become visible (it is now "resumed"). } @Override protected void onPause() { super.onPause(); // Another activity is taking focus (this activity is about to be "paused"). } @Override protected void onStop() { super.onStop(); // The activity is no longer visible (it is now "stopped") } @Override protected void onDestroy() { super.onDestroy(); // The activity is about to be destroyed. }}
Note: to overwrite the lifecycle callback function, call the default implementation function of the parent class.
Complete lifecycle: onCreate-> onDestroy
Visible life cycle: onStart-> onStop
Foreground lifecycle: onResume-> onPause
OnPause, onStop, and onDestroy methods may be destroyed by the system (low memory). Because onPause bears the brunt, you must use onPause to store important persistent data of users, and choose the most important one to save. Because onPause is frequently executed and the logic takes too long, it will affect the user experience.
Note: In extreme scenarios, other statuses may be destroyed.
Save activity status
The onSaveInstanceState is called before the activity is accidentally destroyed by the system. Data is transmitted through the Bundle (putString, putInt to save the key-value pair data). If the activity is destroyed, restart the activity, the system will pass the stored Bundle data to onCreate and onRestoreInstatnceState. Through these two methods, you can restore the status data saved in the Bundle. (Bundle data is null at the first startup)
Note: it cannot be guaranteed that the onSaveInstanceState will be executed before the activity is destroyed. For example, when you press the return key, the onSaveInstanceState will not be triggered. Therefore, it is better to save the onSaveInstanceState temporarily, the data needs to be persistently stored using onPause.
By default, all built-in widgets implement onSaveInstanceState. For example, EditText stores user input data by default. You need to specify a unique id for each widget through android: ID. Of course, you can use android: saveEnabled = false or call setSaveEnabled to forcibly disable the default behavior of the system.
If we need to override the onSaveInstanceState () method, the default implementation of this method is called in the first line of code: super. onSaveInstanceState ().
A simple verification method for data storage is to check whether the user input data in your app is retained. (Of course, it is possible that the developer will force the creation of the activity not to be re-destroyed on the horizontal and vertical screens)
Configuration changes
When the configurations of some devices change, the activity will be destroyed and re-created to adapt to the newly configured resources, such as horizontal and vertical screens and language changes.
To cope with this change, you can useonSaveInstanceState()
AndonRestoreInstanceState()
(OronCreate()
) To save the status.
Collaboration
A starts B:
If A needs to save data for B, the logic should be placed before onPause, rather than before onStop.