本文深入解析Android应用程序窗口UI的硬件加速渲染，重点分析Display List的构建过程。Display List是UI绘制命令的缓冲区，用于提高渲染效率。内容包括Display List的构建、更新、以及如何处理视图属性变化，详述了从视图到Display List再到GPU执行的流程，涉及Android的硬件渲染机制和优化策略。
在硬件加速渲染环境中，Android应用程序窗口的UI渲染是分两步进行的。第一步是构建Display List，发生在应用程序进程的Main Thread中；第二步是渲染Display List，发生在应用程序进程的Render Thread中。Display List是以视图为单位进行构建的，因此每一个视图都对应有一个Display List。
这里说的Display List与Open GL里面的Display List在概念上是类似的，不过是两个不同的实现。Display List的本质是一个缓冲区，它里面记录了即将要执行的绘制命令序列。这些绘制命令最终会转化为Open GL命令由GPU执行。这意味着我们在调用Canvas API绘制UI时，实际上只是将Canvas API调用及其参数记录在Display List中，然后等到下一个Vsync信号到来时，记录在Display List里面的绘制命令才会转化为Open GL命令由GPU执行。与直接执行绘制命令相比，先将绘制命令记录在Display List中然后再执行有两个好处。第一个好处是在绘制窗口的下一帧时，若某一个视图的UI没有发生变化，那么就不必执行与它相关的Canvas API，即不用执行它的成员函数onDraw，而是直接复用上次构建的Display List即可。第二个好处是在绘制窗口的下一帧时，若某一个视图的UI发生了变化，但是只是一些简单属性发生了变化，例如位置和透明度等简单属性，那么也不必重建它的Display List，而是直接修改上次构建的Display List的相关属性即可，这样也可以省去执行它的成员函数onDraw。
Android应用程序窗口视图是树形结构的，因此它们的Display List是从根视图开始构建的，并且子视图的Display List包含在父视图的Display List中。这意味着根视图的Display List包含了Android应用程序窗口UI所有的绘制命令，因此最后我们只需要对根视图的Display List进行渲染即可得到Android应用程序窗口的UI，如图所示：
Android应用程序窗口的根视图是虚拟的，抽象为一个Root Render Node。此外，一个视图如果设置有Background，那么这个Background也会抽象为一个Background Render Node。Root Render Node、Background Render Node和其它真实的子视图，除了TextureView和软件渲染的子视图之外，都具有Display List，并且是通过一个称为Display List Renderer的对象进行构建的。TextureView不具有Display List，它们是通过一个称为Layer Renderer的对象以Open GL纹理的形式来绘制的，不过这个纹理也不是直接就进行渲染的，而是先记录在父视图的Display List中以后再进行渲染的。同样，软件渲染的子视图也不具有Display List，它们先绘制在一个Bitmap上，然后这个Bitmap再记录在父视图的Display List中以后再进行渲染的。
最后，Root Render Node的Display List被一个称为Open GL Renderer的对象进行渲染，就得到Android应用程序窗口的UI了。接下来我们就结合源代码来分析Android应用程序窗口视图的Display List的构建过程。
在前面Android应用程序UI硬件加速渲染环境初始化过程分析一文提到，Android应用程序窗口UI的绘制过程是从ViewRootImpl类的成员函数performDraw开始的，它的实现如下所示：
public final class ViewRootImpl implements ViewParent,
View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
......
private void performDraw() {
......
try {
draw(fullRedrawNeeded);
} finally {
......
}
......
}
......
}
ViewRootImpl类的成员函数performDraw主要是调用了另外一个成员函数draw执行UI绘制工作，后者的实现如下所示：
public final class ViewRootImpl implements ViewParent,
View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
......
private void draw(boolean fullRedrawNeeded) {
......
final Rect dirty = mDirty;
......
if (!dirty.isEmpty() || mIsAnimating) {
......
if (mAttachInfo.mHardwareRenderer != null && mAttachInfo.mHardwareRenderer.isEnabled()) {
......
mAttachInfo.mHardwareRenderer.draw(mView, mAttachInfo, this);
} else {
......
if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {
return;
}
}
}
......
}
......
}
经过一些滚动相关的处理之后，在两种情况下，需要真正地重绘窗口的下一帧。第一种情况是当前需要更新的区域，即ViewRootImpl类的成员变量mDirty描述的脏区域不为空。第二种情况下窗口当前有动画需要执行，即ViewRootImpl类的成员变量mIsAnimating的值等于true。
在上述两种情况下，如果ViewRootImpl类的成员变量mAttachInfo指向的一个AttachInfo对象的成员变量mHardwareRenderer的值不为null，并且调用它指向的一个HardwareRenderer对象的成员函数isEnabled的返回值为true，那么就调用这个HardwareRenderer对象的另外一个成员函数draw执行渲染工作。从前面Android应用程序UI硬件加速渲染环境初始化过程分析一文可以知道，当使用硬件加速渲染时，ViewRootImpl类的成员变量mAttachInfo指向的一个AttachInfo对象的成员变量mHardwareRenderer的值不为null，并且它指向的是一个ThreadedRenderer对象。如果该ThreadedRenderer对象也设置了支持硬件加速渲染，那么调用它的成员函数isEnabled的返回值就为true。这意味着当使用硬件加速渲染时，ViewRootImpl类的成员函数draw调用的是ThreadedRenderer类的成员函数draw。另一方面，当使用软件渲染时，ViewRootImpl类的成员函数draw调用的是另外一个成员函数drawSoftware。
软件渲染的执行过程可以参考前面Android应用程序窗口（Activity）的测量（Measure）、布局（Layout）和绘制（Draw）过程分析一文。这里我们只关注硬件渲染的执行过程，因此接下来我们继续分析ThreadedRenderer类的成员函数draw的实现，如下所示：
public class ThreadedRenderer extends HardwareRenderer {
......
@Override
void draw(View view, AttachInfo attachInfo, HardwareDrawCallbacks callbacks) {
......
updateRootDisplayList(view, callbacks);
......
if (attachInfo.mPendingAnimatingRenderNodes != null) {
final int count = attachInfo.mPendingAnimatingRenderNodes.size();
for (int i = 0; i < count; i++) {
registerAnimatingRenderNode(
attachInfo.mPendingAnimatingRenderNodes.get(i));
}
attachInfo.mPendingAnimatingRenderNodes.clear();
// We don't need this anymore as subsequent calls to
// ViewRootImpl#attachRenderNodeAnimator will go directly to us.
attachInfo.mPendingAnimatingRenderNodes = null;
}
int syncResult = nSyncAndDrawFrame(mNativeProxy, frameTimeNanos,
recordDuration, view.getResources().getDisplayMetrics().density);
if ((syncResult & SYNC_INVALIDATE_REQUIRED) != 0) {
attachInfo.mViewRootImpl.invalidate();
}
}
......
}
ThreadedRenderer类的成员函数draw主要是完成以下四件事情：
- 调用成员函数updateRootDisplayList构建参数view描述的视图的Display List，该视图即为图1所示的Decor View。
- 调用成员函数registerAnimatingRenderNode将保存在参数attachInfo指向的一个AttachInfo对象的成员变量mPendingAnimatingRenderNodes描述的一个列表中的Render Node注册到Native层中去。这些Render Node描述的是当前窗口设置的动画。
- 调用成员函数nSyncAndDrawFrame通知Render Thread绘制下一帧。
- 如果成员函数nSyncAndDrawFrame的返回值syncResult的SYNC_INVALIDATE_REQUIRED位不等于0，就表明Render Thread可能需要与Main Thread进行信息同步，这时候就时候向Main Thread发送一个INVALIDATE消息，以便Main Thread可以进行信息同步。这种情况一般发生在当前绘制的一帧包含有同步动画时。例如，同步动画显示到一半，需要中止，这个中止的操作就是由Main Thread发出的，然后由Render Thread检测到这个中止操作。
这里我们只关注第一件事情，ThreadedRenderer类的成员函数updateRootDisplayList的实现如下所示：
public class ThreadedRenderer extends HardwareRenderer {
......
private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {
......
updateViewTreeDisplayList(view);
if (mRootNodeNeedsUpdate || !mRootNode.isValid()) {
HardwareCanvas canvas = mRootNode.start(mSurfaceWidth, mSurfaceHeight);
try {
final int saveCount = canvas.save();
.......
canvas.insertReorderBarrier();
canvas.drawRenderNode(view.getDisplayList());
canvas.insertInorderBarrier();
......
canvas.restoreToCount(saveCount);
mRootNodeNeedsUpdate = false;
} finally {
mRootNode.end(canvas);
}
}
......
}
......
}
ThreadedRenderer类的成员函数updateRootDisplayList通过调用另一个成员函数updateViewTreeDisplayList来构建参数view描述的视图的Display List，即Decor View的Display List。构建好的这个Display List可以通过调用参数view描述的视图的成员函数getDisplayList获得的一个Render Node来描述。
ThreadedRenderer类的成员变量mRootNodeNeedsUpdate是一个布尔变量，当它的值等于true的时候，就表示要更新另外一个成员变量mRootNode描述的一个Render Node的Display List。另外，如果ThreadedRenderer类的成员变量mRootNode描述的Render Node还未构建过Display List，那么这时候调用它的成员函数isValid的返回值为true，这种情况也表示要更新它的Display List。
从前面Android应用程序UI硬件加速渲染环境初始化过程分析一文可以知道，ThreadedRenderer类的成员变量mRootNode描述的Render Node即为即为当前窗口的Root Node，更新它的Display List实际上就是要将参数view描述的视图的Display List记录到它里面去，具体方法如下所示：
- 调用ThreadedRenderer类的成员变量mRootNode描述的Render Node的成员函数start获得一个Hardware Canvas。
- 调用上面获得的Hardware Canvas的成员函数drawRenderNode将参数view描述的视图的Display List绘制在它里面。在绘制参数view描述的视图的Display List的前后，会调用Hardware Canvas的成员函数insertReorderBarrier和insertInorderBarrier分别设置一个Reorder Barrier和一个Inorder Barrier。后面我们在分析Display List绘制在Hardware Canvas的过程时就会看到，插入这些Barrier是为了将一个View的所有的Draw Op及其子View对应的Draw Op记录在一个Chunk中。其中，Reorder Barrier表明在真正渲染这些Chunck记录的Draw Op时，需要考虑按照Z轴坐标值重新排列子View的渲染顺序。
- 调用ThreadedRenderer类的成员变量mRootNode描述的Render Node的成员函数end取出上述已经绘制好的Hardware Canvas的数据，并且作为上述Render Node的新的Display List。
接下来，我们首先分析ThreadedRenderer类的成员变量mRootNode描述的Render Node的Display List的更新过程，即RootNode类的成员函数start、HardwareCanvas类的成员函数drawRenderNode和RootNode类的成员函数end的实现，然后再回过头来分析参数view描述的视图的Display List的构建过程，即ThreadedRenderer类的成员函数updateViewTreeDisplayList的实现。
RootNode类的成员函数start的实现如下所示：
public class RenderNode {
......
public HardwareCanvas start(int width, int height) {
HardwareCanvas canvas = GLES20RecordingCanvas.obtain(this);
canvas.setViewport(width, height);
......
return canvas;
}
......
}
RootNode类的成员函数start的核心是调用GLES20RecordingCanvas类的静态成员函数obtain一个类型为GLES20RecordingCanvas的Hardware Canvas，然后在设置了该Hardware Canvas的View Port之后，返回给调用者。
GLES20RecordingCanvas类的静态成员函数obtain的实现如下所示：
class GLES20RecordingCanvas extends GLES20Canvas {
......
private static final int POOL_LIMIT = 25;
private static final SynchronizedPool<GLES20RecordingCanvas> sPool =
new SynchronizedPool<GLES20RecordingCanvas>(POOL_LIMIT);
RenderNode mNode;
private GLES20RecordingCanvas() {
super();
}
static GLES20RecordingCanvas obtain(@NonNull RenderNode node) {
......
GLES20RecordingCanvas canvas = sPool.acquire();
if (canvas == null) {
canvas = new GLES20RecordingCanvas();
}
canvas.mNode = node;
return canvas;
}
......
}
GLES20RecordingCanvas类的静态成员函数obtain首先是从一个GLES20RecordingCanvas对象池中请求一个GLES20RecordingCanvas对象。如果获取失败，再直接创建一个GLES20RecordingCanvas对象。在将获取到的GLES20RecordingCanvas对象返回给调用者之前，还会将参数node描述的Render Node保存在其成员变量mNode中。
接下来我们继续关注GLES20RecordingCanvas对象的创建过程，即GLES20RecordingCanvas类的构造函数的实现。GLES20RecordingCanvas类的构造函数只是简单调用了父类GLES20Canvas的构造函数，它的实现如下所示：
class GLES20Canvas extends HardwareCanvas {
......
protected long mRenderer;
......
protected GLES20Canvas() {
......
mRenderer = nCreateDisplayListRenderer();
......
}
......
}
GLES20Canvas类的构造函数最主要做的事情就是调用另外一个成员函数nCreateDisplayListRenderer在Native层创建了一个Display List Renderer，并且将它的地址保存在成员变量mRenderer中。
GLES20Canvas类的成员函数nCreateDisplayListRenderer是一个JNI函数，由Native层的函数android_view_GLES20Canvas_createDisplayListRenderer实现，如下所示：
static jlong android_view_GLES20Canvas_createDisplayListRenderer(JNIEnv* env, jobject clazz) {
return reinterpret_cast<jlong>(new DisplayListRenderer);
}
从这里就可以看到，函数android_view_GLES20Canvas_createDisplayListRenderer创建了一个DisplayListRenderer对象之后，就将它的地址返回给调用者。
从上面分析的过程就可以知道，调用RenderNode类的成员函数start获得的一个Hardware Canvas的具体类型为GLES20RecordingCanvas，它通过父类GLES20Canvas在Native层创建了一个DisplayListRenderer对象。
因此当我们调用上述Hardware Canvas的成员函数drawRenderNode绘制一个Display List时，调用的实际上是GLES20RecordingCanvas类的成员函数drawRenderNode，不过这个成员函数是从其父类GLES20Canvas继承下来的，它的实现如下：
class GLES20Canvas extends HardwareCanvas {
......
@Override
public int drawRenderNode(RenderNode renderNode, Rect dirty, int flags) {
return nDrawRenderNode(mRenderer, renderNode.getNativeDisplayList(), dirty, flags);
}
......
}
GLES20Canvas类的成员函数drawRenderNode首先是调用参数renderNode指向的一个RenderNode对象的成员函数getNativeDisplayList获得其在Native层对应的Display List，接着再调用另外一个成员函数nDrawRenderNode将获得的Native Display List通过成员变量mRenderer描述的一个在Native层的Display List Renderer绘制在当前的GLES20 Canvas中。Native层的Display List实际上是通过Native层的Render Node来描述的。
GLES20Canvas类的成员函数nDrawRenderNode是一个JNI函数，由Native层的函数android_view_GLES20Canvas_drawRenderNode实现，如下所示：
static jint android_view_GLES20Canvas_drawRenderNode(JNIEnv* env,
jobject clazz, jlong rendererPtr, jlong renderNodePtr,
jobject dirty, jint flags) {
DisplayListRenderer* renderer = reinterpret_cast<DisplayListRenderer*>(rendererPtr);
RenderNode* renderNode = reinterpret_cast<RenderNode*>
最低0.47元/天 解锁文章
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
