And when we hit the back key, the activity will go back. This will have a problem, starting the same activity multiple times, and the system creates multiple instances that are expensive. So android designers provide startup mode to modify the system 's default behavior. There are four startup modes currently:
The following four startup modes are described in turn:
( 1 ) standard: standard mode, which is also the default pattern of the system. Each time an activity starts, a new instance is recreated, regardless of whether the instance already exists. The lifecycle of the created I & tance conforms to the life cycle of the activity in typical circumstances. It's oncreate, onstart, the onresume method will be called. This is a typical implementation. A task stack can have multiple instances, and each instance can also belong to a different task stack. In this mode, who started the activity, then the activity would run on the stack in which the activity was. For example, ActivityA started ActivityB ( b is standard mode ), then ActivityB will be in the stack.
Note: we need to know that activity must be attached to a stack. If we use the applicationcontext to start the activity of the standard mode, we'll get an error.
Calling startActivity() from outside ofan Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
Because the activity of the stardard schema defaults to the stack to which it's started, the context of the activity type doesn't have a task stack, so this error. How to solve this problem is to add a flag activity new task tag, which will create a new task stack for it when it starts, which starts the activity, and is actually.
( 2 ) singleTop:: In this mode, if the new activity is already on the stack top of the task stack, this activity won't be recreated and its onnewintent method will be callback, and the It's important to note that the oncreate of this activity won't be called by the system. Because he didn't change it. If the new activity instance already exists but not at the top of the stack. Then the new activity will still be recreated. Example: assuming that the current stack is a, b, c, d, this time again starts d, the startup mode is singleTop, which doesn't recreate the d. Stack. The case in this case is still a, b, c, d. If this time starts b, b, c, d, b.
( 3 ) singletask: It's a single instance of the pattern, in which case, as long as the activity exists in a stack, the activity won't be recreated many times. Like singleTop, the system will also call back to its onnewintent when an activity request for a singletask mode is started, if it doesn't exist, then create an instance of a task stack after creating an instance of a task stack. If a required task stack exists, see whether a is present in the stack. If the instance exists, then the system will set a to the top of the stack and call its onnewintent. Example:
For example, the situation in which the task stack s1 is ActivityD, this time starts with singletask mode request, the task stack that it requires is s2, so the system creates the task stack s2, and then creates the instance of d and puts it into the stack to s2.
Another case, assuming that the task stack required d is s1, other cases, as the above example, then because s1 already exists. So the system will create an instance of d directly and put it into the stack s1.
If the task stack required for d is s1, and the current task stack s1 is adbc, the d won't be recreated according to the principle of the stack. The system switches d to the top of the stack and calls its onnewintent method, as the singletask has cleartop effect, which results in an ad in the stack.
( 4 ) singleinstance: this is an enhanced singletask pattern that's enhanced in addition to all features of singletask mode, which is an activity that has such a pattern can only be located in one task stack, for example: A ActivityA is singleinstance mode, and when a starts, a new task stack is created for it. Then a is independent of the new task stack, due to the reuse of the stack, and subsequent requests don't create new activities unless the unique task stack is.
As mentioned earlier: when the activity is started, it'll look for the task stack it needs, what's the task stack required for the activity. I want to start with a parameter taskAffinity.
This parameter identifies the name of the task stack required by an activity, by default, the name of the task stack required by all activities, which we can specify for each activity. A taskAffinity property is mainly used with singletask startup mode or allowtaskreparenting attribute configuration, which isn't meaningful in other situations.
The two ways to specify the startup mode and its differences in
Fi & t: specify the startup mode for activity by AndroidMenifest:
Second: specify the startup mode for the activity by setting the flag bit in intent, such as:
Intent intent = new Intent(MainActivity.this,SecondActivity.class); intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); startActivity(intent);
Both modes can specify startup mode for activity, but there are differences between them. First of all, the second method is higher than the first, when two methods exist at the same time. Next two ways vary in scope, for example, the fi & t way cannot set flag activity clear top ids directly for activity, and the second way cannot specify singleinstance mode for activity.
Several flags properties commonly used by the activity:
This flag is a bit that specifies"singletask"startup mode for activity, which is the same as specifying the startup mode in xml.
The role of this flag is to specify"singleTop"startup mode for activity, which is the same as specifying the startup mode in xml.
Activity with this flag bit, when it starts, all the activities on the same task stack are pushed on the same task stack.
The activity with this tag doesn't appear in the history activity list, which is useful when we don't want the user to return to our activity through the history list. It's equivalent to specifying the property excludeFromRecents for activity in xml: ="true";