1, Android's activity task stack
On Android, each app will have a task stack by default when the app runs, and the task stack name is named after the app's package name. The task stack is a state-of-the-art structure, in which every activity in the app is placed in sequence, and the activity in focus is at the top of the stack of the task stack.
When the user presses the back key, the activities in the stack will stack up in sequence and invoke the activity's OnDestroy method. If there are no elements in the stack, the system recycles the app's task stack.
In the XML tag of the activity, you can define the pattern for each activity. Different patterns behave differently when they are called in the task stack:
- Standard mode: Normal mode. In this mode, each activity that is started creates an instance to press it into the task stack, regardless of whether the activity already exists at that time.
- Singletop mode: Stack top multiplexing mode. If the activity that is currently started is at the top of the task stack at this point, then the activity is reused. The OnCreate, OnStart, and Onresume methods of the activity are not re-executed at this time, but the Onnewintent () method is executed. If the activity is not in the top position of the stack, it is the same as standard mode.
- Singletask mode: In-stack multiplexing mode. A model that is more overbearing, when activity starts, determines whether the current stack already exists. If it does not exist, create the activity instance and press it into the task stack first. If present, all activity above the activity is erased, the activity is transferred to the top of the stack, and the Onnewintent method is called.
- SingleInstance mode: Enhanced version of the Singletask mode, the activity in this mode is in a separate task stack, unless the task stack is destroyed, the new activity will not be created.
The activity stack is managed in Activityrecord and all Activityrecord are placed in a list. You can think of a activityrecord as an activity task stack.
2, the activity of the cache
Why is there a cache of activity? For a chestnut: After the application has moved from activity A to activity B, the resource for a is reclaimed by the system. When you press the back key from B to return to a, the data and state of the previous a is lost, and the Onrestart method of a is not executed, but a is re-executed.
Method of OnCreate. The so,activity cache has the value of being there.
Activity has a well-encapsulated method: Onsaveinstancestate (). Before the activity is destroyed, the method is recalled to hold the activity's state and data. The method has a bundle parameter, which can be saved using the putstring (), Putint () method. When the activity initiates the call
The OnCreate method also has a bundle parameter, which is the data that was saved when the last activity was destroyed.
So what are the scenarios that trigger the Onsaveinstancestate () method? The answer is an action that is not actively destroyed by the user, so the method is called.
- The user presses the home key action
- Switch to another app
- When the screen is extinguished
- Enter another activity from the current activity
- If you do not set the Configchange property, the screen can be toggled on and off, because the system will destroy the current activity before switching, and then re-create it.
There are also some details of the knowledge:
- Each view in the UI layout is implemented by default with the Onsaveinstancestate () method, which means that every change in the UI interface is stored and resumed when the activity is rebuilt. There is a premise that this UI interface requires an ID, and if there is no ID, the previous implementation is not called.
- The Onsaveinstancestate () method call is nondeterministic and can only be used to record the transient state of the activity (the state of the UI). You cannot use this method to store persisted data. Persistent data (such as data that should be stored in the database) should be stored in the OnPause () method when the user leaves the activity.
- Onsaveinstancestate () if called, it must be triggered before onstop (), but it is not necessarily triggered before or after OnPause ().
Continue tomorrow ~
Android Basics-1