一 概述
在手机客户端尤其是 Android 应用开发过程中，我们经常会接触到“硬件加速”这个概念。由于操作系统对底层软硬件封装非常完善，上层软件开发者往往对硬件加速的底层原理了解很少，也不清楚了解底层原理的意义，因此常会有一些误解，如硬件加速是不是通过特殊算法实现页面渲染加速，或是通过硬件提高 CPU/GPU 运算速率实现渲染加速。
硬件加速，直观上说就是依赖 GPU 实现图形绘制加速，软硬件加速的区别主要是图形的绘制究竟是 GPU 来处理还是 CPU，如果是 GPU，就认为是硬件加速绘制，反之，则为软件绘制。在 Android 中也是如此，不过相对于普通的软件绘制，硬件加速还做了其他方面优化，不仅仅限定在绘制方面，绘制之前，在如何构建绘制区域上，硬件加速也做出了很大优化，因此硬件加速特性可以从下面两部分来分析：
- 前期策略：如何构建需要绘制的区域
- 后期绘制：单独渲染线程，依赖 GPU 进行绘制
无论是软件绘制还是硬件加速，绘制内存的分配都是类似的，都是需要请求 SurfaceFlinger 服务分配一块内存，只不过硬件加速有可能从 FrameBuffer 硬件缓冲区直接分配内存（SurfaceFlinger 一直这么干的），两者的绘制都是在 APP 端，绘制完成之后同样需要通知 SurfaceFlinger 进行合成，在这个流程上没有任何区别，真正的区别在于在 APP 端如何完成 UI 数据绘制，本文就直观的了解下两者的区别，会涉及部分源码，但不求甚解。
1.1 了解硬件加速对App开发的意义
对于 App 开发者，简单了解硬件加速原理及上层 API 实现，开发时就可以充分利用硬件加速提高页面的性能。以 Android 举例，实现一个圆角矩形按钮通常有两种方案：使用 PNG 图片；使用代码（XML/Java）实现。简单对比两种方案如下。
| 方案 | 原理 | 特点 |
|---|---|---|
| 使用PNG图片（BitmapDrawable） | 解码PNG图片生成Bitmap，传到底层，由GPU渲染 | 图片解码消耗CPU运算资源，Bitmap占用内存大，绘制慢 |
| 使用XML或Java代码实现（ShapeDrawable） | 直接将Shape信息传到底层，由GPU渲染 | 消耗CPU资源少，占用内存小，绘制快 |
1.2 页面渲染背景知识
- 页面渲染时，被绘制的元素最终要转换成矩阵像素点（即多维数组形式，类似安卓中的 Bitmap），才能被显示器显示
- 页面由各种基本元素组成，例如圆形、圆角矩形、线段、文字、矢量图（常用贝塞尔曲线组成）、Bitmap 等
- 元素绘制时尤其是动画绘制过程中，经常涉及插值、缩放、旋转、透明度变化、动画过渡、毛玻璃模糊，甚至包括 3D 变换、物理运动（例如游戏中常见的抛物线运动）、多媒体文件解码（主要在桌面机中有应用，移动设备一般不用 GPU 做解码）等运算
- 绘制过程经常需要进行逻辑较简单、但数据量庞大的浮点运算。
二 CPU与GPU结构对比
CPU（Central Processing Unit，中央处理器）是计算机设备的核心器件，用于执行程序代码，软件开发者对此都很熟悉；GPU（Graphics Processing Unit，图形处理器）主要用于处理图形运算，通常所说“显卡”的核心部件就是 GPU。
下面是 CPU 和 GPU 的结构对比图。其中：
- 黄色的 Control 为控制器，用于协调控制整个 CPU 的运行，包括取出指令、控制其他模块的运行等；
- 绿色的 ALU（Arithmetic Logic Unit）是算术逻辑单元，用于进行数学、逻辑运算；
- 橙色的 Cache 和 DRAM 分别为缓存和 RAM，用于存储信息。
从结构图可以看出，CPU 的控制器较为复杂，而 ALU 数量较少。因此 CPU 擅长各种复杂的逻辑运算，但不擅长数学尤其是浮点运算。
- 以 8086 为例，一百多条汇编指令大部分都是逻辑指令，数学计算相关的主要是 16 位加减乘除和移位运算。一次整型和逻辑运算一般需要 1~3 个机器周期，而浮点运算要转换成整数计算，一次运算可能消耗上百个机器周期
- 更简单的 CPU 甚至只有加法指令，减法用补码加法实现，乘法用累加实现，除法用减法循环实现
- 现代 CPU 一般都带有硬件浮点运算器（FPU），但主要适用于数据量不大的情况
CPU 是串行结构。以计算 100 个数字为例，对于 CPU 的一个核，每次只能计算两个数的和，结果逐步累加。
和 CPU 不同的是，GPU 就是为实现大量数学运算设计的。从结构图中可以看到，GPU 的控制器比较简单，但包含了大量 ALU。GPU 中的 ALU 使用了并行设计，且具有较多浮点运算单元。
硬件加速的主要原理，就是通过底层软件代码，将 CPU 不擅长的图形计算转换成 GPU 专用指令，由 GPU 完成。
扩展：很多计算机中的 GPU 有自己独立的显存；没有独立显存则使用共享内存的形式，从内存中划分一块区域作为显存。显存可以保存 GPU 指令等信息。
2.1 并行结构举例：级联加法器
为了方便理解，这里先从底层电路结构的角度举一个例子。如下图为一个加法器，对应实际的数字电路结构。
A、B 为输入，C 为输出，且 A、B、C 均为总线，以 32 位 CPU 为例，则每根总线实际由 32 根导线组成，每根导线用不同的电压表示一个二进制的 0 或 1。
Clock 为时钟信号线，每个固定的时钟周期可向其输入一个特定的电压信号，每当一个时钟信号到来时，A 和 B 的和就会输出到 C。
现在我们要计算 8 个整数的和。
对于 CPU 这种串行结构，代码编写很简单，用 for 循环把所有数字逐个相加即可。串行结构只有一个加法器，需要 7 次求和运算；每次计算完部分和，还要将其再转移到加法器的输入端，做下一次计算。整个过程至少要消耗十几个机器周期。
而对于并行结构，一种常见的设计是级联加法器，如下图，其中所有的 clock 连在一起。当需要相加的 8 个数据在输入端 A1~B4 准备好后，经过三个时钟周期，求和操作就完成了。如果数据量更大、级联的层级更大，则并行结构的优势更明显。
由于电路的限制，不容易通过提高时钟频率、减小时钟周期的方式提高运算速度。并行结构通过增加电路规模、并行处理，来实现更快的运算。但并行结构不容易实现复杂逻辑，因为同时考虑多个支路的输出结果，并协调同步处理的过程很复杂（有点像多线程编程）。
2.2 GPU并行计算举例
假设我们有如下图像处理任务，给每个像素值加 1。GPU 并行计算的方式简单粗暴，在资源允许的情况下，可以为每个像素开一个 GPU 线程，由其进行加 1 操作。数学运算量越大，这种并行方式性能优势越明显。
三 软硬件加速的分歧点
大概从 Android 4.+ 开始，默认情况下都是支持和开启了硬件加速的，也存在手机支持硬件加速，但是部分 API 不支持硬件加速的情况，如果使用了这些 API，就需要主动关闭硬件加速，或者在 View 层，或者在 Activity 层关闭，比如 Canvas 的 clipPath 等。但是，View 的绘制是软件实现的还是硬件加速实现的，一般在开发的时候并不可见，那么图形绘制的时候，软硬件的分歧点究竟在哪呢？举个例子，有个 View 需要重绘，一般会调用 View 的 invalidate，触发重绘，跟着这条线走，去查一下分歧点。
从上面的调用流程可以看出，视图重绘最后会进入 ViewRootImpl 的 draw，软硬件加速的分歧点就在这个函数里面，我们来看代码：
ViewRootImpl.java
private void draw(boolean fullRedrawNeeded) {
......
if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {
<!--关键点1 是否开启硬件加速-->
if (mAttachInfo.mThreadedRenderer != null &&
mAttachInfo.mThreadedRenderer.isEnabled()) {
......
dirty.setEmpty();
<!--关键点2 硬件加速绘制-->
mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);
} else {
...
<!--关键点3 软件绘制-->
if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset,
scalingRequired, dirty, surfaceInsets)) {
return false;
}
......
关键点1是启用硬件加速的条件，必须支持硬件并且开启了硬件加速才可以，满足这两个条件后，就调用 ThreadedRenderer.draw，否则 drawSoftware（软件绘制）。简答看一下这个条件，默认情况下，该条件是成立的，因为 4.+ 之后的手机一般都支持硬件加速，而且在 ViewRootImpl 通过 setView 添加窗口的时候，会调用 enableHardwareAcceleration 开启硬件加速，我们来看代码：
ViewRootImpl.java
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
......
if (view instanceof RootViewSurfaceTaker) {
mSurfaceHolderCallback =
((RootViewSurfaceTaker)view).willYouTakeTheSurface();
if (mSurfaceHolderCallback != null) {
mSurfaceHolder = new TakenSurfaceHolder();
mSurfaceHolder.setFormat(PixelFormat.UNKNOWN);
mSurfaceHolder.addCallback(mSurfaceHolderCallback);
}
}
......
if (mSurfaceHolder == null) {
// While this is supposed to enable only, it can effectively disable
// the acceleration too.
//关键点： 开启硬件加速
enableHardwareAcceleration(attrs);
final boolean useMTRenderer = MT_RENDERER_AVAILABLE
&& mAttachInfo.mThreadedRenderer != null;
if (mUseMTRenderer != useMTRenderer) {
// Shouldn't be resizing, as it's done only in window setup,
// but end just in case.
endDragResizing();
mUseMTRenderer = useMTRenderer;
}
}
......
}
private void enableHardwareAcceleration(WindowManager.LayoutParams attrs) {
......
<!--根据配置，获取硬件加速的开关-->
final boolean hardwareAccelerated =
(attrs.flags &
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED) != 0;
if (hardwareAccelerated) {
......
<!--新建硬件加速图形渲染器-->
mAttachInfo.mThreadedRenderer =
ThreadedRenderer.create(mContext, translucent,
attrs.getTitle().toString());
......
}
}
其实到这里软件绘制跟硬件加速绘制的分歧点已经找到了，就是 ViewRootImpl 在 draw 的时候，如果需要硬件加速就利用 ThreadedRenderer 进行 draw，否则走软件绘制流程。
drawSoftware 其实很简单，利用 Surface.lockCanvas，向 SurfaceFlinger 申请一块匿名共享内存内存分配，同时获取一个普通的 SkiaCanvas，用于调用 Skia 库，进行图形绘制。
private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff,
int yoff, boolean scalingRequired, Rect dirty, Rect surfaceInsets) {
final Canvas canvas;
try {
<!--关键点1 -->
canvas = mSurface.lockCanvas(dirty);
......
<!--关键点2 绘制-->
mView.draw(canvas);
......
<!--关键点3 通知SurfaceFlinger进行图层合成-->
surface.unlockCanvasAndPost(canvas);
} ...
return true;
}
默认情况下 Skia 的绘制没有采用 GPU 渲染的方式（虽然 Skia 也能用 GPU 渲染），也就说默认 drawSoftware 工作完全由 CPU 来完成，不会牵扯到 GPU 的操作，但是 8.0 之后，Google 逐渐加重了 Skia，开始让 Skia 接手 OpenGL，间接统一调用，将来还可能是 Skia 同 Vulkan 的结合，不过这里不是重点。重点看下 ThreadedRenderer 所进行的硬件加速绘制。
四 硬件加速绘制模型
开头说过，硬件加速绘制包括两个阶段：构建阶段和绘制阶段，所谓构建就是递归遍历所有视图，将需要的绘制操作缓存下来，之后再交给单独的 Render 线程利用 OpenGL 渲染。在 Android 硬件加速框架中，View 视图被抽象成 RenderNode 节点。
4.1 ThreadedRenderer架构分析
构造方法（其中 ThreadedRenderer 继承于 HardwareRenderer）
ThreadedRenderer(Context context, boolean translucent, String name) {
super();
setName(name);
setOpaque(!translucent);
......
setLightSourceAlpha(ambientShadowAlpha, spotShadowAlpha);
}
public HardwareRenderer() {
mRootNode = RenderNode.adopt(nCreateRootRenderNode());
mRootNode.setClipToBounds(false);
mNativeProxy = nCreateProxy(!mOpaque, mRootNode.mNativeRenderNode);
if (mNativeProxy == 0) {
throw new OutOfMemoryError("Unable to create hardware renderer");
}
Cleaner.create(this, new DestroyContextRunnable(mNativeProxy));
ProcessInitializer.sInstance.init(mNativeProxy);
}
JNI# 方法创建了一个底层 RootRenderNode 节点，相应地也创建一个上层 RenderNode 节点，它主要就是对 RootRenderNode 的一个封装 ；
JNI#方法创建一个底层 RenderProxy 代理。RenderProxy 的构造方法，将创建 CanvasContext 和 RenderThread，其中 RenderThread 是一个单例线程；CanvasContext 封装底层 RootRenderNode 节点。
RenderProxy::RenderProxy(bool translucent, RenderNode* rootRenderNode,
IContextFactory* contextFactory)
: mRenderThread(RenderThread::getInstance()), mContext(nullptr) {
mContext = mRenderThread.queue().runSync([&]() -> CanvasContext* {
return CanvasContext::create(mRenderThread,
translucent, rootRenderNode, contextFactory);
});
mDrawFrameTask.setContext(&mRenderThread, mContext, rootRenderNode);
}
ThreadedRenderer 与底层结构的关系图如下。
开头说过，硬件加速绘制包括两个阶段：构建阶段+绘制阶段，所谓构建就是递归遍历所有视图，将需要的操作缓存下来，之后再交给单独的 Render 线程利用 OpenGL 渲染。在 Android 硬件加速框架中，View 视图被抽象成 RenderNode 节点，View 中的绘制都会被抽象成一个个 DrawOp（DisplayListOp）。
如此以来，每个 View 不仅仅握有自己 DrawOp List，同时还拿着子 View 的绘制入口，如此递归，便能够统计到所有的绘制 Op，很多分析都称为 Display List，源码中也是这么来命名类的，不过这里其实更像是一个树，而不仅仅是 List。
构建完成后，就可以将这个绘图 Op 树交给 Render 线程进行绘制，这里是同软件绘制很不同的地方，软件绘制时，View 一般都在主线程中完成绘制，而硬件加速，除非特殊要求，一般都是在单独线程中完成绘制，如此以来就分担了主线程很多压力，提高了UI线程的响应速度。
4.2 硬件渲染入口
上面我们已经知道进入硬件加速的时候调用的是 ThreadedRenderer 的 draw 方法，这个就是 Java 层硬件渲染的入口方法。
void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {
......
//入参 view 是顶层视图 DecorView。
updateRootDisplayList(view, callbacks); //遍历更新视图树每一个节点。
......
//通知 RenderThread 线程绘制
int syncResult = syncAndDrawFrame(choreographer.mFrameInfo);
if ((syncResult & SYNC_LOST_SURFACE_REWARD_IF_FOUND) != 0) {
setEnabled(false);
attachInfo.mViewRootImpl.mSurface.release();
// Invalidate since we failed to draw. This should fetch a Surface
// if it is still needed or do nothing if we are no longer drawing
attachInfo.mViewRootImpl.invalidate();
}
if ((syncResult & SYNC_REDRAW_REQUESTED) != 0) {
attachInfo.mViewRootImpl.invalidate();
}
}
这里有两大步骤：
- updateRootDisplayList 方法，完成绘制区域的构建，绘制整个树形视图结构，从顶层视图开始，每一个视图节点逐一绘制，最终目的是触发每一个视图的 Canvas#drawXxx 方法。
- nSyncAndDrawFrame 方法，通知 RenderThread 线程来进行绘制阶段，最终目的是把 OpenGL 指令写入 GPU。(另外文章分析)
4.3 绘制区域的构建－－视图遍历
如何触发树形结构中每一个视图 Canvas 的相关方法呢？自定义 View 时，重写 onDraw 方法，将视图绘制成我们想要的样子，就是利用 Canvas 的一系列 drawXxx 方法。视图遍历，我们从 ThreadedRenderer 的 updateRootDisplayList 方法开始分析。
private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {
//第一步，从顶层视图开始，更新所有视图的DisplayList。
updateViewTreeDisplayList(view);
//第二步，根节点绘制顶层视图RenderNode。
if (mRootNodeNeedsUpdate || !mRootNode.hasDisplayList()) {
RecordingCanvas canvas =
mRootNode.beginRecording(mSurfaceWidth, mSurfaceHeight);
try {
final int saveCount = canvas.save();
canvas.translate(mInsetLeft, mInsetTop);
callbacks.onPreDraw(canvas);
canvas.enableZ();
//绘制顶层视图RenderNode。
canvas.drawRenderNode(view.updateDisplayListIfDirty());
canvas.disableZ();
callbacks.onPostDraw(canvas);
canvas.restoreToCount(saveCount);
mRootNodeNeedsUpdate = false;
} finally {
mRootNode.endRecording();
}
}
}
它的入参是顶层视图 DecorView。主流程图。
从图片与源码可以看出，两个步骤
- updateViewTreeDisplayList 方法，从顶层视图 DecorView 开始，遍历树形视图结构的每一个节点，利用视图内的 RenderNode 创建 Canvas 绘制
- 利用 ThreadedRenderer 的根 RootRenderNode 创建 Canvas，绘制顶层 RenderNode 节点。
4.3.1 updateViewTreeDisplayList
遍历的主流程在第一步，ThreadedRenderer 的 updateViewTreeDisplayList 方法，意思是更新树视图的绘制数据。从顶层视图 DecorView，真正开始树形结构递归绘制。
ThreadedRenderer.java
private void updateViewTreeDisplayList(View view) {
view.mPrivateFlags |= View.PFLAG_DRAWN;
view.mRecreateDisplayList = (view.mPrivateFlags & View.PFLAG_INVALIDATED)
== View.PFLAG_INVALIDATED;
view.mPrivateFlags &= ~View.PFLAG_INVALIDATED;
view.updateDisplayListIfDirty();
view.mRecreateDisplayList = false;
}
该方法代码很少，判断视图的 PFLAG_INVALIDATED 标志，有这个标志，在调用每一个 View 的 updateDisplayListIfDirty 方法时，才会创建 Canvas，当一个视图需要绘制时，上层肯定会设置该标志。最后会将重建标志还原。
View.java
public RenderNode updateDisplayListIfDirty() {
final RenderNode renderNode = mRenderNode;
if (!canHaveDisplayList()) {
// can't populate RenderNode, don't try
return renderNode;
}
if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0
|| !renderNode.hasDisplayList()
|| (mRecreateDisplayList)) {
......
int width = mRight - mLeft;
int height = mBottom - mTop;
int layerType = getLayerType();
//关键点１ 通过 renderNode 生成 RecordingCanvas
final RecordingCanvas canvas =
renderNode.beginRecording(width, height);
try {
if (layerType == LAYER_TYPE_SOFTWARE) {
buildDrawingCache(true);
Bitmap cache = getDrawingCache(true);
if (cache != null) {
canvas.drawBitmap(cache, 0, 0, mLayerPaint);
}
} else {
......
// Fast path for layouts with no backgrounds
if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
//如果需要跳过，则直接派发给子视图
dispatchDraw(canvas);
......
} else {
//关键点2 通过 canvas 进行绘制
draw(canvas);
}
}
} finally {
//关键点３ 绘制结束，保存canvas记录内容
renderNode.endRecording();
setDisplayListProperties(renderNode);
}
} else {
mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
mPrivateFlags &= ~PFLAG_DIRTY_MASK;
}
return renderNode;
}
每个视图的流程是一样的，都有三个步骤，第一次绘制时，每个视图都要建立 Canvas。
- 通过视图 renderNode.beginRecording(width, height)，创建 RecordingCanvas 画布对象。
- 通过 View 的 draw (canvas) 方法，实现具体记录绘制操作，(绘制自身与派发)，draw 方法包括很多步骤，包括递归到子视图的 updateDisplayListIfDirty 方法，后面会介绍。
- 最后，renderNode.endRecording() 绘制结束，保存 canvas 记录内容
因此，从顶层 DecorView 的 updateDisplayListIfDirty 方法，就已经开始准备遍历递归每个子视图的 updateDisplayListIfDirty 方法啦，进入每一个视图的 draw 方法，最终，触发每个视图 onDraw 方法。
关键点１：RecordingCanvas.beginRecording
RenderNode.java
public @NonNull RecordingCanvas beginRecording(int width, int height) {
if (mCurrentRecordingCanvas != null) {
throw new IllegalStateException(
"Recording currently in progress - missing #endRecording() call?");
}
mCurrentRecordingCanvas = RecordingCanvas.obtain(this, width, height);
return mCurrentRecordingCanvas;
}
static RecordingCanvas obtain(@NonNull RenderNode node, int width, int height) {
if (node == null) throw new IllegalArgumentException("node cannot be null");
//缓存池中请求
RecordingCanvas canvas = sPool.acquire();
if (canvas == null) {
canvas = new RecordingCanvas(node, width, height);
} else {
nResetDisplayListCanvas(canvas.mNativeCanvasWrapper,
node.mNativeRenderNode,
width, height);
}
canvas.mNode = node;
canvas.mWidth = width;
canvas.mHeight = height;
return canvas;
}
创建 RecordingCanvas 画布，它继承 DisplayListCanvas，而 DisplayListCanvas 又继承自 Canvas。每个视图都有一个画布，Canvas 缓存池存储画布对象。
关键点２：draw(canvas)
调用 View 自身的 draw 方法，最后会递归遍历到 updateDisplayListIfDirty。这个流程在之前的 View 的绘制中已经做了分析，在此不再赘述。
关键点３：renderNode.endRecording()
public void endRecording() {
if (mCurrentRecordingCanvas == null) {
throw new IllegalStateException(
"No recording in progress, forgot to call #beginRecording()?");
}
RecordingCanvas canvas = mCurrentRecordingCanvas;
mCurrentRecordingCanvas = null;
long displayList = canvas.finishRecording();
nSetDisplayList(mNativeRenderNode, displayList);
canvas.recycle();
}
JNI# 方法调用底层 RecordingCanvas 的 finishRecording 方法，返回底层 DisplayListCanvas 对象中保存的 DisplayListData 指针。
JNI# 方法将 DisplayListData 指针保存到底层 RenderNode 中。
Canvas 释放，回收入缓存池。
4.3.2 根RenderNode绘制
重新回到 ThreadedRenderer 的 updateRootDisplayList 方法，我们知道第一步是调用 updateViewTreeDisplayList 来递归遍历子 View，并更新 DisplayList 数据。接下来就是对根 RenderNode 的绘制。
private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {
//第一步，从顶层视图开始，更新所有视图的DisplayList。
updateViewTreeDisplayList(view);
//第二步，根节点绘制顶层视图RenderNode。
if (mRootNodeNeedsUpdate || !mRootNode.hasDisplayList()) {
RecordingCanvas canvas =
mRootNode.beginRecording(mSurfaceWidth, mSurfaceHeight);
try {
final int saveCount = canvas.save();
canvas.translate(mInsetLeft, mInsetTop);
callbacks.onPreDraw(canvas);
canvas.enableZ();
//绘制顶层视图RenderNode。
canvas.drawRenderNode(view.updateDisplayListIfDirty());
canvas.disableZ();
callbacks.onPostDraw(canvas);
canvas.restoreToCount(saveCount);
mRootNodeNeedsUpdate = false;
} finally {
mRootNode.endRecording();
}
}
}
同样，通过根 RenderNode 创建 RecordingCanvas，通过它的 drawRenderNode 方法，负责绘制顶层视图 DecorView 的 RenderNode 节点。
这里需要注意的一点是，这里根 RenderNode 创建的 Canvas 不属于任一个 View 视图，因为 Canvas 是 View 的 RenderNode 搞出来的，顶层 RenderNode 不依赖任何 View，Canvas 负责绘制 DecorView 的 RenderNode。
看一下 RecordingCanvas 的 drawRenderNode 方法，其中还会调用一次根 View 的 updateDisplayListIfDirty 方法，不会再进行一次 View 树绘制，这时的 view 还是 DecorView，它的 RecordingCanvas 已经 end 结束记录，并且，View 的 RenderNode 节点 mValid 已有效。
五 纯软件绘制 VS 硬件加速
下面根据具体的几种场景，具体分析一下硬件加速前后的流程与加速效果。
| 渲染场景 | 纯软件绘制 | 硬件加速 | 加速效果分析 |
|---|---|---|---|
| 页面初始化 | 绘制所有View | 创建所有DisplayList | GPU分担了复杂计算任务 |
| 在一个复杂页面调用背景透明TextView的setText()，且调用后其尺寸位置不变 | 重绘脏区所有View | TextView及每一级父View重建DisplayList | 重叠的兄弟节点不需CPU重绘，GPU会自行处理 |
| TextView逐帧播放Alpha / Translation / Scale动画 | 每帧都要重绘脏区所有View | 除第一帧同场景2，之后每帧只更新TextView对应RenderNode的属性 | 刷新一帧性能极大提高，动画流畅度提高 |
| 修改TextView透明度 | 重绘脏区所有View | 直接调用RenderNode.setAlpha()更新 | 加速前需全页面遍历，并重绘很多View；加速后只触发DecorView.updateDisplayListIfDirty，不再往下遍历，CPU执行时间可忽略不计 |
场景1中，无论是否加速，遍历 View 树并都会走 Draw 路径。硬件加速后 Draw 路径不做实际绘制工作，只是构建 DisplayList，复杂的绘制计算任务被 GPU 分担，已经有了较大的加速效果。
场景2中，TextView 设置前后尺寸位置不变，不会触发重新 Layout。
- 软件绘制时，TextView 所在区域即为脏区。由于 TextView 有透明区域，遍历 View 树的过程中，和脏区重叠的多数 View 都要重绘，包括与之重叠的兄弟节点和他们的父节点（详见后面的介绍），不需要绘制的 View 在 draw(canvas,parent,drawingTime) 方法中判断直接返回
- 硬件加速后，也需要遍历 View 树，但只有 TextView 及其每一层父节点需要重建 DisplayList，走的是 Draw 路径，其他 View 直接走了 DisplayList 路径，剩下的工作都交给 GPU 处理。页面越复杂，两者性能差距越明显。
场景3中，软件绘制每一帧都要做大量绘制工作，很容易导致动画卡顿。硬件加速后，动画过程直接走 DisplayList 路径更新 DisplayList 的属性，动画流畅度能得到极大提高。
场景4中，两者的性能差距更明显。简单修改透明度，软件绘制仍然要做很多工作；硬件加速后一般直接更新 RenderNode 的属性，不需要触发 invalidate，也不会遍历 View 树（除了少数 View 可能要对 Alpha 做特殊响应并在 onSetAlpha() 返回 true，代码如下）。
public class View {
......
public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {
ensureTransformationInfo();
if (mTransformationInfo.mAlpha != alpha) {
setAlphaInternal(alpha);
if (onSetAlpha((int) (alpha * 255))) {
......
invalidate(true);
} else {
......
mRenderNode.setAlpha(getFinalAlpha());
......
}
}
}
protected boolean onSetAlpha(int alpha) {
return false;
}
......
}
六 软件绘制刷新逻辑简介
实际阅读源码并实验，得出通常情况下的软件绘制刷新逻辑：
１．默认情况下，View 的 clipChildren 属性为 true，即每个 View 绘制区域不能超出其父 View 的范围。如果设置一个页面根布局的 clipChildren 属性为 false，则子 View 可以超出父 View 的绘制区域。
２．当一个 View 触发 invalidate，且没有播放动画、没有触发 layout 的情况下：
- 对于全不透明的 View，其自身会设置标志位 PFLAG_DIRTY，其父 View 会设置标志位 PFLAG_DIRTY_OPAQUE。在 draw(canvas) 方法中，只有这个 View 自身重绘
- 对于可能有透明区域的 View，其自身和父 View 都会设置标志位 PFLAG_DIRTY
- clipChildren 为 true 时，脏区会被转换成 ViewRoot 中的 Rect，刷新时层层向下判断，当 View 与脏区有重叠则重绘。如果一个 View 超出父 View 范围且与脏区重叠，但其父 View 不与脏区重叠，这个子 View 不会重绘
- clipChildren 为 false 时，ViewGroup.invalidateChildInParent() 中会把脏区扩大到自身整个区域，于是与这个区域重叠的所有 View 都会重绘。
七 总结
至此，硬件加速相关的内容就介绍完了，这里做个简单总结：
- CPU 更擅长复杂逻辑控制，而 GPU 得益于大量 ALU 和并行结构设计，更擅长数学运算。
- 页面由各种基础元素（DisplayList）构成，渲染时需要进行大量浮点运算。
- 硬件加速条件下，CPU 用于控制复杂绘制逻辑、构建或更新 DisplayList；GPU 用于完成图形计算、渲染 DisplayList。
- 硬件加速条件下，刷新界面尤其是播放动画时，CPU 只重建或更新必要的 DisplayList，进一步提高渲染效率。
- 实现同样效果，应尽量使用更简单的 DisplayList，从而达到更好的性能（Shape 代替 Bitmap 等）。
扫一扫
171
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
