android Application Component研究之Activity(一)_commonsettingsapplicationcomponent-CSDN博客

本文链接：https://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

       // Don't modify the client's object!
        intent = new Intent(intent);

        // Collect information about the target of the Intent.
        ActivityInfo aInfo;
        try {
            ResolveInfo rInfo =
                AppGlobals.getPackageManager().resolveIntent(
                        intent, resolvedType,
                        PackageManager.MATCH_DEFAULT_ONLY
                        | ActivityManagerService.STOCK_PM_FLAGS);
            aInfo = rInfo != null ? rInfo.activityInfo : null;
        } catch (RemoteException e) {
            aInfo = null;
        }

        if (aInfo != null) {
            // Store the found target back into the intent, because now that
            // we have it we never want to do this again.  For example, if the
            // user navigates back to this point in the history, we should
            // always restart the exact same activity.
            intent.setComponent(new ComponentName(
                    aInfo.applicationInfo.packageName, aInfo.name));

            // Don't debug things in the system process
            if (debug) {
                if (!aInfo.processName.equals("system")) {
                    mService.setDebugApp(aInfo.processName, true, false);
                }
            }
        }

通过这个过程，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。