Android_Activity life cycle full solution

Written in the front: The main purpose of writing this article is to clarify my own thinking, serve myself well, and serve everyone better.

 

What we need to pay attention to is when we do what with which lifecycle callback method.

 

Evernote address, click

 

Unlike other programming paradigms: the program starts from the main() method. The Android system invokes corresponding callback functions to execute code according to different stages of the life cycle. The system has an ordered set of callback functions for starting and destroying an activity.

 

An activity is an application component that users can provide to interact with the screen to perform actions such as making a phone call, taking a photo, sending an email, or viewing a map. Each Activity gets a window on which to draw its user interface. A window usually fills the screen, but can also be smaller than the screen and float above other windows. — By Google

 

Activity basically exists in three states:

• continue/run

  • This Activity is in the foreground of the screen and has user focus. (This state is also sometimes referred to as "running.")

• pause

  • Another Activity is in the foreground of the screen and has user focus, but this Activity is still visible. That is, another Activity is displayed above this Activity, and the Activity is partially transparent or does not cover the entire screen. A suspended activity is fully active (the Activity object remains in memory, it retains all state and member information, and is connected to the window manager), but may be terminated by the system in extreme low-memory conditions.

• stop

  • The Activity is completely obscured by another Activity (the Activity is currently in the "background"). A stopped activity is also still active (the Activity object remains in memory, it retains all state and member information, but is not connected to the window manager). However, it is no longer visible to the user and may be terminated by the system when memory is needed elsewhere.
  • If an Activity is in a paused or stopped state, the system can remove it from memory by asking it to end (calling its finish() method) or by simply killing its process. When the Activity is opened again (after ending or terminating it), it must be rebuilt.

Lifecycle diagram (after simple translation):

Detailed explanation of life cycle methods

onCreate()
performs "global" state setup (such as defining layouts), creating views, binding data to lists, and more.
The required components of the Activity should be initialized within the implementation.
Most importantly, you must call setContentView() within this method to define the layout of the activity's user interface.

onRestart()
is called just before the Activity has stopped and is about to start again. Always follow onStart().

onStart()
is visible.

onResume()
can interact with the user.

onPause()
is typically used to acknowledge unsaved changes to persistent data, stop animations, and other things that might consume CPU, and so on. It should do what it needs to do very quickly because it returns before the next activity can continue.
Do some necessary operations, such as you want to store some data to the database, to call the second interface Activity, you should write data to the database during the execution of onPause() instead of onStop().

onStop()
is not visible/hidden.

onDestroy()
releases all resources.

 

Q&A

1
Android Studio

<intent-filter>
 <action android:name="android.intent.action.MAIN" />
 <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

It is said that there is no main Activity entry in an APP. After the program is installed, there will be no application on the mobile phone program list, so your app icon will not be displayed in the main interface list of the device. I really haven't tested this, because after deleting it, the smart Android Studio will not run. Eclipse to be tested~~~
2
also said on the Internet that if you finish directly, it will directly call the ondestroy method, but will not call onPause and onStop. After my test, it depends on the situation. If it is finished directly in the lifecycle callback, such as onCreate, then The ondestroy method will be called directly. If it is in onstart, it will call onStop and ondestroy. If it is finished in onResume, it will still call onPause, onStop, and finally ondestroy. If it is called in other methods, such as button click finish, onPause and onStop will still be called.
3.
Special attention is required: An activity jumps to another activity (complete coverage), and only calls onPause first, and when the second activity life cycle enters the running state, it will call its own onStop method (note that if it is not completely covered) occlusion, onStop will not be called). Therefore, it should be noted here that no matter which activity it is in, onPause cannot perform too time-consuming operations , otherwise it will delay the opening of the jump page. Similarly, the aftermath operation can be performed in the onStop method.
4
The onSaveInstanceState and onRestoreInstanceState methods do not belong to the Android lifecycle callback methods and need to be clarified.

• onRestoreInstanceState

  • Its execution is generally after onStart and before onResume.

  • Call timing: It does not appear in pairs with onSaveInstanceState. The timing of its appearance is that the activity is destroyed by the system (artificially not counted), and it will be called when it is created .

• onSaveInstanceState

  • Its execution is generally after onPause and before onStop.

  • When to call: If the current activity is to be destroyed, it will not be called. It will be called when jumping to another activity; it will be called when jumping to the desktop; when jumping to an activity that is not fully covered (transparent, semi-transparent), onSaveInstanceState will also be called, but onStop will not be called because it is paused Status; it will be called when the horizontal and vertical screens are switched.

5.
Save the state of Activity
When the system destroys an Activity in order to restore memory, the Activity object will also be destroyed, so the system cannot keep its state intact when continuing the Activity, but must rebuild the Activity object when the user returns to the Activity. But the user is unaware that the system destroyed the activity and then rebuilt it, so they are likely to think that the state of the activity is unchanged. In this case, you can implement another callback method that saves information about the activity state to ensure that important information about the activity state is preserved: onSaveInstanceState().

The system calls onSaveInstanceState() before making the Activity easy to destroy. The method is passed a Bundle where you can use methods such as putString() and putInt() to save information about the activity state in name-value pairs. Then, if the system kills your app process and the user returns to your activity, the system rebuilds the activity and passes the Bundle to both onCreate() and onRestoreInstanceState(). You can use either of the methods above to extract your saved state from the Bundle and restore the Activity state. If there is no state information to restore, the Bundle passed to you is an empty value (this is the case if the Activity is created for the first time, so if you want to get the value from the Bundle, it is recommended to be in onRestoreInstanceState() , because it is called When the Activity is 100% destroyed, the Bundle will not be empty, otherwise it will be judged whether it is empty in onCreate().
If you do
nothing However, even if you do nothing and do not implement onSaveInstanceState(), the Activity class's default implementation of onSaveInstanceState() restores part of the Activity state. Specifically, the default implementation calls the appropriate onSaveInstanceState() method for each View in the layout, allowing each view to provide information about itself that it should save. Almost every widget in the Android framework implements this method as needed to automatically save and restore any visible changes to the UI when the activity is rebuilt. For example, the EditText widget holds any text entered by the user, and the CheckBox widget holds the checked or unchecked state of a checkbox.You just need to provide a unique ID (via the android:id attribute) for each widget whose state you want to save. If the widget does not have an ID, the system cannot save its state. (So ​​I think that a unique ID needs to be provided in the UI controls with data to display the UI depending on the situation )

Since the default implementation of onSaveInstanceState() helps save the state of the UI, if you override this method to save more state information, you should always call the superclass implementation of onSaveInstanceState() before doing anything. Likewise, if you override the onRestoreInstanceState() method, its superclass implementation should also be called so that the default implementation can restore the view state.