应用是如何渲染到屏幕上的#

主要有以下核心步骤

UI布局与绘制
RenderThread渲染
SurfaceFlinger合成显示

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

Window是一个抽象类，通过控制DecorView提供了一些标准的UI方案，比如背景、标题、虚拟按键等，而PhoneWindow是Window的唯一实现类，在Activity创建后的attach流程中创建，应用启动显示的内容装载到其内部的mDecor（DecorView）；
DecorView是整个界面布局View控件树的根节点，通过它可以遍历访问到整个View控件树上的任意节点；
WindowManager是一个接口，继承自ViewManager接口，提供了View的基本操作方法；WindowManagerImp实现了WindowManager接口，内部通过组合方式持有WindowManagerGlobal，用来操作View；WindowManagerGlobal是一个全局单例，内部可以通过ViewRootImpl将View添加至窗口中；
ViewRootImpl是所有View的Parent，用来总体管理View的绘制以及与系统WMS窗口管理服务的IPC交互从而实现窗口的开辟；ViewRootImpl是应用进程运转的发动机，可以看到ViewRootImpl内部包含mView（就是DecorView）、mSurface、Choregrapher，mView代表整个控件树，mSurfacce代表画布，应用的UI渲染会直接放到mSurface中，Choregorapher使得应用请求vsync信号，接收信号后开始渲染流程

RenderThread渲染

在ViewRootImpl中完成了对界面的measure、layout和draw等绘制流程后，用户依然还是看不到屏幕上显示的应用界面内容。因为整个Android系统的显示流程除了前面讲到的UI线程的绘制外，界面还需要经过RenderThread线程的渲染处理。渲染完成后，还需要通过Binder调用“上帧”交给surfaceflinger进程中进行合成后送显才能最终显示到屏幕上。

Android 4.X之后系统默认界面是开启硬件加速的 硬件加速绘制主要包括两个阶段：

从DecorView根节点出发，递归遍历View控件树，记录每个View节点的drawOp绘制操作命令，完成绘制操作命令树的构建；
JNI调用同步Java层构建的绘制命令树到Native层的RenderThread渲染线程，并唤醒渲染线程利用OpenGL执行渲染任务；

应用在UI线程中从根节点DecorView出发，递归遍历每个子View节点，搜集其drawXXX绘制动作并转换成DisplayListOp命令，将其记录到DisplayListData并填充到RenderNode中，最终完成整个View绘制命令树的构建。从此UI线程的绘制任务就完成了。

下一步UI线程将唤醒RenderThread渲染线程，触发其利用OpenGL执行界面的渲染任务

：UI线程利用RenderProxy向RenderThread线程发送一个DrawFrameTask任务请求，RenderThread被唤醒，开始渲染，大致流程如下：

syncFrameState中遍历View树上每一个RenderNode，执行prepareTreeImpl函数，实现同步绘制命令树的操作；
调用OpenGL库API使用GPU，按照构建好的绘制命令完成界面的渲染（具体过程，由于本文篇幅所限，暂不展开分析）；
将前面已经绘制渲染好的图形缓冲区Binder上帧给SurfaceFlinger合成和显示

SurfaceFlinger合成显示 SurfaceFlinger合成显示部分完全属于Android系统GUI中图形显示的内容。简单的说SurfaceFlinger作为系统中独立运行的一个Native进程，借用Android官网的描述，其职责就是负责接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备 从上图可以看出，其实SurfaceFlinger在Android系统的整个图形显示系统中是起到一个承上启下的作用：