Four launchmodes for Android

Previous understandings of the four models are limited to theory and two simple tests (singletop and singletask)

Today, I tried to test my head, dizzy, and found the singleinstance cup.

If you are familiar with the four modes, jump to the bottom of the article to help you read the singleinstance issue. Thank you.

 

All activities with no launchmode specified are started in default mode.

1, standard

A new activity instance is created each time.

 

2. singletask

Stack space: A -- B -- C

After the startactivity (intent) is used to jump from C to A, because the stack space already has an instance of A, the activity B and C on a (that is, the ondestroy is destroyed), and a is placed on the top of the stack.

If onnewintent (...) method is rewritten in A, the intent data of C-hop a is also received.

 

3. singtop

Stack space: A -- B -- C

Finally, after you use startactivity (intent) to jump from C to A, even if the stack control already has an instance of a, the android system will re-create an instance of a and place it on the top of the stack, of course, the rewritten onnewintent (...) the method does not receive intent data and changes:

 

4. singleinstance (Code jump logic: A -- B -- c -- a -- B -- C .....)

1. The starting activity is not singleinstance (actual jump order: A -- B -- c -- a -- B -- C .....)

 

A and C are in the same stack, with the same taskid. B is in another stack. unlike their taskid, this stack has only one activity of B before B is destroyed (after B is created, onnewintent (...) can also be connected to intent data redirected by other activities). During the whole process, B is created only once, and a and c create an instance each time.

2. The start activity is singleinstance (actual jump order: A -- B -- c -- a -- C .....)

The first scenario in the Code is the same, but the actual jump order is different,

After a -- B -- C is actually redirected for the first time, when C is returned to a (after a is created, onnewintent (...) you can also receive intent data from other activities), and then jump from A to B, but jump to the C page, loop in turn, throughout the process, B only appears at the beginning of creation, and then jumps from A to C directly. A is of course a single instance, but C is also created only once, which is equivalent to a single instance.

When you press the physical return key for multiple jumps:

If the current page is a, a destroys, C appears, C destroys, B destroys, and the application ends.

If the current page is C, C destroys, B appears, B destroys, A, A destroys, and the application ends.

The actual jump status of the Return key is normal because the taskid of A is different from that of B and C and is not in the same stack.

From: http://www.cnblogs.com/youjun/archive/2012/06/05/2535534.html