Android---如何同view进行渲染

ViewRootImpl 在 Activity、window 和 View 三者关系之间起着承上启下的作用。一方面，ViewRootImpl 中通过 Binder 通信机制，远程调用 WindowSession 将 View 添加到 Window 中；另一方面，ViewRootImpl 在添加 View 之前，需要调用 requestLayout 方法，执行完整的 View 树的渲染操作。

ViewRootImpl 执行 View 的渲染

屏幕绘制

ViewRootImpl requestLayout 流程。requestLayout 第一个次被调用是在 setView() 方法中。

从名字也能看出，这个方法的主要目的就是请求布局操作。其中包括 View 的测量、布局和绘制等。具体代码如下

注释1处，检测是否为合法线程。一般情况下，就是检测是否为主线程；注释2处，将请求布局标识符设置为 true。这个参数决定了后续是否执行 measure 和 layout 操作。最后执行 scheduleTraversals() 方法，如下

注释1处向主线程消息队列中插入 SyncBarrierMessage。该方法发送了一个没有 target 的 Message 到 queue 中。在 next 方法获取消息时，如果发现没有 target 的 message，则在一定的时间内跳过同步消息，优先执行异步消息。这里通过调用次方法，保证 UI 绘制操作优先执行。注释2处，调用 postCallback 方法。实际上也是发送一个 Message 到主线程消息队列。

postCallback 的执行流程如下

可以看出，最终通过 Handler 发送 MessageQueue 中的 message ，被设置为异步类型的消息。

mTraversalRunable 是一个实现 Runable 接口的 TraversalRunable 对象，其 run 方法如下

可以看出，在 run() 方法中，调用了 doTraversal() 方法，并最终调用了 performTraversals() 方法。这个方法就是真正的开始 View 的绘制流程：measure-->layout-->draw。核心代码如下

这是个比较重的方法，只负责做3件事情，即在自定义 view 中常用到的 3 个主要过程：measue、layout、draw。下面以测量 performMeasure 实现举例。

ViewRootImpl 的 measureHierarchy

View 的测量是一层递归调用，递归执行子 View 的测量工作之后，最后决定父视图的宽和高。但是，这个递归的起源是在哪里呢？

答案就是 DecorView。因为在 measureHierarchy 方法中，最终是调用 performMeasure 方法来进行测量工作的。performMeasure 方法的实现，如下代码所示

在这个方法中，通过 getRootMeasureSpec() 方法获取了根 View 的 MeasureSpec() 方法。实际上 MeasureSpec 的宽高此处获取的值是 Window 的宽高。

ViewRootImpl 的 performMeasure

这个方法很简单，只是执行了 mView 的 measure 方法。这个 mView 就是 DecorView。其 DecorView 的 measure 方法中会调用 onMeasure 方法，而 DecorView 是继承 FramLayout 的。因此，最终会执行 FramLayout 的 onMeasure 方法，并递归调用子 View 的 onMeasure 方法。

performLayout() 也是类似的过程，这里不再分析。

ViewRootImpl 的 performDraw

从图中可以看出，在 performDraw 方法中调用的 ViewRootImpl 的 draw 方法。在 draw 方法中进行 UI 绘制操作，Android 系统提供了两种绘制方式。图中1处标识 App 开启了硬件加速功能，所以会启动硬件加速绘制；图中2处表示使用软件绘制，

软件和硬件绘制

ViewRootImpl 中有一个非常重要的对象 Suface，之所以说 ViewRootImpl 的一个核心功能是负责 UI 渲染。原因就在于，在 ViewRootImpl 中会将在 draw 方法中绘制的 UI 元素，绑定到这个 Surface 上。如果说 canvas 是画板，那么 surface 就是画板上的画纸。Surface 中的内容最终会被传递给底层的 SurfaceFlinger，最终将 Surface 中的内容进行合成并显示在屏幕上。

软件绘制 drawSoftware

图中1处，就是调用 DecorView 的 draw 方法。将 UI 元素绘制到画布 canvas 对象中；图中2处，请求将 canvas 中的内容显示到屏幕上。实际上就是将 canvas 中的内容提交给 SurfaceFlinger 进行合成处理。默认情况下，软件绘制没有采用 GPU 渲染的方式，drawSoftware 工作完全由 CPU 来完成。

DecorView 并没有复写 draw 方法，因此，实际上是调用顶层 View 的 draw 方法，如下代码

图中1处绘制 view 的背景；图中2处绘制 view 的自身内容；图中3处表示对 draw 事件进行分发，在 view 中是空实现，实际调用的是 viewGroup 中的实现，并递归调用子 View 的 draw 事件。

启用硬件加速

可以在 ViewRootImpl 的 draw 方法中，通过如下方法判断是否启用硬件加速

我们可以在 AndroidManifest.xml 清单文件中，指定 Application 或者某一个 Activity 支持硬件加速

此外，还可以进行粒度更小的硬件加速设置，比如设置某个 View 支持硬件加速

之所以会有这么多级的支持区分，主要是因为并不是所有的 2D 绘制操作都支持硬件加速。

硬件加速优势

硬件加速能够提高 UI 渲染的性能。在 ViewRootImpl 的 draw 方法中，mThreadedRenderer 是 ThreadedRenderer 类型

其 darw 方法具体如下

图中1处就是硬件加速的特殊之处，通过 updateRootDisplayList() 方法，将 View 视图抽象成一个 RendererLoad 对象，并构建 View 的 drawOp 树；图中2处通知 renderThread 进行绘制操作。

renderThread 是一个单例线程，每个进程最多只有一个硬件渲染线程，这样就不会存在多线程并发访问冲突问题。updateRootDisplayList() 具体如下

Android 硬件加速过程中，View 视图被抽象成 RenderNode 节点。View 中的绘制操作都会被抽象成一个个 DrawOp。比如，View 中 drawLine，构建过程中就会被抽象成一个 DrawLineOp。drawBitmap 操作会被抽象成 DrawBitmapOp，每个子 View 的绘制被抽象成 DrawRenderNodeOp，每个 DrawOp 有对应的 OpenGL 绘制命令。

上图中1处遍历 view 递归构建 DrawOp；2处根据 canvas 将所有的 operation 进行缓存操作。所有的 DrawOp 对应 OpenGL 命令构建完成后，就需要使用 RenderProxy 向 RenderThread 发送消息。请求 OpenGL 线程进行渲染。整个渲染过程是通过 GPU 并在不同线程绘制渲染图像。因此整个流程会更加流程。

View 的两种刷新方式

Invalidate 轻量级刷新

通过 invalidate 来刷新 View，与 requestLayout 的区别在于它不一定会触发 View 的 measure 和 layout 的操作，多数情况下只会执行 draw 操作。在 View 的 measure 方法中，有如下几行代码

可以看出，如果要触发 onMeasure 方法，需要对 View 设置 PFLAG_FORCE_LAYOUT 的标志位。而这个标志位在 requestLayout 方法中被设置。 invalidate 并没有设置此标志位。

再看一下 onLayout 方法

可以看出当 view 的位置发生改变或者添加 PFLAG_FORCE_LAYOUT 标志位，onLayout 才会被执行。

当调用 invalidate 方法时，如果 View 的位置并没有发生改变，则 View 不会触发重新布局的操作。

postInvalidate

postInvalidate 在面试中经常被问道，实际开发中使用频率也是较高的。invalidate 与 postInvalidate 两者之间的区别是 invalidate 是在 UI 线程调用，postInvalidate 是在非 UI 线程调用。postInvalidate 实现如下

最终还是在 ViewRootImpl 中进行操作。

ViewRootImpl 的 dispatchInvalidateDelayed 在非 UI 线程中，通过 Handler 发送了一个延时 Message。

因为 Handler 是在主线程中创建的，所以 handleMessage 最终会在主线程中被执行。方法如下

上图中的 msg.obj 就是发生 postInvalidate 的 view 对象。可以看出，最终还是回到了 UI 线程，执行了 View 的 invalidate 方法。

个人理解，做过 android 开发的都知道，只有 UI 线程才可以刷新 view 控件。但是，事实却并非如此。在 ViewRootImpl 中对 view 进行刷新时，会检测当前线程的合法性，下图中 mThread 是被赋值为当前线程。而 ViewRootImpl 是在 UI 线程中被创建的，因此只有 UI 线程可以进行 view 刷新。但是，如果我们能在非 UI 线程中创建 ViewRootImpl，并通过这个 ViewRootImpl 进行 view 的添加和绘制操作，那么后续理论上也是可以在非 UI 线程中刷新 view 控件的。只是维护成本较高，很少有人去做这件事情。