Android Activity启动流程

作者: MY1112 | 来源:发表于2019-02-25 16:58 被阅读0次

一、所涉及的类：

ZygoteInit
Zygote
SystemServer
PowerManagerService
DisplayManagerService
PackageManagerService
IBinder和Binder
源码地址：
platform/frameworks/base/+/android-7.1.1_r1/core/java/android/os/IBinder.java
platform/frameworks/base/+/android-7.1.1_r1/core/java/android/os/Binder.java

Binder通信是单向的。

IActivityManager
源码地址：
7.1: platform/frameworks/base/+/android-7.1.1_r1/core/java/android/app/
IActivityManager.java
9.0: platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
IActivityManager.aidl

Android7.1时还是接口类，8.0改成了aidl文件，由aidl文件生成接口，ActivityManagerNative，ActivityManagerProxy都implements了它，ActivityManagerService则extends IActivityManager.Stub

ActivityManagerNative(AMN)
源码地址：
7.1：platform/frameworks/base/+/refs/tags/androidct7.1_r25/core/java/android/app/
ActivityManagerNative.java
9.0：platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
ActivityManagerNative.java
ActivityManagerNative是ActivityManagerProxy和ActivityManagerService中间的桥梁。

对S端给ActivityManagerService继承，实现各种接口，包括binder通信的接口，这样就可以实现binder通信了，从而实现了AMS作为服务端的存在。

对C端的用ActivityManagerNative.getDefault返回ActivityManagerProxy对象。它是如何提供ActivityManagerProxy对象呢？api25使用的是ActivityManagerNative类的静态方法asInterface，26后则使用IActivityManager.Stub.asInterface(b)（其实26里已经没有了ActivityManagerProxy，这里只是理论上相当于ActivityManagerProxy对象）。

API25:

    /**
     * Retrieve the system's default/global activity manager.
     */
    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;
        }
    };

    /**
     * Cast a Binder object into an activity manager interface, generating
     * a proxy if needed.
     */
    static public IActivityManager asInterface(IBinder obj) {
        if (obj == null) {
            return null;
        }
        IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            return in;
        }
        return new ActivityManagerProxy(obj);
    }

API26:

/**
     * @hide
     */
    public static IActivityManager getService() {
        return IActivityManagerSingleton.get();
    }

    private static final Singleton<IActivityManager> IActivityManagerSingleton =
            new Singleton<IActivityManager>() {
                @Override
                protected IActivityManager create() {
                    final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
                    final IActivityManager am = IActivityManager.Stub.asInterface(b);
                    return am;
                }
            };

下面是C端里Instrumentation类调用到ActivityManagerProxy的地方：

public ActivityResult execStartActivity(
            Context who, IBinder contextThread, IBinder token, Activity target,
            Intent intent, int requestCode, Bundle options) {
        IApplicationThread whoThread = (IApplicationThread) contextThread;
        Uri referrer = target != null ? target.onProvideReferrer() : null;
        if (referrer != null) {
            intent.putExtra(Intent.EXTRA_REFERRER, referrer);
        }
        if (mActivityMonitors != null) {
            synchronized (mSync) {
                final int N = mActivityMonitors.size();
                for (int i=0; i<N; i++) {
                    final ActivityMonitor am = mActivityMonitors.get(i);
                    if (am.match(who, null, intent)) {
                        am.mHits++;
                        if (am.isBlocking()) {
                            return requestCode >= 0 ? am.getResult() : null;
                        }
                        break;
                    }
                }
            }
        }
        try {
            intent.migrateExtraStreamToClipData();
            intent.prepareToLeaveProcess(who);
            int result = ActivityManagerNative.getDefault()//这一行就是获取到ActivityManagerProxy对象
                .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) {
            throw new RuntimeException("Failure from system", e);
        }
        return null;
    }

ActivityManagerProxy(AMP, api26时完全删除)
源码地址：
7.1：platform/frameworks/base/+/android-7.1.1_r1/core/java/android/app/
ActivityManagerNative.java内
9.0：删除了

ActivityManagerProxy作为ActivityManagerService在C端(ActivityThread)的代理类，C端需要做什么工作只需要告诉该类，代码最后都会反馈AMS进行执行。

ActivityManagerService(AMS)
源码地址：
7.1：platform/frameworks/base/+/android-7.1.1_r1/services/core/java/com/android
/server/am/ActivityManagerService.java
9.0：platform/frameworks/base/+/android-9.0.0_r22/services/core/java/com/android
/server/am/ActivityManagerService.java

ActivityManagerService在api26以前是extends ActivityManagerNative, api26后extends IActivityManager.Stub，虽然有所改动，但是原理是一样的。客户端发送的各种指令都会到这里进行执行。

其作用：A、统一管理、调度、切换各应用程序的Activities,Service等四大组件； B、内存管理 C、进程管理

ActivityStartController
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/services/core/java/com/android
/server/am/ActivityStartController.java

这个类的作用官方是这样描述的：

Controller for delegating activity launches.
This class' main objective is to take external activity start requests and prepare them into
a series of discrete activity launches that can be handled by an {@link ActivityStarter}. It is
also responsible for handling logic that happens around an activity launch, but doesn't
necessarily influence the activity start. Examples include power hint management, processing through the pending activity list, and recording home activity launches.

从这个解释我们可以这样理解，这个也是一个控制器，控制着activity启动的分发。这个类主要接受一些外部传进来的activity start request，并把这些request准备成一系列可由ActivityStarter处理的离散的activity launches。而且在一个activity launch过程中，该类会处理一些相关的逻辑，但是这个处理并不会影响activity 的start。例如：处理电源提示管理、处理挂起的activity列表，记录各个home activity启动。

ActivityStarter
源码地址：
platform/frameworks/base/+/android9.0.0_r22/services/core/java/com/android
/server/am/ActivityStarter.java

这个类的作用官方是这样描述的：

Controller for interpreting how and then launching an activity.
This class collects all the logic for determining how an intent and flags should be turned into an activity and associated task and stack.

也就是说这个类是个解释性的控制器，解释的是如何启动activity，里面包含怎么样把intent和flags转换成一个activity，以及在这个转换过程中或者转换成功后所有涉及到task和stack 的逻辑都会有。

ActivityStackSupervisor
源码地址：
platform/frameworks/base/+/android9.0.0_r22/services/core/java/com/android
/server/am/ActivityStackSupervisor.java

这个类官方并没有做解释说明，从类名我们可以看出是ActivityStack的监督者。从该类的方法和属性，我们大致可以认为这个类的核心就是对ActivityStack进行管理，监视和管理ActivityStack的各个属性，且对外提供 ActivityStack对象。

ActivityStack
源码地址：
platform/frameworks/base/+/android9.0.0_r22/services/core/java/com/android
/server/am/ActivityStack.java

这个类的作用官方是这样描述的：

State and management of a single stack of activities.

ActivityManagerService使用它来管理系统中所有的Activities的状态， Activities使用stack的方式进行管理,它是S端真正负责做事的家伙。

ActivityManager

该类提供与Activity、Service和Process相关的信息以及交互方法，可以被看作是ActivityManagerService在客户端的辅助类。

IApplicationThread
源码地址：
7.1 platform/frameworks/base/+/android-7.1.1_r1/core/java/android/app/
IApplicationThread.java
9.0 platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
IApplicationThread.aidl

低版本是一个接口类，里面提供了大量的可以操作activity的方法，比如管理activity的生命周期管理，service 生命周期管理，provider管理，配置信息等，这样给别的类实现，最后让AMS调用。

ApplicationThreadNative
源码地址：
7.1: platform/frameworks/base/+/android-7.1.1_r1/core/java/android/app/
ApplicationThreadNative.java
9.0 删除

ApplicationThreadNative是一个桥梁的作用，连接着AMS和ApplicationThread。注意，在这个过程中，AMS是C 端，ApplicationThread则是S端。

对C端，AMS会在startActivity方法里调用ApplicationThreadNative的静态方法asInterface(IBinder) 生成一个ApplicationThreadProxy对象，然后把该proxy对象依次传到别的方法里进行使用。

@Override
public int startActivity(IBinder whoThread, String callingPackage,
        Intent intent, String resolvedType, Bundle bOptions) {
    checkCaller();
    int callingUser = UserHandle.getCallingUserId();
    TaskRecord tr;
    IApplicationThread appThread;
    synchronized (ActivityManagerService.this) {
        tr = mStackSupervisor.anyTaskForIdLocked(mTaskId);
        if (tr == null) {
            throw new IllegalArgumentException("Unable to find task ID " + mTaskId);
        }
        appThread = ApplicationThreadNative.asInterface(whoThread);
        if (appThread == null) {
            throw new IllegalArgumentException("Bad app thread " + appThread);
        }
    }
    return mActivityStarter.startActivityMayWait(appThread, -1, callingPackage, intent,
            resolvedType, null, null, null, null, 0, 0, null, null,
            null, bOptions, false, callingUser, null, tr);
}

对S端，ApplicationThread extends ApplicationThreadNative, 但是ApplicationThreadNative是抽象类， implements IApplicationThread接口，所以ApplicationThread 实现了IApplicationThread接口的众多方法，当然也包括binder的方法，这样就实现了binder通信，实现了ApplicationThread 作为服务端的存在。

ApplicationThreadProxy
源码地址：
7.1 platform/frameworks/base/+/android-7.1.1_r1/core/java/android/app/
ApplicationThreadNative.java
9.0 删除

7.1版本在ApplicationThreadNative文件内，但是不是内部类；9.0里已经删除了。

ApplicationThreadProxy作为ApplicationThread的代理对象存在于AMS内，然后AMS需要ApplicationThread 做什么工作都可以告诉ApplicationThreadProxy即可，程序的执行就会反应到ApplicationThread里。

ApplicationThread
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
ActivityThread.java

它是ActivityThread的内部类；

这个类没啥说的，最终实现了IApplicationThread和IBinder的方法，AMS发送指令到APP端会首先进入该类，是 AMS在app端执行的入口。

ActivityThread
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
ActivityThread.java

每个进程都有且只有一个ActivityThread，是客户端对几大控件进行管理的核心类，当ApplicationThread从AMS 获取到相关的事件时，很多方法都会进入ActivityThread里执行，最后由该类型进行下一步需要处理的分发。官方给的解释如下： This manages the execution of the main thread in anapplication process, scheduling and executing activities,broadcasts, and other operations on it as the activity manager requests.

H(Handler)
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
ActivityThread.java

是ActivityThread的内部类；

该类只是ApplicationThread和ActivityThread之间通信的一个桥梁而已，没有实际的业务意义。

Instrumentation
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/core/java/android/app/
Instrementation.java

该类主要是Application的管理，ActivityThread的很多方法最终都是通过这个类来完成的，类似一个大管家，管理着Activity等，是Activity状态和生命周期实际操作者，而ActivityThread更像一个老板，命令Instrementation干这个干那个。另外，每个Activity都会持有一个该类的对象，但是在一个进程里该类只有一个对象。

ActivityInfo
源码地址：
platform/frameworks/base/+/android-9.0.0_r22/core/java/android/content/pm/
ActivityInfo.java

该类最主要用来解析Manifest生成关于Activity信息对象

ActivityRecord
源码地址：
platform/frameworks/base/+/android9.0.0_r22/services/core/java/com/android/
server/am/ActivityRecord.java

该类是AMS进程里用于保存每个Activity的信息

主要包含的变量有：

A、环境变量：Activity的工作环境，例如进程名称、文件路径、数据路径、图标、主题等，这些信息一般比较固定。

...
 final String packageName; // the package implementing intent's component
 final String processName; // process where this component wants to run
...
private int labelRes;           // the label information from the package mgr.
private int icon;               // resource identifier of activity's icon.
private int logo;               // resource identifier of activity's logo.
private int theme;              // resource identifier of activity's theme.
private int realTheme;          // actual theme resource we will use, never 0.
private int windowFlags;        // custom window flags for preview window.
...

B、运行状态数据，例如idle、stop、finishing等；

// TODO: See if this is still needed.
boolean frontOfTask;    // is this the root activity of its task?
boolean launchFailed;   // set if a launched failed, to abort on 2nd try
boolean haveState;      // have we gotten the last activity state?
boolean stopped;        // is activity pause finished?
boolean delayedResume;  // not yet resumed because of stopped app switches?
boolean finishing;      // activity in pending finish list?
boolean deferRelaunchUntilPaused;   // relaunch of activity is being deferred until pause is completed

TaskRecord

栈记录

ProgressRecord
源码地址：
platform\frameworks/base/+/android9.0.0_r22/services/core/java/com/android/server/am/ProgressRecord.java

进程记录，记录了一个进程的相关信息。
一般情况下，一个应用程序（APK）运行会对应一个进程，而ProcessRecord就是用来记录一个进程的相关信息，主要包含以下几个方面：

A、进程文件信息：与该进程对应的APK文件的内部信息，如：

final ApplicationInfo info; // all about the first app in the process
...
final String processName;   // name of the process
// List of packages running in the process
final ArrayMap<String, ProcessStats.ProcessStateHolder> pkgList = new ArrayMap<>();
...

B、进程的内存状态信息：用于Linux系统的out of memory(OOM)情况的处理，当发生内存紧张时，Linux系统会根据进程的内存状态信息杀掉低优先级的进程，包括的变量有：

int maxAdj;                 // Maximum OOM adjustment for this process
int curRawAdj;              // Current OOM unlimited adjustment for this process
int setRawAdj;              // Last set OOM unlimited adjustment for this process
int curAdj;                 // Current OOM adjustment for this process
int setAdj;                 // Last set OOM adjustment for this process
int verifiedAdj;            // The last adjustment that was verified as actually being set

C、进程中包含的Activity、ContentProvider、Service、Receiver等，如下：

// all activities running in the process
final ArrayList<ActivityRecord> activities = new ArrayList<>();
// any tasks this process had run root activities in
final ArrayList<TaskRecord> recentTasks = new ArrayList<>();
// all ServiceRecord running in this process
final ArraySet<ServiceRecord> services = new ArraySet<>();
// services that are currently executing code (need to remain foreground).
final ArraySet<ServiceRecord> executingServices = new ArraySet<>();
// All ConnectionRecord this process holds
final ArraySet<ConnectionRecord> connections = new ArraySet<>();
// all IIntentReceivers that are registered from this process.
final ArraySet<ReceiverList> receivers = new ArraySet<>();
// class (String) -> ContentProviderRecord
final ArrayMap<String, ContentProviderRecord> pubProviders = new ArrayMap<>();
// All ContentProviderRecord process is using
final ArrayList<ContentProviderConnection> conProviders = new ArrayList<>();

LoadedApk
WindowManager

二、关系网

1、ActivityManagerService、ActivityManagerNative、ActivityManagerProxy和IActivityManager这几者之间的关系(不同API版本略微有所差别)

在介绍类的时候已经说了一部分，在此再完善一下。我们可以先看一下UML图：
https://www.processon.com/diagraming/5c1c3e54e4b0b71ee5039696

再看下图(这个图从网上copy下来的，有点老)，用getRunningServices这个方法举例：

AMS涉及类几者间关系.png

从以上两图我们可以梳理一下：

A、如果是老版本，App进程的ActivityThread类（C端）直接通过ActivityManagerNative.getDefault()方法获取到ActivityManagerProxy对象，然后通过该对象调用各种方法，前面我们提到ActivityManagerProxy是AMS在App进程（C端）的代理而已，所以程序执行至此进入AMS进程（S端），会触发AMS重写的该方法；同理，App进程的ActivityManager类（C端）也一样是通过ActivityManagerNative.getDefault()获取到ActivityManagerProxy对象，然后操作AMS进程（S端）代码。例如：App进程的ActivityThread里调用ActivityManagerNative.getDefault().activityResumed(token)，后续会执行到AMS进程的activityResumed方法;

B、如果是新版本，AMS换成了AIDL方式实现IActivityManager里的众方法，而ActivityManagerProxy已经删除了，改成了由ActivityManager（C端）进行过度性的管理操作S端代码，也就是说，App进程（C端）想调用AMS进程的方法都需要经过ActivityManager类，而不是用ActivityManagerNative.getDefault()获取代理对象。 App进程的ActivityThread类（C端）通过调用ActivityManager.getService获取AMS进程（S端）在C端的对象（其实这个过程原理类似获取到ActivityManagerProxy），然后通过这个对象操作AMS进程各种方法。例如：App进程的ActivityThread里调用ActivityManager.getService().activityResumed(token)，后续会执行到AMS进程的activityResumed方法;

C、(1). AMS继承自ActivityManagerNative(AMN)，并实现了Watchdog.Monitor和BatteryStatsImpl.BatteryCallback接口

(2). AMN继承Java的Binder类，同时实现了IActivityManager接口，即AMN将作为Binder通信的服务端为用户提供支持

(3). 在ActivityManagerNative类中定义了内部类ActivityManagerProxy，该类同样实现了IActivityManager接口，将作为客户端使用的服务端代理

(4). 其它进程将使用ActivityManager来使用AMS的服务。ActivityManager通过AMN提供的getDefault接口得到ActivityManagerProxy，然后再以Binder通信的方式调用AMS的接口

(5). 从这里我们可以看出应用进程通过binder的方式和systemserver进程进行通信

2、ApplicationThread、ApplicationThreadNative、ApplicationThreadProxy和IApplicationThread这几者之间的关系(不同API版本略微有所差别)

在介绍类的时候已经说了一部分，在此再完善一下。我们可以先看一下UML图：

https://www.processon.com/diagraming/5c1ca912e4b05e0d063a974d

A、如果是老版本，AMS进程(C端)会持有一个App进程（S端）ApplicationThread的一个代理对象，也就是ApplicationThreadProxy，这个对象是App进程（S端） ApplicationThread调用AMS进程的方法自己传过去一个IBinder，AMS调用ApplicationThreadNative的静态方法asInterfase(IBinder binder)生成的。这个过程就完成了App进程把自己的一个代理对象传递到AMS进程，实现了AMS进程与App进程的通信通道。这以后，AMS进程有什么需要App进程做的事儿就通过这个代理对象通知App进程即可。

B、如果是新版本，ApplicationThreadNative和ApplicationThreadProxy都不存在了，IApplicationThread也由接口变成了IApplicationThread.aidl文件，App进程里的ApplicationThread改成extends 由IApplicationThread 自动生成的IApplicationThread.Stub,并override其各个方法。App进程把IApplicationThread对象传递到AMS进程后，AMS会通过asBinder获取到ApplicationThread在AMS中的对象（这个过程相当于老版本的获取一个Proxy），作为AMS进程和App进程通信的通道，AMS进程通过这个对象可以操作App进程的相关方法。

C、 (1)、ActivityThread作为应用进程的主线程代表，在其中持有ApplicationThread

(2)、ApplicationThread继承ApplicationThreadNative（ATN），当AMS与应用进程通信时，ApplicationThread 将作为Binder通信的服务端。

(3)、ATN继承自Binder并实现了IApplicationThread接口，即ATN将作为Binder通信的服务端为用户提供支持

(4)、ApplicationThreadProxy实现了IApplicationThread接口，所以它将作为客户端使用的服务端代理

(5)、AMS与应用进程通信时，通过ApplicationThreadNative获取应用进程对应的ApplicationThreadProxy对象，通过ApplicationThreadProxy对象，将调用信息通过Binder传递到ActivityThread中的 ApplicationThread

(6)、从这里我们可以出systemserver通过binder的方式和应用程序进行通信

3、ActivityManagerService、ActivityStartController、ActivityStarter、ActivityStackSupervisor、ActivityStack这几者之间的关系

首先要说明的是，这几个类都是运行在ams进程里的，是ams进程涉及到activity以及相关类管理的操作

A、 AMS作为activity管理的入口，会持有ActivityStartController对象；

B、 ActivityStartController会obtain一个ActivityStarter对象，然后把这个ActivityStarter对象给外部使用，因为ActivityStarter是Builder模式的，所以其他地方调用这个ActivityStarter对象时可以往其中设置很多属性（这些属性都是关于activity状态管理的）；

C、在给ActivityStarter设置多个属性后会执行其execute()方法，该方法是执行startActivity入口，然后里面执行startActivityMayWait或者startActivity方法(startActivityMayWait最后也走到startActivity方法)；

D、 ActivityStarter.startActivity()方法里会调用ActivityStackSupervisor的一个对象，用这个对象进行一些检测或者处理一些包括但不限于状态和权限等属性：ActivityStackSupervisor.isInAnyStackLocked()，ActivityStackSupervisor.checkStartAnyActivityPermission()，ActivityStackSupervisor.resolveIntent()，ActivityStackSupervisor.resolveActivity()等，最后为startActivity准备好各个合适条件和参数，以便下一步；

E、在D的基础上，会走到ActivityStarter.startActivityUnchecked()方法，然后这个方法里会调用到ActivityStack.startActivityLocked()方法，最终无论如何会调用ActivityStackSupervisor.resumeFocusedStackTopActivityLocked()方法，同时在这个过程中ActivityStackSupervisor会记录这些执行过程中关于activity statck状态和其他的状态，例如方法：sendPowerHintForLaunchStartIfNeeded，resumeFocusedStackTopActivityLocked，updateUserStackLocked，handleNonResizableTaskIfNeeded等；

F、 ActivityStackSupervisor的resumeFocusedStackTopActivityLocked()又调用ActivityStact.resumeTopActivityUncheckedLocked()方法；

进入ActivityStact类后，就算是AMS进程关于管理activity的各种状态和生命周期的末端了，如果继续执行就会调用到App进程了。只是在9.0的时候，android又引入了ClientTransactionHandler来辅助管理Activity的生命周期，这个Handler会发送EXECUTE_TRANSACTION消息到ActivityThread.H里面继续处理。

从以上的这么多步骤可以看出，这几个类之间的关系既简单又复杂，简单的就是处理关于activity的一些参数，反正就是为了能启动activity，理论上这些类的逻辑可以在一个类里完成(前期版本就没这么多类)，复杂就是这个参数比较多，处理的逻辑复杂。

4、Activity、ActivityThread、ApplicationThread、H(Handler)和Instrumentation这几者之间的关系

首先要说明的是，这几个类都是运行在app进程里的，是开发者可以直观感受到的activity各个生命周期和状态管理的类。

A、Activity的startActivity会先经过Instrumentation的方法跨进程调用AMS的方法，也就是C->S;

B、startActivity不管是否是启动一个新的App(包含Activity)，当前的Activity都要进入pause生命周期，而进入这个pause生命是由AMS发起的，AMS执行pause时会通过其持有的App进程的代理类ApplicationThread通知App进程，这个时候程序又回到了App进程的ApplicationThread。

C、在B的基础上，ApplicationThread执行到schedulePauseActivity，而schedulePauseActivity调用到了H（Handler），通过这个H，把要pause activity这个事件分发到ActivityThread里（我们知道，ApplicationThread和H都是ActivityThread的内部类，ActivityThread持有ApplicationThread和H的对象）

D、在C的基础上，ActivityThread最后会走到performPauseActivityIfNeeded，这个方法会调用Instrumentation的callActivityOnPause,然后这个时候会反馈到我们开发的API上，执行到我们开发者经常看到的onPause生命周期方法。

E、在D执行完成后，还要把这个结果反馈到AMS（也就是说APP端执行了onPause了，你还得告诉AMS执行完了，整个流程怪怪的，pause是AMS发起的，最后还要反馈回来，为什么不直接在AMS那边进行处理呢？也许这就是C/S的魅力吧），至于如何把APP进行的pause反馈到AMS进程的，就要看这一行代码：ActivityManage.getService().activityPaused(token).

F、当前Activity pause以后，如果是新启动一个App(也就是新开一个进程)，会从Zygote孵化一个新的Process，Process调用ActivityThread的main()方法，然后进入attach()方法，在attach()方法里会把当前进程通过bingApplication()方法通知AMS进程；

G、当程序走到AMS进程，AMS会做2件事儿，一是调用App进程在AMS进程的代理ApplicationThread的bindApplication()方法，然后这个方法通过H(Handler)发送一个Message，从而调用ActivityThread的handleBindApplication()方法，ActivityThread的handleBindApplication()方法又调用Instrementation的init()方法和onCreate()方法，这个时候新进程的Application就创建起来了。二是在AMS启动Application的同时(也可理解为在Application之后，因为Activity创建肯定是在Applicaiton后)AMS内部会执行一系列的操作(例如调用ActivityStack构建ActivityRecord等)通过调用ApplicationThread的scheduleLaunchActivity()方法，该方法同样是通过H(Handler)发送一个Message，通知到ActivityThread，调用ActivityThread的handleLaunchActivity()方法，该方法又调用performLaunchActivty(),performLaunchActivty()最后又调用Instrementation的callActivityOnCreate()，然后程序开始进入Activity的onCreate()生命周期，至此Activity在App端启动起来了。

H、在上个流程里，ActivityThread在调用Instrementation的callActivityOnCreate()之前，会调用Activity的attach()方法，在这个方法里，会初始化关于Window相关的信息(例如PhoneWindow对象， WindowManager对象，DecorView对象等)，方便下一步setContentView()，这个是题外话。

从以上的数个步骤可以看出，在新启动一个App进程中这几个类的关系，我们大致总结一下：1.ApplicationThread是AMS和ActivityThread之间通信的桥梁，AMS要执行的事情都会通过ApplicationThread告诉App进程的ActivityThread；2.H(Handler)是ApplicationThread和ActivityThread之间通信的桥梁，ApplicationThread要执行的事情都会通过H分发到ActivityThread里进行处理；3.Instrumentation是ActivityThread和Activity之间通信的强烈，ActivityThread要做的很多事情都通过Instrumentation表现在Activity里。

（三）、进程启动流程之时序图：

在上面各种类的介绍和关系网分析中，我们已经说了很多关于Activity启动流程的代码，这里是再系统地完善一下。先看一张图片，这个是基于9.0画的时序图

activity_start.png

大家先勉强看看吧，我解释一下，一个是本人对时序图部分概念不是很了解，画的只能说是够看，另外一个就是确实导不出更清晰的图片了。
这个图基本能代表9.0activity启动的流程走向了，跟android之前版本(8.0，7.0)的总体流程差不多，只是里面的类或增或改了一部分，换汤不换药。大家也可以看看之前别人写的文章，刚开始可能会比较懵逼，后面基本就通了。

（四）、进程启动流程之代码分析：

最后要感谢：
https://juejin.im/entry/5abdcdea51882555784e114d
https://blog.csdn.net/pihailailou/article/details/78545391
http://haiolv.github.io/2016/06/13/Android-Activity%E5%90%AF%E5%8A%A8%E8%BF%87%E7%A8%8B/
https://www.jianshu.com/p/89fd44083c1c

Android Activity启动流程

一、所涉及的类：

二、关系网

1、ActivityManagerService、ActivityManagerNative、ActivityManagerProxy和IActivityManager这几者之间的关系(不同API版本略微有所差别)

2、ApplicationThread、ApplicationThreadNative、ApplicationThreadProxy和IApplicationThread这几者之间的关系(不同API版本略微有所差别)

3、ActivityManagerService、ActivityStartController、ActivityStarter、ActivityStackSupervisor、ActivityStack这几者之间的关系

4、Activity、ActivityThread、ApplicationThread、H(Handler)和Instrumentation这几者之间的关系

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读