RenderThread vs UI线程

Question

来自Android主题doc：

  

你不能从工作线程操纵你的UI - 你必须从UI线程对你的用户界面进行所有操作

所以我相信屏幕上的所有内容都由 UI线程呈现。但在Android Lollipop中，他们有introduced个 RenderThread ：

  

一个名为RenderThread的新系统管理处理线程即使在主UI线程中存在延迟时也能保持动画流畅

它是如何工作的？ RenderThread 是否使用 UI线程在屏幕上呈现动画（包含新属性的视图）？如果是这样，为什么不阻止 UI线程？

Answer 1

RenderThread取决于UI Thread，但它与最后提到的一起并行运行。

它的主要工作是在GPU上运行昂贵的计算，以清空UI Thread的重负荷。

  

它是如何工作的？

基本上，UI Thread充当了工作调度员。它准备了一个在RenderThread上执行的命令管道。

GPU不知道动画是什么;它只能理解基本命令，例如：

• translation(x,y,z)
• rotate(x,y)

或基本绘图实用程序：

• drawCircle(centerX, centerY, radius, paint)
• drawRoundRect(left, top, right, bottom, cornerRadiusX, cornerRadiusY, paint)

它们组合在一起形成了您在屏幕上看到的复杂动画。

  

RenderThread是否使用UI线程在屏幕上呈现动画（包含新属性的视图）？

不，它以异步方式运行

  

如果是这样，为什么它不会阻止UI线程？

docs解释了渲染分两个阶段进行：

1. View#draw - ＆gt; UI Thread
2. DrawFrame - ＆gt; RenderThread，根据View#draw阶段执行工作。

在较低级别，使用硬件加速时，延迟rendering由DisplayListCanvas执行。

在此Canvas实现中，您可以找到上述绘图命令，例如drawCircle。

因此，DisplayListCanvas也是RenderNodeAnimator的绘图目标，它运行基本动画命令（translate，scale，alpha， ...）。

Answer 2

渲染帖子，因为它的名称解释只需渲染 onDraw() ， UI线程执行onMeasure()，{ {1}}等...... 这种分离的概念是做一些测量和计算其他事情的艰苦工作，而不会阻碍渲染，从而导致光滑的 fps

观看this