Android源码分析——Activity的启动过程

96
兰心之舞动
2017.02.16 20:59* 字数 619

最近在看维术的Android插件化原理解析,需要补充一些Framework层的知识,首先来研究Activity的启动过程。

Activity的启动从Activity类中startActivity方法(先看Actiivty中的,后面再看Context中的,本质是一样的)开始。跟着这个方法一步一步跟踪,会发现它最后在startActivityForResult里面调用了Instrument对象的execStartActivity方法;
Instrumentation类中的execStartActivity方法,源码如下:

public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
        IApplicationThread whoThread = (IApplicationThread) contextThread;
        ......
        ......
        try {
            intent.migrateExtraStreamToClipData();
            intent.prepareToLeaveProcess();
            int result = ActivityManagerNative.getDefault()
                .startActivity(whoThread, who.getBasePackageName(), intent,
                        intent.resolveTypeIfNeeded(who.getContentResolver()),
                        token, target != null ? target.mEmbeddedID : null,
                        requestCode, 0, null, options);
            checkStartActivityResult(result, intent);
        } catch (RemoteException e) {
        }
        return null;
    }

发现最终调用的是ActivityManagerNative类中的startActivity方法。ActivityManagerNative指的是Binder本地对象,这个类是抽象类,它的实现是ActivityManagerService;因此对于AMS的最终操作都会进入ActivityManagerService这个真正实现,接着调用startActivityAsUser方法,最终调用ActivityStackSupervisor类中的startActivityMayWait方法,ActivityStackSupervisor这个类低版本没有,在startActivityMayWait中调用startActivityLocked之后处理的都是Activity任务栈相关内容,这一系列ActivityStack和ActivityStackSupervisor纠缠不清的调用看下图就明白了;


调用流程图

ActivityStack类中的resumeTopActivityLocked方法中调用ActivityStack中的resumeTopActivityInnerLocked,然后在改方法中调用ActivityStackSupervisor类中的startSpecificActivityLocked方法:

void startSpecificActivityLocked(ActivityRecord r,
            boolean andResume, boolean checkConfig) {
        // Is this activity's application already running?
        ProcessRecord app = mService.getProcessRecordLocked(r.processName,
                r.info.applicationInfo.uid, true);

        r.task.stack.setLaunchTime(r);
        //如果App已经运行了,直接创建Activity
        if (app != null && app.thread != null) {
            try {
                if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
                        || !"android".equals(r.info.packageName)) {
                    // Don't add this if it is a platform component that is marked
                    // to run in multiple processes, because this is actually
                    // part of the framework so doesn't make sense to track as a
                    // separate apk in the process.
                    app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode,
                            mService.mProcessStats);
                }
                //真正启动Activity
                realStartActivityLocked(r, app, andResume, checkConfig);
                return;
            } catch (RemoteException e) {
                Slog.w(TAG, "Exception when starting activity "
                        + r.intent.getComponent().flattenToShortString(), e);
            }

            // If a dead object exception was thrown -- fall through to
            // restart the application.
        }
        //如果App还没有运行,创建ActivityThread的进程,然后创建Activity
        mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
                "activity", r.intent.getComponent(), false, false, true);
        //走到这里会先创建ActivityThread的进程,在ActivityThread的main方法中调用attach方法,
        //接着调用AMS的attachApplication方法,接着调用AMS的attachApplicationLocked,
        //接着调用ActivityStackSupervisor的attachApplicationLocked,
        //接着调用realStartActivityLocked方法创建Activity
    }

接着在改方法中调用realStartActivityLocked,人如其名,这个方法开始了真正的“启动Activity”:它调用了ApplicationThread的scheduleLaunchActivity方法,开始了真正的Activity对象创建以及启动过程。

ApplicationThread是ActivityThread中定义的内部类,继承ApplicationThreadNative(ApplicationThreadNative extends Binder implements IApplicationThread ),ApplicationThread实际上是一个Binder对象,是App所在的进程与AMS所在进程system_server通信的桥梁。

这里的scheduleLaunchActivity方法直接把启动Activity的任务通过一个消息转发给了主线程;我们查看Handler类对于这个消息的处理:

case LAUNCH_ACTIVITY: {
                    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
                    final ActivityClientRecord r = (ActivityClientRecord) msg.obj;

                    r.packageInfo = getPackageInfoNoCheck(
                            r.activityInfo.applicationInfo, r.compatInfo);
                    handleLaunchActivity(r, null);
                    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                } break;

可以看到,这里直接调用了ActivityThread的handleLaunchActivity方法,在这个方法内部有一句非常重要:

Activity a = performLaunchActivity(r, customIntent);

绕了这么多弯,我们的Activity终于被创建出来了!这个方法做了两件很重要的事情:
使用ClassLoader加载并通过反射创建Activity对象:

java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
r.intent.prepareToEnterProcess();
if (r.state != null) {
    r.state.setClassLoader(cl);
}

如果Application还没有创建,那么创建Application对象并回调相应的生命周期方法;

Application app = r.packageInfo.makeApplication(false, mInstrumentation);

Activity的启动过程到这里就结束了,这里调用了一系列方法,大多数方法我也不知道是干嘛的,留待以后研究,毕竟代码逻辑还是很复杂的。

Android