android Application Component研究之Activity(一)

http://blog.csdn.net/windskier/article/details/7096521

终于下定决心写写ActivityManagerService的源码分析的文章了，ActivityManagerService 业务的整个逻辑关系被各种复杂的数据结构包裹着，因此对ActivityManagerService 的分析主要就是对各种数据结构的分析，明白了这些数据结构，理解ActivityManagerService的业务内容就水到渠成了。

AMS提供了一个ArrayList mHistory来管理所有的activity，activity在AMS中的形式是ActivityRecord，task在AMS中的形式为TaskRecord，进程在AMS中的管理形式为ProcessRecord。如下图所示

从图中我们可以看出如下几点规则：

1. 所有的ActivityRecord会被存储在mHistory管理；

2. 每个ActivityRecord会对应到一个TaskRecord，并且有着相同TaskRecord的ActivityRecord在mHistory中会处在连续的位置；

3. 同一个TaskRecord的Activity可能分别处于不同的进程中，每个Activity所处的进程跟task没有关系；

因此，在分析Activity管理之前，先了解一下这个规则。

1. Activity 启动

这篇文章关于整个Activity的启动过程，侧重于分析相关数据结构的构建与管理，以达到理解整个AMS对Activity的管理。

1.1 获得要启动的activity信息

        final int startActivityMayWait(IApplicationThread caller,
            Intent intent, String resolvedType, Uri[] grantedUriPermissions,
            int grantedMode, IBinder resultTo,
            String resultWho, int requestCode, boolean onlyIfNeeded,
            boolean debug, WaitResult outResult, Configuration config)方法中。

我们知道，Android中是通过Intent来启动一个新的activity的，因此AMS在得到请求启动activity时，首先需要根据Intent从PM中获得要启动的activity，PM通过parse 每个application的AndroidManifest.xml来获得所有的activity信息，针对每个Intent提供的信息，PM会提供给AMS一个ResolveInfo对象。

startActivityMayWait()@ActivityManagerService.java

1. // Don't modify the client's object!
2. intent = new Intent(intent);
3. // Collect information about the target of the Intent.
4. ActivityInfo aInfo;
5. try {
6. ResolveInfo rInfo =
7. AppGlobals.getPackageManager().resolveIntent(
8. intent, resolvedType,
9. PackageManager.MATCH_DEFAULT_ONLY
10. | ActivityManagerService.STOCK_PM_FLAGS);
11. aInfo = rInfo != null ? rInfo.activityInfo : null;
12. } catch (RemoteException e) {
13. aInfo = null;
14. }
15. if (aInfo != null) {
16. // Store the found target back into the intent, because now that
17. // we have it we never want to do this again.  For example, if the
18. // user navigates back to this point in the history, we should
19. // always restart the exact same activity.
20. intent.setComponent(new ComponentName(
21. aInfo.applicationInfo.packageName, aInfo.name));
22. // Don't debug things in the system process
23. if (debug) {
24. if (!aInfo.processName.equals("system")) {
25. mService.setDebugApp(aInfo.processName, true, false);
26. }
27. }
28. }

通过这个过程，AMS就知道了要启动那个activity。在找到要启动的activity信息之后，需要将这个activity信息记录到Intent中。

1.2 创建ActivityRecord

final int startActivityLocked(IApplicationThread caller,
            Intent intent, String resolvedType,
            Uri[] grantedUriPermissions,
            int grantedMode, ActivityInfo aInfo, IBinder resultTo,
            String resultWho, int requestCode,
            int callingPid, int callingUid, boolean onlyIfNeeded,
            boolean componentSpecified)

这一函数主要为了创建对应activity的ActivityRecord，这里先简单的对startActivityLocked方法的几个关键的参数根据代码做一个解释。

1. IApplicationThread caller :请求启动当前Activity的应用方，IApplicationThread 类型是AMS IPC调用ActivityThread的IBinder接口；

2. IBinder resultTo: 调用方Activity的ActivityRecord，每个Activity在启动之后，AMS均会将这个Activity的ActivityRecord的IBinder再传递给Activity，作为其在AMS中的标识。因此此时的resultTo经过2次IPC传递之后，已经不再是接口了，回到AMS之后就会再次变为ActivityRecord。

3. callingPid和callingUid: 如果caller为空，其为请求启动Activity的进程的PID和UID；caller不为空，为caller activity所在的进程的PID和UID，基本上是一码事。这个PID和UID为了权限检查用的，检查当前的请求方是否有权限启动这个Activity。

startActivityLocked()方法在创建ActivityRecord前，还做了如下几不操作：

1. 确定sourceRecord和resultRecord，这两个变量均为ActivityRecord类型，前者代表请求启动当前activity的activity；后者表示当前的activity在启动之后需要返回结果的ActivityRecord，一般情况下，如果sourceRecord的activity使用startActivityForResult()启动当前activity并且requestCode>=0时，则resultRecord不为空，且resultRecord=sourceRecord。

还有一种特殊的情况，当启动一个activity时，启动的Intent设置了Intent.FLAG_ACTIVITY_FORWARD_RESULT标志，在这种情况resultRecord并不指向sourceRecord，而是指向sourceRecord的sourceRecord，比较绕上个图先

如上图所示，Activity A 启动了Activity B，Activity B又启动了C，A-->B-->C, 这种情况下，A启动B要求B返回result给A，但是如果B在启动C时，Intent设置了Intent.FLAG_ACTIVITY_FORWARD_RESULT标志，那么此时将会交由C向A setResult。为了避免冲突，B启动C时不得指定resultRecord>=0。

1. ActivityRecord sourceRecord = null;
2. ActivityRecord resultRecord = null;
3. if (resultTo != null) {
4. int index = indexOfTokenLocked(resultTo);
5. if (DEBUG_RESULTS) Slog.v(
6. TAG, "Sending result to " + resultTo + " (index " + index + ")");
7. if (index >= 0) {
8. sourceRecord = (ActivityRecord)mHistory.get(index);
9. if (requestCode >= 0 && !sourceRecord.finishing) {
10. resultRecord = sourceRecord;
11. }
12. }
13. }
14. int launchFlags = intent.getFlags();
15. if ((launchFlags&Intent.FLAG_ACTIVITY_FORWARD_RESULT) != 0
16. && sourceRecord != null) {
17. // Transfer the result target from the source activity to the new
18. // one being started, including any failures.
19. if (requestCode >= 0) {
20. return START_FORWARD_AND_REQUEST_CONFLICT;
21. }
22. resultRecord = sourceRecord.resultTo;
23. resultWho = sourceRecord.resultWho;
24. requestCode = sourceRecord.requestCode;
25. sourceRecord.resultTo = null;
26. if (resultRecord != null) {
27. resultRecord.removeResultsLocked(
28. sourceRecord, resultWho, requestCode);
29. }

1.2.2 Activity permission检查

1.2.2.1 callingPid和callingUid

根据前面获得的callingPid和callingUid，我们看一下callingPid和callingUid是如何获得的。

如果当前的activity不是从一个application启动的，也就是说参数caller==null，此时的callingPid和callingUid可以从IPC调用AMS的调用方获得，例如am启动，启动Home时，是没有caller的：

@startActivityMayWait()

1. if (caller == null) {
2. callingPid = Binder.getCallingPid();
3. callingUid = Binder.getCallingUid();
4. } else {
5. callingPid = callingUid = -1;
6. }

如果当前的activity是从一个application启动的，也就是说参数caller!=null，此时的callingPid和callingUid可以从caller所处的进程中得出。

1. ProcessRecord callerApp = null;
2. if (caller != null) {
3. callerApp = mService.getRecordForAppLocked(caller);
4. if (callerApp != null) {
5. callingPid = callerApp.pid;
6. callingUid = callerApp.info.uid;
7. } else {
8. Slog.w(TAG, "Unable to find app for caller " + caller
9. + " (pid=" + callingPid + ") when starting: "
10. + intent.toString());
11. err = START_PERMISSION_DENIED;
12. }
13. }

1.2.2.2    permission检查的规则

1. Root uid(0), System Server uid (Process.SYSTEM_UID), own process(MY_PID),将授权permission

2. 如果请求启动的activity的属性android:exported=false， 并且请求的callingUid不等于请求启动的activity的UID，不允许启动；

3. 请求启动的activity没有设定permission，只有当activity的permission和其所在的application的android:permission均为设置时才为null，直设置了application未设置activity，那么activity的permission与application相同。activity的permission为空，则授权；

4. 请求启动的activity设定了permission，那么检查请求方的activity中是否声明了使用这个permission，如果声明，授权。

1. final int perm = mService.checkComponentPermission(aInfo.permission, callingPid,
2. callingUid, aInfo.exported ? -1 : aInfo.applicationInfo.uid);
3. if (perm != PackageManager.PERMISSION_GRANTED) {
4. if (resultRecord != null) {
5. sendActivityResultLocked(-1,
6. resultRecord, resultWho, requestCode,
7. Activity.RESULT_CANCELED, null);
8. }
9. String msg = "Permission Denial: starting " + intent.toString()
10. + " from " + callerApp + " (pid=" + callingPid
11. + ", uid=" + callingUid + ")"
12. + " requires " + aInfo.permission;
13. Slog.w(TAG, msg);
14. throw new SecurityException(msg);
15. }

创建ActivityRecord

1. ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid,
2. intent, resolvedType, aInfo, mService.mConfiguration,
3. resultRecord, resultWho, requestCode, componentSpecified);

1.3  task管理

在android应用开发中，task是一个很重要的概念，在文章开始，我就画出了task和activity以及process整体的关系，在这里还需要说明一下，task和application的区别，application在android中的作用仅仅是activity在未被使用前的一个容器，我们开发android应用程序时，需要一个application来组织我们开发的activity，application和activity之间是一个静态关系，并且是一一对应的关系；也就是说我们开发的activity在PM中的最终形式是唯一的，永远对应一个application。

而task和activity之间的关系是动态的关系，是我们在运行应用程序时，activity的调用栈，同一个task中的activity可能来自不同的application。

关于task，更详细的资料参考:http://developer.android.com/guide/topics/fundamentals/tasks-and-back-stack.html

这部分源码主要是在

final int startActivityUncheckedLocked(ActivityRecord r,
            ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
            int grantedMode, boolean onlyIfNeeded, boolean doResume)

这一部分比较繁琐，写的可能比较乱。

1.3.1 Intent.FLAG_ACTIVITY_NO_USER_ACTION

检查Intent是否设置了Intent.FLAG_ACTIVITY_NO_USER_ACTION，如果设置了，则在activity pause之前将不再调用activity的onUserLeaveHint()方法。

1. mUserLeaving = (launchFlags&Intent.FLAG_ACTIVITY_NO_USER_ACTION) == 0;
2. if (DEBUG_USER_LEAVING) Slog.v(TAG,
3. "startActivity() => mUserLeaving=" + mUserLeaving);

1.3.2 Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP

检查Intent是否设置了Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP，这个标志我有点困惑，从它的注释可以看出它的含义是指如果设置了该flag，那么mHistory中最top的activity在后续的处理中将不被视为top，而将前一个activity视为top，如A-->B-->C，将B视为top。

这个top activity的作用很大，涉及到后面对task的处理。但是目前来看这个flag并没有起到该有的作用，代码中判断如果设置了该标志，那么AMS将会视当前正在启动的activity为top，然后去mHistory中去查找它的前一个activity为后续task处理的top activity(topRunningNonDelayedActivityLocked()中实现)，但是现在的问题是此时此刻，正在启动的activity并不存在于mHistory中，因为我们在前一个函数中刚刚创建了这个ActivityRecord。如下面代码所示：

1. ActivityRecord notTop = (launchFlags&Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP)
2. != 0 ? r : null;

因此，感觉这个flag的意义不是太大。

1.3.3  何时应该创建新的task

sourceRecord为空；sourceRecord的activity的launch mode为ActivityInfo.LAUNCH_SINGLE_INSTANCE，也就是sourceRecord activity的task只允许一个activity；当前activity的launch mode为ActivityInfo.LAUNCH_SINGLE_INSTANCE或者r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK。以上几种情况，均可视为需要为启动的activity创建一个新的task.

1. if (sourceRecord == null) {
2. // This activity is not being started from another...  in this
3. // case we -always- start a new task.
4. if ((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
5. Slog.w(TAG, "startActivity called from non-Activity context; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: "
6. + intent);
7. launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
8. }
9. } else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
10. // The original activity who is starting us is running as a single
11. // instance...  this new activity it is starting must go on its
12. // own task.
13. launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
14. } else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
15. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
16. // The activity being started is a single instance...  it always
17. // gets launched into its own task.
18. launchFlags |= Intent.FLAG_ACTIVITY_NEW_TASK;
19. }

1.3.4 Intent.FLAG_ACTIVITY_NEW_TASK时断开与Caller依赖

如果启动的activity需要新的task，那么新启动的activity将会与其caller断开依赖关系，这个关系主要是指result反馈，A-->B,如果A是通过startActivityForResult()请求启动的，并且requestCode >=0,那么如果B是在新的task中，那么B在finish的时候将不再向A反馈result，而是在启动过程中就会向A反馈一个RESULT_CANCELED。

1. if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
2. // For whatever reason this activity is being launched into a new
3. // task...  yet the caller has requested a result back.  Well, that
4. // is pretty messed up, so instead immediately send back a cancel
5. // and let the new task continue launched as normal without a
6. // dependency on its originator.
7. Slog.w(TAG, "Activity is launching as a new task, so cancelling activity result.");
8. sendActivityResultLocked(-1,
9. r.resultTo, r.resultWho, r.requestCode,
10. Activity.RESULT_CANCELED, null);
11. r.resultTo = null;
12. }

1.3.5  Task复用

1.3.5.1 Task的基本属性

检查mHistory中是否有task可复用，在分析这段之前，先了解一下task的一些基本概念

task的root activity是指如果一个activity启动时创建的了一个新的task，那么这个activity是task的root activity；

task.affinity是指root activity的affinity；

task.intent是指启动root activity的Intent；

task.affinityIntent是指activity在进行了TaskReparenting之后，AMS为activity分配了新的task，该task的affinityIntent则是启动该activity时的Intent，此时task.intent==null。

TaskReparenting操作举例说明一下，假如有2个activity拥有不同的affinity，且自Activity A中启动Activity B，假如Activity A是所在task的root activity，如下图示：

假如Activity B设置了ActivityInfo.FLAG_ALLOW_TASK_REPARENTING，那么如果此时另外一个application启动了Activity B并要求其在新的task中，那么此时的Activity B将被从Task A中移动到新的task中，如下图所示：

这个过程就称之为TaskReparenting，关于TaskReparenting，我会专门写一篇文章分析一下。下面来分析task复用的过程。

1.3.5.2 查找可复用的task

以下3种条件需要检查是否有有task可复用

⑴ (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
                (launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0;

⑵ r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK

⑶ r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE

第⑴是一个组合条件，Intent.FLAG_ACTIVITY_MULTIPLE_TASK不能单独使用，它是和Intent.FLAG_ACTIVITY_NEW_TASK结合起来使用的，如果设置了Intent.FLAG_ACTIVITY_MULTIPLE_TASK，那么将会永远启动一个新的task，不管是否有可复用的task。

为什么是这3种条件，从android的开发文档中，我们可知LAUNCH_SINGLE_TASK和LAUNCH_SINGLE_INSTANCE两种launch mode的activity只允许作为task的root activity，既然是作为root activity，那么它所处的task的affinity必然是和它的是一样的，因此从mHistory中找打一个和自己的affinity相同的task是非常有必要的。

而对于设置了Intent.FLAG_ACTIVITY_NEW_TASK的Intent来说，并且没有设置Intent.FLAG_ACTIVITY_MULTIPLE_TASK，那么同样的，它也必须是作为它所处的task的root activity。道理是一样的。

AMS去mHistory中查找可复用的task，查找这个task的规则如下：

  ⑴ launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE的情况，遵循如下规则： @findTaskLocked()

① 查找mHistory中是否有与要启动的activity相同affinity的task，上面也提过这几类activity启动时，均是作为task的root activity，并且其task的affinity必须和自己的affinity相同，因此首先需要去mHistory查找和自己affinity相同的task。

② 如果activity没有affinity，即属性android:taskAffinity设置为“”，空字符串时。此时AMS就会去mHistory中去查找是否有task的root activity和启动的activity相同，通过比较task.intent.getComponent()和启动activity的Comeponent比较，为什么是root activity，前面分析过了；

③ 如果task.Intent为空，这种情况发生在TaskReparenting之后，TaskReparenting之后，AMS为这个activity创建一个新的task，并将启动这个activity的Intent赋值给task.affinityIntent，并且此时的task.Intent==null。此时就需要比较task.affinityIntent.getComponent()和启动activity的Comeponent比较，看是否和启动的activity相同。

以上3个规则中，均是返回找的task中最上面的activity，而不一定是task的activity，至于如何处理要启动的activity和task中已有的activity，后面会介绍。

 ⑵ launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE的情况，遵循如下规则： @findActivityLocked()

对于ActivityInfo.LAUNCH_SINGLE_INSTANCE启动模式来说，它所处的task中只允许有它一个activity，因此它的规则只符合上面规则中的②；

对于第①条，由于设置了ActivityInfo.LAUNCH_SINGLE_INSTANCE启动模式的activity，它只能自己独处一个task，不可能和别人共享同一个task，因此mHistory即使存在了与该activity有相同的affinity的activity，如果这个activity和启动的activity不同，那么ActivityInfo.LAUNCH_SINGLE_INSTANCE启动模式的activity也不可能和它共用一个task，因此这第①条完全可以不用检查。

对于第②条，由于该模式的activity独处一个task，因此完全没有可能所处的task的affinity和自己的affinity不同，因此，假如mHistory存在相同的activity与启动的activity相同，那么这个activity的affinity必然和自己的相同。所以对于这种模式，第②条囊括了其他模式的①②两条。

对于第③条，同样的道理，ActivityInfo.LAUNCH_SINGLE_INSTANCE启动模式的activity不可能处在与自己不同affinity的task中，因此不可能出现TaskReparenting操作，所以这条也不需要。

1. ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
2. ? findTaskLocked(intent, r.info)
3. : findActivityLocked(intent, r.info);

在获得taskTop之后，下面来分析这个taskTop的意义。

1.3.5.3 task移到mHistory前端

由于我们要复用task，因此需要将taskTop所在的task移到mHistory前端。

1. ActivityRecord curTop = topRunningNonDelayedActivityLocked(notTop);
2. if (curTop.task != taskTop.task) {
3. r.intent.addFlags(Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT);
4. boolean callerAtFront = sourceRecord == null
5. || curTop.task == sourceRecord.task;
6. if (callerAtFront) {
7. // We really do want to push this one into the
8. // user's face, right now.
9. moveTaskToFrontLocked(taskTop.task, r);
10. }
11. }

1.3.5.4 Reset Task

如果Intent设置Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED，最常见的情况，当从Home启动应用程序时，会设置这个flag；从recently task进入应用程序，则不会设置这个falg。

设置了FLAG_ACTIVITY_RESET_TASK_IF_NEEDED，AMS会对复用的task作如下处理，下面称这个可复用的task为复用task：

⑴ mHistory中，对于复用task中的除root activity外的activity，有如下处理

在此之前，先介绍activity的几个关键属性：

① 如果复用task在后台时间超过30min，那么在这个过程中将删除除root activity之外的所有的activity；

② 如果新启动的activity设置了属性ActivityInfo.FLAG_ALWAYS_RETAIN_TASK_STATE，那么表明它并不要求后台20min的复用task删除activity；

③ 如果新启动的activity设置了属性ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH，那么表明不论复用task在后台是否超过30min，一律要求删除除root activity之外的所有的activity；

④ 复用task中的activity设置了属性ActivityInfo.FLAG_FINISH_ON_TASK_LAUNCH，那么复用task从home中再次被启动到前台时，这个activity会被删除；

⑤ 复用task中的activity设置了属性ActivityInfo.FLAG_ALLOW_TASK_REPARENTIN，并且这个activity的resultTo为空，那么也就是说这个activity和它的caller没有依赖关系，那么AMS认为这个activity暂时没有用处了，需要对其进行TaskReparenting操作，最好的方法是把它放到mHistory栈底，不影响其他task。

⑥ 复用task中的activity的Intent设置属性Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET，那么下次再从home中进入到task中，那么将删除设置了该属性的activity以上所有的activity，例如A-->B-->C-->D-->E,加入在C启动D时设置了该属性，那么下次从HOME中再次进入到这个task中时，将会是A-->B-->C。

⑦ 如果复用task中的activity的resultTo不为空，也就是启动这个activity的是一个activity，那么这个activity的处理将按照它的前一个activity的处理方式来处理，不管在何时情况下，它的前一个activity都是启动它的activity，即便resultTo不是前一个activity，如设置了Intent.FLAG_ACTIVITY_FORWARD_RESULT。如果复用task中每个activity的resultTo都不为空，并且上述处理优先级在其前面的属性没有设置的话，那么这个复用task中的activity将不作任何的处理。

一般情况下，activity的resultTo都不为空，除非设置了Intent.FLAG_ACTIVITY_FORWARD_RESULT，那么此时被启动的activity的caller的resultTo将会为空。

task中的activity的属性设置是上述属性的组合，因此reset task过程要按照一定的优先级来处理，上述属性的处理优先级是：⑥=④>⑦>⑤>③=②>①

        具体操作顺序如下：

♣ 根据⑥，④条件来删除复用task中相应的activity；

♣ ⑦条件下，将会暂时不做处理，再根据它的前一个activity的属性来做处理，即使这个activity设置了allowTaskReparenting；

♣ 如果activity的resultTo为空，并且满足条件⑤，那么将其及其以上未作处理的，满足条件⑦的所有activity，一并进行TaskReparenting操作，并放置在mHistory栈底。它们在mHistory栈底顺序如同在复用task中的顺序；

♣ 根据①②③的条件来删除复用task中相应的activity。

⑵ mHistory中，不属于复用task的activity，并且它的resultTo不为空，那么将根据它的前一个activity的处理来处理；

⑶ mHistory中，不属于复用task，但是和当前启动的activity有相同affinity，并且允许TaskReparenting操作，那么将进行以下操作：

♣ 如果满足上述的①②③④的条件，但是其中的task不是复用task，而是这个activity所处的task，那么将输出这个activity，而不是进行TaskReparenting操作。

为什么非复用task中的activity，和当前启动的activity有相同affinity，并且允许TaskReparenting操作，满足了①②③④的条件之后要删除呢，为什么非复用task中的其他activity，不需要删除呢？

正因为它和启动的activity有相同的affinity，因此AMS认为这个activity是和启动activity相关的，以后可能会重新调用，所以当其满足删除条件后,这时它将不允许TaskReparenting操作，并且不应该再允许它存在于其他的task中，此时应该删除。

♣ 如果没有满足①②③④的条件，那么将会对其进行TaskReparenting操作，重新将其移动到复用task或新启动的task中。

1. // If the caller has requested that the target task be
2. // reset, then do so.
3. if ((launchFlags&Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED) != 0) {
4. taskTop = resetTaskIfNeededLocked(taskTop, r);
5. }

上面就是这个复用task的reset 过程，它的执行过程是按照上述的⑴⑵⑶的顺序来执行的，下面给出一个图示，便于更好的理解reset task的过程。

1.3.5.5 判断是否有可复用的activity

如果mHistory中有可复用的task，那么在某些情况下并不需要启动这个activity，下面分析具体是什么情况：

⑴ Intent设置了Intent.FLAG_ACTIVITY_CLEAR_TOP，或者launchMode == ActivityInfo.LAUNCH_SINGLE_TASK，或者r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE；这3种条件有一个共同点，就是启动的activity启动之后，在这个task中,这个activity之上不能有其他的activity。

一般情况下，需要将复用task中启动的activity之上的所有的activity删除，

当activity的launchMode == ActivityInfo.LAUNCH_MULTIPLE，即普通模式，并且Intent并未要求singletop模式，这种情况是连复用task中与启动activity相同的activity都要删除，也就是不希望复用相同的activity。

performClearTaskLocked()实现了上述功能，并返回可复用的activity。

1. ActivityRecord top = performClearTaskLocked(
2. taskTop.task.taskId, r, launchFlags, true);

如果有可复用的activity，并且这个activity是task的root activity，由于task的Intent是root activity的Intent，所以需要重新设置task的Intent。

向可复用的activity发送新的Intent，通知它Intent的变化，最终会调用到这个activity的onNewIntent()方法。

⑵ 如果不满足⑴条件的话，但是启动的activity与复用task的root activity相同。

如果此时Intent设置了Intent.FLAG_ACTIVITY_SINGLE_TOP，并且复用task的top activity正好是要启动的activity，则复用这个activity，同时更新activity的Intent，如果需要更新task的Intent。

如果Intent没有设置了Intent.FLAG_ACTIVITY_SINGLE_TOP，即使设置了，但是当前的top activity不是正要启动的activity，那么会判断当前启动的Intent和task的Intent不同，那么将会重新启动这个activity。

其他情况，将直接resume top的activity。

⑶ 如果⑴ ⑵条件均不满足，其实如果不满足⑴ ⑵条件的话，复用的task中就不存在与启动的activity相同的activity了，如果启动的Intent没有设置Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED，那么一定不会复用任何的activity。

(4) 如果⑴ ⑵条件均不满足，并且Intent设置了Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED，那么需要检查当前复用task的Intent是否设置了Intent.FLAG_ACTIVITY_RESET_TASK_IF_NEEDED。

如果没有设置，重新设置新的Intent,同样不可能复用activity。

这种情况下，将不会显示要启动的activity，而是改为显示复用的task中的内容，如下图：

至此，整个Task复用，已经activity复用的过程就介绍完了，如果没有可复用的activity，则需要启动一个新的activity，如果有可复用的activity，那么activity的启动过程至此结束，直接调用resumeTopActivityLocked()resume top的activity即可。

以后的处理均为Task复用和activity复用失败之后的处理。

1.3.6 singleTop和singleTask属性的处理

这一部分是针对singleTop和singleTask属性的处理，前面分析Task复用的时候，也有对singleTop和singleTask属性的处理，两者有什么不同呢？

Task复用中是启动的activity需要在新的task中，而这里的处理主要是针对同一个task。

当设置Intent.FLAG_ACTIVITY_SINGLE_TOP或者launchMode == ActivityInfo.LAUNCH_SINGLE_TOP或者launchMode == ActivityInfo.LAUNCH_SINGLE_TASK这几种情况下，如果top activity与启动的activity为同一个activity，那么将复用top activity，并直接resume top activity。

1. if (top != null && r.resultTo == null) {
2. if (top.realActivity.equals(r.realActivity)) {
3. if (top.app != null && top.app.thread != null) {
4. if ((launchFlags&Intent.FLAG_ACTIVITY_SINGLE_TOP) != 0
5. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TOP
6. || r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
7. logStartActivity(EventLogTags.AM_NEW_INTENT, top, top.task);
8. // For paranoia, make sure we have correctly
9. // resumed the top activity.
10. if (doResume) {
11. resumeTopActivityLocked(null);
12. }
13. if (onlyIfNeeded) {
14. // We don't need to start a new activity, and
15. // the client said not to do anything if that
16. // is the case, so this is it!
17. return START_RETURN_INTENT_TO_CALLER;
18. }
19. top.deliverNewIntentLocked(callingUid, r.intent);
20. return START_DELIVERED_TO_TOP;
21. }
22. }
23. }
24. }

r.resultTo == null这个条件是在startActivityForResult()的requestCode<0时成立。

为什么没有ActivityInfo.LAUNCH_SINGLE_INSTANCE？这是因为这种启动模式，如果Task复用失败之后，直接启动为其启动一个Intent.FLAG_ACTIVITY_NEW_TASK即可。

1.3.7 standard和singleInstance模式

为什么代码中没有明显的针对ActivityInfo.LAUNCH_SINGLE_INSTANCE模式的处理？这是因为这种启动模式，如果Task复用失败之后，直接启动为其启动一个Intent.FLAG_ACTIVITY_NEW_TASK即可。

⑴ 设置了Intent.FLAG_ACTIVITY_NEW_TASK，则为该activity创建一个新的task；

⑵ 在当前的task中启动新的activity，

①当前的caller是一个activity，如果设置Intent.FLAG_ACTIVITY_CLEAR_TOP，当前的task如果存在要启动的activity(这个和上一节中的Task复用时的clear top过程不同，两者是互斥的过程，不冲突)，清除其上的所有的activity；

② 当前的caller是一个activity，如果设置Intent.FLAG_ACTIVITY_REORDER_TO_FRONT，这个flag表示如果启动的activity已经在当前的task中，那么如果当前启动的Intent设置了该flag，那么则会将这个activity从task中移动到top。

如果A-->B-->C-->D，D启动B时，设置了该flag，那么将变为A-->C-->D-->B

①②两个条件，则不需要再启动新的activity，直接resume top。

③  当前的caller是一个activity，其他情况则需要启动新的activity。

⑶ 当前的caller不是activity，那么仍将新启动的activity放在top的task中。