Activity启动过程简单分析

时间：2022-09-28 05:03:42

前言

看了大半天的《Android开发艺术探索》的Activity启动过程，总算看完，不得不感叹android源码也太复杂了，跳来跳去，头都大了，不过，一番努力，总算有所了解。这本书的android源码是基于5.0的，我最开始用7.0的源码查看，结果发现有部分不一样，找了半天，都没有找到出口，最后不得不换回5.0，才找到出口，还是太菜了。。。。接下来，我就根据这本书写下自己的总结理解过程。

Activity启动

通常一个Activity的启动可以是用户点击图标，然后进入应用主Activity。还有就是在程序中调用StartActivity或StartActivityForResult，都可以完成Activity的创建。这些对于Android开发者都是很平常的事，有时候根本没想到内部工作过程如此复杂，以至于我们很少关心。但是对于一个想成为高级开发者的程序员来说，了解这些内部工作过程的基本原理是必不可少的。

对于第一种过程 暂且不分析，直接分析第二种startActivity(intent)，第一种能力不够尚且不多做解释。

Activity有好几种重载方式，但查看源码最终会调用到
startActivityForResult(Intent intent, int requestCode, @Nullable Bundle options)
它的实现如下

Activity启动过程简单分析

上面代码中只需要关注mParent == null这段代码，intent被转移到了mInstrumentation.execStartActivity方法，所以接下来看Instrumentation的execStartActivity方法。

Activity启动过程简单分析

代码都好长，而且不需要都看（也看不懂），这是部分截图，可以看见intent，被转移到了ActivityManagerNative.getDefault() .startActivity方法中，所有Activity的启动真正实现由ActivityManagerNative.getDefault()的startActivity完成。在ActivityManagerNative中，
AMS的获取是通过一个单例类来得到的。Singleton是一个单例的封装类，第一次调用get会通过create方法来初始化AMS这个Binder对象，以后调用会直接返回这个Binder对象。

    static public IActivityManager getDefault() {
return gDefault.get();
    }

private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");
if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);
if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
return am;
        }
    };

ActivityManagerService（简称AMS）继承自ActivityManagerNative，而ActivityManagerNative继承自Binder并实现了IActivityManager接口，所以Activity的启动又转移到了AMS的startActivity方法。

Activity启动过程简单分析

继续查看AMS的startActivity方法，Activity启动过程又转移到了ActivityStackSupervisor的startActivityMayWait方法，在startActivityMayWait中调用了startActivityLocked（927行左右），而在startActivityLocked方法中，又调用了startActivityUncheckedLocked（1490行左右，intent的信息封装到了 ActivityRecord方法），其中startActivityUncheckedLocked又调用了ActivityStack的resumeTopActivityLocked（1957行左右）方法，这个时候Activity的启动过程由ActivityStackSupervisor转移到了ActivityStack。然后查看resumeTopActivityLocked方法。

Activity启动过程简单分析

在这个方法里面调用了resumeTopActivityInnerLocked方法，然后在resumeTopActivityInnerLocked中调用了ActivityStackSupervisor的startSpecificActivityLocked（1882行左右），此时Activity的创建又由ActivityStackSupervisor转回到了ActivityStack类。在startSpecificActivityLocked中调用了realStartActivityLocked方法，然后查看该方法中一部分

Activity启动过程简单分析

这段代码很重要，其中app.thread的类型为一个接口IApplicationThread，查看该接口可以看到其中包含了大量的启动，停止Activity的接口。而IApplicationThread的实现者是ActivityThread的内部类ApplicationThread，所以Activity又转移到了ApplicationThread的scheduleLaunchActivity方法执行。

// we use token to identify this activity without having to send the
        // activity itself back to the activity manager. (matters more with ipc)
        public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
                ActivityInfo info, Configuration curConfig, CompatibilityInfo compatInfo,
                IVoiceInteractor voiceInteractor, int procState, Bundle state,
                PersistableBundle persistentState, List<ResultInfo> pendingResults,
                List<Intent> pendingNewIntents, boolean notResumed, boolean isForward,
                ProfilerInfo profilerInfo) {

            updateProcessState(procState, false);

            ActivityClientRecord r = new ActivityClientRecord();

            r.token = token;
            r.ident = ident;
            r.intent = intent;
            r.voiceInteractor = voiceInteractor;
            r.activityInfo = info;
            r.compatInfo = compatInfo;
            r.state = state;
            r.persistentState = persistentState;

            r.pendingResults = pendingResults;
            r.pendingIntents = pendingNewIntents;

            r.startsNotResumed = notResumed;
            r.isForward = isForward;

            r.profilerInfo = profilerInfo;

            updatePendingConfiguration(curConfig);

            sendMessage(H.LAUNCH_ACTIVITY, r);
        }

在该方法中，就是发送了一个消息给Handler处理，其中处理消息的Handler为H。sendMessage(H.LAUNCH_ACTIVITY, r)作用就是发送一个消息给H处理。然后看下Handler H对消息的处理，如下所示：

Activity启动过程简单分析

从Handler 对LAUNCH_ACTIVITY的消息处理可以看见，Activity的启动由ActivityThread的handleLaunchActivity来实现，他的源码如下：

 private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
if (localLOGV) Slog.v(
            TAG, "Handling launch of " + r);

        Activity a = performLaunchActivity(r, customIntent);

if (a != null) {
            r.createdConfig = new Configuration(mConfiguration);
            Bundle oldState = r.state;
            handleResumeActivity(r.token, false, r.isForward,
                    !r.activity.mFinished && !r.startsNotResumed);

          ....  
    }

可以看见 performLaunchActivity 完成了最终Activity的创建和启动，而handleResumeActivity来调用onResume这一生命周期方法，完成页面的可交互性。

performLaunchActivity做了如下几件事

1 . 从ActivityClientRecord中获取待启动的Activity组件信息
2 . 通过Instrumentation的 newActivity方法使用类加载器创建Activity对象
3 . 通过LoadedApk的makeApplcation方法尝试创建Application对象
4 . 创建ContextImpl对象并且通过Activity的attach方法完成重要数据初始化。
5 .调用Activity的onCreate方法

最后

能力不够，以后有能力继续总结。
标签：

相关文章