从用户手指点击桌面上的应用图标到屏幕上显示出应用主Activity界面而完成应用启动，快的话往往都不需要一秒钟，但是这整个过程却是十分复杂的，其中涉及了Android系统的几乎所有核心知识点。同时应用的启动速度也绝对是系统的核心用户体验指标之一，多少年来，无论是谷歌或是手机系统厂商们还是各个Android应用开发者，都在为实现应用打开速度更快一点的目标而不断努力。但是要想真正做好应用启动速度优化这件事情，我想是必须要对应用启动的整个流程有充分的认识和理解的，所以无论作为Android系统或应用开发者，都有必要好好的学习和了解一下这个过程的。网上有很多介绍应用启动流程源码的文章，但是总感觉大多数都不太全面，很多只是介绍了应用启动过程中的部分流程，而没有总体清晰的认识应用启动过程的总体脉络与系统架构设计思想。所以本文将结合笔者多年来的工作经历，结合systrace分析工具，基于最新Android R AOSP源码完整的分析一下这个从用户手指触控点击屏幕应用图标到应用界面展示到屏幕上的整个应用启动过程，也是对之前所做所学的一个总结与归纳。

Android 系统是由事件驱动的，而 input 是最常见的事件之一，用户的点击、滑动、长按等操作，都属于 input 事件驱动，其中的核心就是 InputReader 和 InputDispatcher。InputReader 和 InputDispatcher 是跑在 SystemServer进程中的两个 native 循环线程，负责读取和分发 Input 事件。整个处理过程大致流程如下：

用一张图描述整个过程大致如下：

从桌面点击应用图标启动应用，system_server的native线程InputReader首先负责从EventHub中利用linux的epolle机制监听并从屏幕驱动读取上报的触控事件，然后唤醒另外一条native线程InputDispatcher负责进行进一步事件分发。InputDispatcher中会先将事件放到InboundQueue也就是“iq”队列中，然后寻找具体处理input事件的目标应用窗口，并将事件放入对应的目标窗口OutboundQueue也就是“oq”队列中等待通过SocketPair双工信道发送到应用目标窗口中。最后当事件发送给具体的应用目标窗口后，会将事件移动到WaitQueue也就是“wq”中等待目标应用处理事件完成，并开启倒计时，如果目标应用窗口在5S内没有处理完成此次触控事件，就会向system_server报应用ANR异常事件。以上整个过程在Android系统源码中都加有相应的systrace tag，如下systrace截图所示：

接着上面的流程继续往下分析：当input触控事件传递到桌面应用进程后，Input事件到来后先通过enqueueInputEvent函数放入“aq”本地待处理队列中，并唤醒应用的UI线程在deliverInputEvent的流程中进行input事件的具体分发与处理。具体会先交给在应用界面Window创建时的ViewRootImpl#setView流程中创建的多个不同类型的InputStage中依次进行处理（比如对输入法处理逻辑的封装ImeInputStage），整个处理流程是按照责任链的设计模式进行。最后会交给ViewPostImeInputStage中具体进行处理，这里面会从View布局树的根节点DecorView开始遍历整个View树上的每一个子View或ViewGroup界面进行事件的分发、拦截、处理的逻辑。最后触控事件处理完成后会调用finishInputEvent结束应用对触控事件处理逻辑，这里面会通过JNI调用到native层InputConsumer的sendFinishedSignal函数通知InputDispatcher事件处理完成，从触发从"wq"队列中及时移除待处理事件以免报ANR异常。

桌面应用界面View中在连续处理一个ACTION_DOWN的TouchEvent触控事件和多个ACTION_MOVE，直到最后出现一个ACTION_UP的TouchEvent事件后，判断属于onClick点击事件，然后透过ActivityManager Binder调用AMS的startActivity服务接口触发启动应用的逻辑。从systrace上看如下图所示：

接着上一节继续往下看，桌面进程收到input触控事件并处理后binder调用框架AMS的的startActivity接口启动应用，相关简化代码如下：

在执行startActivityInner启动应用逻辑中，AMS中的Activity栈管理的逻辑，检查发现当前处于前台Resume状态的Activity是桌面应用，所以第一步需要通知桌面应用的Activity进入Paused状态，相关简化代码逻辑如下：

桌面应用进程这边执行收到pause消息后执行Activity的onPause生命周期，并在执行完成后，会binder调用AMS的activityPaused接口通知系统执行完activity的pause动作，相关代码如下：

AMS这边收到应用的activityPaused调用后，继续执行启动应用的逻辑，判断需要启动的应用Activity所在的进程不存在，所以接下来需要先startProcessAsync创建应用进程，相关简化代码如下：

以上过程从systrace上看，如下图所示：

2.确认桌面activityPaused状态之后，开始创建应用进程：

接上一小节的分析可以知道，Android应用进程的启动是被动式的，在桌面点击图标启动一个应用的组件如Activity时，如果Activity所在的进程不存在，就会创建并启动进程。Android系统中一般应用进程的创建都是统一由zygote进程fork创建的，AMS在需要创建应用进程时，会通过socket连接并通知到到zygote进程在开机阶段就创建好的socket服务端，然后由zygote进程fork创建出应用进程。整体架构如下图所示：

我们接着上节中的分析，继续从AMS#startProcessAsync创建进程函数入手，继续看一下应用进程创建相关简化流程代码：

在ZygoteProcess#startViaZygote中，最后创建应用进程的逻辑：

从systrace上看这个过程如下：

其实早在系统开机阶段，zygote进程创建时，就会在ZygoteInit#main入口函数中创建服务端socket，并预加载系统资源和框架类（加速应用进程启动速度），代码如下：

继续往下看ZygoteServer#runSelectLoop如何监听并处理AMS客户端的请求：

以上过程从systrace上看如下图所示：

接上一节中的分析，zygote进程监听接收AMS的请求，fork创建子应用进程，然后pid为0时进入子进程空间，然后在 ZygoteInit#zygoteInit中完成进程的初始化动作，相关简化代码如下：

应用进程启动后，初始化过程中主要依次完成以下几件事情：

我们继续看RuntimeInit#applicationInit简化的代码流程：

我们继续往下看ActivityThread的main函数中又干了什么：

可以看到进程ActivityThread#main函数初始化的主要逻辑是：

以上初始化过程。从systrace上看如下图所示：

接上一节的分析，我们知道应用进程创建后会通过反射创建ActivityThread对象并执行其main函数，进行主线程的初始化工作：

主线程初始化完成后，主线程就有了完整的 Looper、MessageQueue、Handler，此时 ActivityThread 的 Handler 就可以开始处理 Message，包括 Application、Activity、ContentProvider、Service、Broadcast 等组件的生命周期函数，都会以 Message 的形式，在主线程按照顺序处理，这就是 App 主线程的初始化和运行原理，部分处理的 Message 如下

主线程初始化完成后，主线程就进入阻塞状态，等待 Message，一旦有 Message 发过来，主线程就会被唤醒，处理 Message，处理完成之后，如果没有其他的 Message 需要处理，那么主线程就会进入休眠阻塞状态继续等待。可以说Android系统的运行是受消息机制驱动的，而整个消息机制是由上面所说的四个关键角色相互配合实现的（Handler、Looper、MessageQueue、Message），其运行原理如下图所示：

从前面4.2.3小结中的分析我们知道，应用进程启动初始化执行ActivityThread#main函数过程中，在开启主线程loop消息循环之前，会通过Binder调用系统核心服务AMS的attachApplication接口将自己注册到AMS中。下面我们接着这个流程往下看，我们先从systrace上看看AMS服务的attachApplication接口是如何处理应用进程的attach注册请求的：

我们继续来看相关代码的简化流程：

从上面的代码流程可以看出：AMS服务在执行应用的attachApplication注册请求过程中，会通过oneway类型的binder调用应用进程ActivityThread#IApplicationThread的bindApplication接口，而bindApplication接口函数实现中又会通过往应用主线程消息队列post BIND_APPLICATION消息触发执行handleBindApplication初始化函数，从systrace看如下图所示：

我们继续结合代码看看handleBindApplication的简化关键流程：

在ActivityThread#**handleBindApplication初始化过程中在应用主线程中主要完成如下几件事件**：

下面我们结合代码重点看看APK Dex文件的加载和Resource资源的加载流程。

从以上代码可以看出：在创建Application的Context对象后会立马尝试去加载APK的Resource资源，而在这之前需要通过LoadedApk去创建类加载器ClassLoader对象，而这个过程最终就会触发Art虚拟机加载应用APK的dex文件，从systrace上看如下图所示：

具体art虚拟机加载dex文件的流程由于篇幅所限这里就不展开讲了，这边画了一张流程图可以参考一下，感兴趣的读者可以对照追一下源码流程：

从以上代码可以看出：系统对于应用APK文件资源的加载过程其实就是创建应用进程中的Resources资源对象的过程，其中真正实现APK资源文件的I/O解析作，最终是借助于AssetManager中通过JNI调用系统Native层的相关C函数实现。整个过程从systrace上看如下图所示：

我们回到6.1小结中，看看AMS在收到应用进程的attachApplication注册请求后，先通过oneway类型的binder调用应用及进程的IApplicationThread#bindApplication接口，触发应用进程在主线程执行handleBindeApplication初始化操作，然后继续执行启动应用Activity的操作，下面我们来看看系统是如何启动创建应用Activity的，简化代码流程如下：

从以上代码分析可以看到，框架system_server进程最终是通过ActivityStackSupervisor#realStartActivityLocked函数中，通过LaunchActivityItem和ResumeActivityItem两个类的封装，依次实现binder调用通知应用进程这边执行Activity的Launch和Resume动作的，我们继续往下看相关代码流程：

从上面代码可以看出，应用进程这边在收到系统binder调用后，在主线程中创建Activiy的流程主要步骤如下：

从systrace上看整个过程如下图所示：

从上面代码可以看出，应用进程这边在接收到系统Binder调用请求后，在主线程中Activiy Resume的流程主要步骤如下：

从systrace上看整个过程如下图所示：

接上一节的分析，应用主线程中在执行Activity的Resume流程的最后，会创建ViewRootImpl对象并调用其setView函数，从此并开启了应用界面UI布局与绘制的流程。在开始讲解这个过程之前，我们先来整理一下前面代码中讲到的这些概念，如Activity、PhoneWindow、DecorView、ViewRootImpl、WindowManager它们之间的关系与职责，因为这些核心类基本构成了Android系统的GUI显示系统在应用进程侧的核心架构，其整体架构如下图所示：

从以上代码可以看出ViewRootImpl的setView内部关键流程如下：

我们顺着ViewRootImpl的requestLayout动作继续往下看界面绘制的流程代码：

Choreographer 的引入，主要是配合系统Vsync垂直同步机制（Android“黄油计划”中引入的机制之一，协调APP生成UI数据和SurfaceFlinger合成图像，避免Tearing画面撕裂的现象），给上层 App 的渲染提供一个稳定的 Message 处理的时机，也就是 Vsync 到来的时候 ，系统通过对 Vsync 信号周期的调整，来控制每一帧绘制操作的时机。Choreographer 扮演 Android 渲染链路中承上启下的角色：

Choreographer在收到CALLBACK_TRAVERSAL类型的绘制任务后，其内部的工作流程如下图所示：

从以上流程图可以看出：ViewRootImpl调用Choreographer的postCallback接口放入待执行的绘制消息后，Choreographer会先向系统申请APP 类型的vsync信号，然后等待系统vsync信号到来后，去回调到ViewRootImpl的doTraversal函数中执行真正的绘制动作（measure、layout、draw）。这个绘制过程从systrace上看如下图所示：

我们接着ViewRootImpl的doTraversal函数的简化代码流程往下看：

从上面的代码流程可以看出，ViewRootImpl中负责的整个应用界面绘制的主要流程如下：

以上绘制过程从systrace上看如下图所示：

借用一张图来总结应用UI绘制的流程，如下所示：

截止到目前，在ViewRootImpl中完成了对界面的measure、layout和draw等绘制流程后，用户依然还是看不到屏幕上显示的应用界面内容，因为整个Android系统的显示流程除了前面讲到的UI线程的绘制外，界面还需要经过RenderThread线程的渲染处理，渲染完成后，还需要通过Binder调用“上帧”交给surfaceflinger进程中进行合成后送显才能最终显示到屏幕上。本小节中，我们将接上一节中ViewRootImpl中最后draw的流程继续往下分析开启硬件加速情况下，RenderThread渲染线程的工作流程。由于目前Android 4.X之后系统默认界面是开启硬件加速的，所以本文我们重点分析硬件加速条件下的界面渲染流程，我们先分析一下简化的代码流程：

从上面的代码可以看出，硬件加速绘制主要包括两个阶段：

我们先来看看第一阶段构建绘制命令树的代码简化流程：

从以上代码可以看出，构建绘制命令树的过程是从View控件树的根节点DecorView触发，递归调用每个子View节点的updateDisplayListIfDirty函数，最终完成绘制树的创建，简述流程如下：

以上整个构建绘制命令树的过程可以用如下流程图表示：

硬件加速下的整个界面的View树的结构如下图所示：

最后从systrace上看这个过程如下图所示：

经过上一小节中的分析，应用在UI线程中从根节点DecorView出发，递归遍历每个子View节点，搜集其drawXXX绘制动作并转换成DisplayListOp命令，将其记录到DisplayListData并填充到RenderNode中，最终完成整个View绘制命令树的构建。从此UI线程的绘制任务就完成了。下一步UI线程将唤醒RenderThread渲染线程，触发其利用OpenGL执行界面的渲染任务，本小节中我们将重点分析这个流程。我们还是先看看这块代码的简化流程：

从以上代码可以看出：UI线程利用RenderProxy向RenderThread线程发送一个DrawFrameTask任务请求，RenderThread被唤醒，开始渲染，大致流程如下：

整个过程可以用如下流程图表示：

从systrace上这个过程如下图所示：

SurfaceFlinger合成显示部分完全属于Android系统GUI中图形显示的内容，逻辑结构也比较复杂，但不属于本文介绍内容的重点。所以本小节中只是总体上介绍一下其工作原理与思想，不再详细分析源码，感兴趣的读者可以关注笔者后续的文章再来详细分析讲解。简单的说SurfaceFlinger作为系统中独立运行的一个Native进程，借用Android官网的描述，其职责就是负责接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备。如下图所示：

从上图可以看出，其实SurfaceFlinger在Android系统的整个图形显示系统中是起到一个承上启下的作用：

图形的传递是通过Buffer作为载体，Surface是对Buffer的进一步封装，也就是说Surface内部具有多个Buffer供上层使用，如何管理这些Buffer呢？答案就是BufferQueue ，下面我们来看看BufferQueue的工作原理：

借用一张经典的图来描述BufferQueue的工作原理：

BufferQueue是一个典型的生产者-消费者模型中的数据结构。在Android应用的渲染流程中，应用扮演的就是“生产者”的角色，而SurfaceFlinger扮演的则是“消费者”的角色，其配合工作的流程如下：

Vysnc垂直同步是Android在“黄油计划”中引入的一个重要机制，本质上是为了协调BufferQueue的应用生产者生成UI数据动作和SurfaceFlinger消费者的合成消费动作，避免出现画面撕裂的Tearing现象。Vysnc信号分为两种类型：

Vsync信号的生成是参考屏幕硬件的刷新周期的，其架构如下图所示：

本小节所描述的流程，从systrace上看SurfaceFlinger处理应用上帧工作的流程如下图所示：

至此，本文结合源码和systrace完整的分析了从用户手指点击桌面上的应用图标到屏幕上显示出应用主Activity界面第一帧画面的完整流程，这其中涉及了App应用、system_server框架、Art虚拟机、surfaceflinger等一系列Android系统核心模块的相互配合，有很多的细节也由于篇幅所限无法完全展开分析，感兴趣的读者可以结合AOSP源码继续深入分析。而优化应用启动打开的速度这个系统核心用户体验的指标，也是多少年来谷歌、SOC芯片厂商、ODM手机厂商以及各个应用开发者共同努力优化的方向：

本文只是分析了应用启动一般性流程，至于如何去优化应用启动的速度，可以关注笔者后续文章的更新，而本文则可以作为应用启动优化的一个基础认知。最后用一张流程图来概述一下应用启动流程的全貌：

针对上面的思维导图里面的知识点，我还对应的整理相关的学习文档，分享给大家进行参考学习。