【学习】Android四大组件启动流程——Acticity的启动流程

四大组件的运行状态

四大组件中除了BroadcastReceiver以外，其他三种组件都必须要在AndroidManifest注册，对于它来说，它既可以在AndroidManifest由可以代码动态注册。
在调用方式上，Activity、Service、BroadcastReceiver都需要借助Intent，而ContentProvider无需借助Intent

Activity是展示型组件，扮演着一个前台界面的角色，用于向用户直接地展示一个界面，并且接受用户的输入信息从而进行交互。它是最重要的一种组件，对用户来说它就是应用的全部，因为其他三个都是不可感知的。它的启动有显式、隐式Intent，也可以具有特定的启动模式。它是可以停止的，实际开发中通过Activity的finish方法来结束一个Activity组件的运行。

Service是计算型组件，用于在后台执行一系列计算任务。Service有两种状态：启动状态和绑定状态。在启动状态时，Service内部做一些后台计算并且不需要和外界有直接的交互。尽管它用于后台计算，但它本身运行在主线程中，因此耗时的后台需要在单独的线程中去完成。处于绑定状态时，同样可以进行后台计算，但这个状态时外界很方便地和Service组件进行通信。服务也是可以停止的，不过需要灵活采用stopService和unBindService才能完全停止一个Service组件。

BroadcastReceiver是消息型组件，用于在不同组件甚至不同应用之间传递消息。静态注册在应用安装时会被系统解析，此种广播不需要应用启动就能收到相应广播。动态注册必须在应用启动才能注册并接收广播。在实际开发中可以通过Context的一系列方法来发送广播，发送和接收过程的匹配使用过广播接收者的< intent-filter>来描述。它不适合来执行耗时操作，它一般也不需要停止，也没有停止的概念。

ContentProvider是数据共享型组件，用于向其他组件乃至其他应用共享数据。它的内部需要实现增删改查四种操作，在它的内部维持着一份数据集合，这个数据集合既可以通过数据库来实现，也可以采用其他任何类型来实现，比如List和Map。增删改查方法需要处理好线程同步，因为这几个方法是在Binder线程池中调用的，另外它也不需要停止。

Activity的工作过程

启动流程图

注意：有弧形的方框只是支线，顺着矩形走才是主线

从startActivity方法开始分析，它有好几种重载方式，但它们最终都会调用startActivityForResult

mParent代表ActivityGroup，它最开始被用来在一个界面中嵌入多个子Activity，但已被废弃，系统推荐Fragment来代替ActivityGroup。代码中注意mMainThread.getApplicationThread()这个参数，它的类型是ApplicationThread，ApplicaitonThread是ActivityThread的一个内部类。看一下Instrumentation的execStartActivity方法

Activity由ActivityManagerNative.getDefault()的startActivity完成，AMS继承自ActivityManagerNative，而ActivityManagerNative继承自Binder并实现IActivityManager这个Binder接口，因此AMS也是一个Binder，它是IActivityManager的具体实现。由于ActivityManagerNative.getDefalut()其实是一个IActivityManager类型的Binder对象，因此它的具体实现是AMS。在ActivityManagerNative中，AMS这个Binder对象采用单例模式对外提供，Singleton是一个单例的封装类，第一次调用它的get方法它会通过create方法来初始化AMS这个Binder对象，在后续的调用中直接返回之前创建的对象。

如今的新代码虽有所不同，但思路是一样的。

此时启动过程转移到了AMS中，在分析其AMS的startActivity前，我们先看一下checkStartActivityResult(result,intent)

它的作用就是检查启动Activity的结果。当无法正确地启动一个Activity时，它就会抛出异常

继续分析AMS的startActivity

此时活动启动过程又转移到了ActivityStackSupervisor的startActivityMayWait方法中，在startActivityMayWait中又调用startActivityLocked，startActivityLocked又调用startActivityUncheckedLocked方法，startActivityUncheckedLocked又调用ActivityStack的resumeTopActivitesLocked方法，此时启动过程已经从ActivityStackSupervisor转移到了ActivityStack。

可以看出resumeTopActivityLocked调用了resumeTopActivityInnerLocked方法，resumeTopActivityInnerLocked又调用ActivityStackSupervisor的startSpecificActivityLocked方法

启动过程的传递顺序

它调用了realStartActivityLocked方法，在这个方法中有这么一段代码

app.thread的类型为IApplicationThread，声明如下

因为它继承了IInterface接口，所以它是一个Binder类型的接口，从IApplicationThread声明的接口方法可以看出，其内部包含了大量启动停止活动的接口，还包含了启动和停止服务的接口。这个Binder接口的实现者完成了大量和Activity以及Service启动停止相关的功能。

而它的实现者是ActivityThread中的内部类ApplicationThread

它继承了Binder并实现了IApplicationThread接口。

最终Activity的启动过程最终回到了ApplicationThread中，它通过scheduleLaunchActivity方法来启动Activity 在scheduleLaunchActivity方法中

它发送一个启动活动的信息交给Handler处理，Hnadler的名字是H。
sendMessage的作用是发送一个消息给H处理

在H类中

Activity的启动过程由ActivityThread的handleLaunchActivity方法来实现

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

performActivity完成的事情

1.从ActivityClientRecord中获取待启动的Activity的组件信息

2.通过Instrumentation的newActivity方法使用类加载器创建Activity对象

3.通过LoadApk的makeApplication方法来尝试创建Application对象（部分代码）

可以看出如果Application已经被创建过了，那么就不会再重复创建了，这也意味着一个应用只有一个Application对象。Application对象的创建也是通过Instrumentation来完成的，这个过程和Activity对象的创建一样，都是通过类加载器来实现。Application创建完毕后，系统会通过Instrumentation的callApplicationOnCreate来调用Application的onCreate方法

4.创建ContextImpl对象并通过Activity的attach方法来完成一些重要数据的初始化

它是Context的的具体实现，Context的大部分逻辑都是由ContextImpl来完成的。他通过Activity的attach方法和Activity建立关联，除此以外，在attach方法中活动还会完成Window的创建并建立自己和Window的关联，这样当Window接收到外部输入事件后就可以将事件传递给Activity

5.调用Activity的onCreate方法

mInstrumentation.callActivityOnCreate(activity,r.state)，由于onCreate已经被调用，意味着活动已经完成了整个启动过程

文末

我总结了一些Android核心知识点，以及一些最新的大厂面试题、知识脑图和视频资料解析。

需要的小伙伴直接点击文末小卡片免费领取哦，以后的路也希望我们能一起走下去。（谢谢大家一直以来的支持，需要的自己领取）

Android学习PDF+架构视频+面试文档+源码笔记

部分资料一览：

• 330页PDF Android学习核心笔记（内含8大板块）

• Android学习的系统对应视频

• Android进阶的系统对应学习资料

• Android BAT大厂面试题（有解析）

领取地址：点击下方CSDN官方认证卡片免费获取。