By

总阅读次

文章目录

Activity对于开发者来说最普通不过了,但是你有没有想过当我们看到一个Activity的之后系统内部到底是如何启动一个Activity的呢?比如新Activity对象是何时创建的?Activity的onCreate方法又是在何时被系统回调的呢?

首先来看一下流程图:

img

从Activity的startActivity()方法开始分析,有好几个重载方法,他们最终都会调用startActivityFriResult方法,在该方法中会执行Instrumentation的execStartActivity方法

1
2
3
4
5
6
7
public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target,
       Intent intent, int requestCode, Bundle options)
           ....省略代码...
int result = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(), intent, intent.resolveTypeIfNeeded
(who.getContentResolver()),token, target != null ? target.mEmbeddedID : null,
                   requestCode, 0, null, options);

从代码中可以启动Activity真正的实现由ActivityManagerNative.getDefault()的startActivity方法来完成,ActivityManagerNative(下面简称AMS)继承自Binder接口,因此AMS也是一个Binder,因此他也是一个Binder,它是IActivityManager类型的Binder对象.因此Activity的启动过程又转移到了AMS中.

在AMS的startActivity中又转移到了ActivityStacjSupervisor的startActivityMayWait方法中.

在该方法中又调用了startActivityLocked方法,接着调用了startActivityUncheckedLocked方法,又调用了ActivityStack的resumeTopActivityLocked.

这个时候启动已经从ActivityStackSupervisor转移到了ActivityStack,resumeTopActivityLocked调用了resumeTopActivityLocked方法,resumeTopActivityLocked方法,又调用了ActivityStackSupervisor的startSpecificActivityLocked方法

在该方法中调用了realStartActivityLocked方法,在该方法中有这么一段代码

1
2
3
4
5
app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
System.identityHashCode(r), r.info, new Configuration(mService.mConfiguration),
new Configuration(stack.mOverrideConfig), r.compat, r.launchedFromPackage,
task.voiceInteractor, app.repProcState, r.icicle, r.persistentState, results,
newIntents, !andResume, mService.isNextTransitionForward(), profilerInfo);

这段代码很重要,其中app.thread的类型为IApplicationThread,他继承了IInterface接口,所以他是一个Binder类型的接口.该接口内部包含了大量的启动、停止Activity的接口,此外还包含了启动和停止服务的接口,IApplicationThread这个Binder接口的实现者完成了大量的Activity以及Service启动停止相关的功能.他的实现者就是ActivityThread中的内部类ApplicationThread,

ApplicationThread继承了ApplicationThreadNative,而ApplicationThreadNative则继承了Binder并实现了IApplicationThread接口.

在ApplicationThreadNative的内部,还有一个ApplicationThreadProxy这个类为AIDL文件自动生成的代理类,种种迹象表明ApplicationThreadNative就是IAppilicationthread的实现者,由于ApplicationThreadNative被系统定义为抽象类,所以ApplicationThread就成了IApplicationthread最终的实现者.

绕了一大圈,Activity的启动过程最终回到了ApplicationThread中,ApplicationThread通过scheduleLaunchActivity方式来启动Activity,在该方法中通过发送一个启动Activity的消息交由Handler处理,这个Handler有个简洁的名字H,在H对LAUNCH_ACTIVITY这个消息进行处理可以知道,Activity启动过程由ActivityThread的handleLaunchActivity方法来实现

在该方法中最终通过performLaunchActivity方法完成了Activity对象的创建和启动过程,并且ActivityThread通过handleResumeActivity方法来调用被启动Activity的onResume这一生命周期.

performLaunchActivity方法主要完成了如下几件事

  1. 从ActivityClientRecord中获取待启动Activity的组建信息.
  2. 通过mInstrumentation的newActivity方法使用类加载器创建Activity对象
  3. 通过LoadedApk的makeApplication方法尝试创建Application对象
  4. 创建ContextImpl对象并通过Activity的attach方法来完成这些重要数据的初始化
  5. 调用Activity的onCreate方法
    mInstrumentation.callActivityOnCreate(activity, r.state);

至此Activity已经完成了启动过程

未经许可不得转载，转载请注明zilianliuxue的blog,本人保留所有版权。

文章目录