Android中的硬件加速那么好用？为啥没被普及？

浅谈

前几天有个朋友问我：Android中硬件加速那么好用，为啥没被普及？，嗯？其实我也想知道。。。

手机开发中最重要的两个点：

• 
  
• 1.用户点击的流畅性
  
• 2.界面效果的展示
  

早期的Android系统这两个事件都是在主线程上执行，导致用户点击的时候，界面绘制停滞或者界面绘制的时候，用户点击半天不响应，体验性很差。

于是在4.0以后，以 “run fast, smooth, and responsively” 为核心目标对 UI 进行了优化，应用开启了硬件加速对UI进行绘制。

1.硬件加速

在之前文章中我们分析过，Android 屏幕的绘制流程分为两部分：

• 
  
• 1.生产者:app侧将View渲染到一个buffer中，供SurfaceFlinger消费
  
• 2.消费者:SurfaceFlinger测将多个buffer合并后放入buffer中，供屏幕显示
  

其中 第二步一直都是在GPU中实现的，而我们所说的硬件加速就是第一步中的view渲染流程。

早期view的渲染是在主线程中进行的，而硬件加速则使用一个新的线程RenderThread以及硬件GPU进行渲染，

2.CPU / GPU结构对比

• 
  
• CPU （Central Processing Unit）: 中央处理器，计算机设备核心器件，适用于一些复杂的计算。
  
• GPU （Graphic Processing Unit）: 图形处理器，通常所说“显卡”的核心部件就是GPU，主要用于处理图形运算。
  

CPU和GPU结构对比：

• 
  
• 黄色代表控制器（Control）：用于协调控制整个CPU的运行，包括取指令等操作。
  
• 绿色的ALU（Arithmetic Logic Unit）：算数逻辑单元，主要用于进行数学，逻辑计算。
  
• 橙色的Cache和DRAM分别为缓存和RAM，用于存储信息。
  

1.结构上看：CPU的ALU较少，而了解过OpenGl的同学应该知道View的渲染过程中是有大量的浮点数计算的，而浮点数转换为整数计算，可能会消耗大量的ALU单元，这对于CPU是比较难接受的。

2.CPU是串行的，一个CPU同一时间只能做一件事情，（多线程其实也是将CPU时间片分割而已），而GPU内部使用的是几千个小的GPU内核，每个GPU内核处理单元都是并行的，
这就非常符合图形的渲染过程。

GPU是显卡的核心部分，在破解密码方面也非常出色，再知道为啥哪些挖矿的使用的是显卡而不是CPU了吧，一个道理。

硬件加速底层原理：

通过将计算机不擅长的图形计算指令使用特殊的api转换为GPU的专用指令，由GPU完成。这里可能是传统的OpenGL或其他开放语言。

3.OpenGL

Android端一般使用OpenGL ES来实现硬件加速。
这里简单介绍下OpenGL和OpenGL ES。

• 
  
• OpenGL（Open Graphics Library）：开放式图形库，是用于渲染2D、3D矢量图形的跨语言、跨平台的应用程序编程接口（API）。这个接口由近350个不同的函数调用组成，
  用来绘制从简单的图形比特到复杂的三维景象。
  
• OpenGL ES(OpenGL for Embedded Systems):是 OpenGL 三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计
  

如果一个设备支持GPU硬件加速渲染（有可能不支持，看GPU厂商是不是适配了OpenGL 等接口），
那么当Android应用程序调用Open GL接口来绘制UI时，Android应用程序的 UI 就是通过GPU进行渲染的。

4.Android图形系统整体架构

在介绍Android图像系统架构前，我们先来了解几个概念：如果把UI的绘制过程当成一幅画的制作过程：
那么：

• 
  
• 
  

  1.画笔：

  
  
  • 
    
  • Skia：CPU用来绘制2D图形
    
  • Open GL /ES:GPU绘制2D和3D图形。
    
  
  
  
• 
  

  2.画纸：
  Surface：所有的绘制和渲染都是在这张画纸上进行，每个窗口都是一个DecorView的容器，同时每个窗口都关联一个Surface

  
  
  
• 
  

  3.画板：
  Graphic Buffer ：Graphic Buffer是谷歌在4.1以后针对双缓冲的jank问题提出的第三个缓冲，CPU/GPU渲染的内容都将写到这个buffer上。

  
  
  
• 
  

  4.合成
  SurfaceFlinger：将所有的Surface合并叠加后显示到一个buffer里面。

  
  
  

简单理解过程：我们使用画笔（Skia、Open GL ES）将内容画到画纸（Surface）中，这个过程可能使用OpenGl ES也可能使用Skia，
使用OpenGl ES表示使用了硬件加速绘制，使用Skia，表示使用的是纯软件绘制。

下面是Android 图形系统的整体架构：

• 
  
• 
  

  Image Stream Producers：图像数据流生产者，图像或视频数据最终绘制到Surface中。

  
  
  
• 
  

  WindowManager ：前面一篇文章《WindowManager体系（上）》笔者说过,每个Surface都有一个Window和他一一对应，而WindowManager则用来管理窗口的各个方面：
  动画，位置，旋转，层序，生命周期等。

  
  
  
• 
  

  SurfaceFlinger：用来对渲染后的Surface进行合并，并传递给硬件抽象层处理。

  
  
  
• 
  

  HWC ： Hardware Composer，SurfaceFlinger 会委派一些合成的工作给 Hardware Composer 以此减轻 GPU 的负载。这样会比单纯通过 GPU 来合成消耗更少的电量。

  
  
  
• 
  

  Gralloc（Graphics memory allocator）：前面讲解的Graphic Buffer分配的内存。

  
  
  

5.软硬件绘制过程源码解析

前面讲解了那么多理论知识，下面从源码角度来分析下硬件加速和软件绘制过程。
“read the fking source”

在前面文章《》中分析过。View最终是在ViewRootImpl的performDraw方法最新渲染的，
而performDraw内部调用的是draw方法。
定位到draw方法：

private void draw(boolean fullRedrawNeeded) {

    ...
if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {
if (mAttachInfo.mThreadedRenderer != null && mAttachInfo.mThreadedRenderer.isEnabled()) {//1

            ...

            mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);//2

    }else {
if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {//3
return;

            }

        }

    }


}

注释1：如果mThreadedRenderer不为null且isEnabled为true，则调用注释2处的mThreadedRenderer.draw，这个就是硬件绘制的入口

如果其他情况，则调用注释3处的drawSoftware，这里就是软件绘制的入口，再正式对软硬件绘制进行深入之前我们看下mAttachInfo.mThreadedRenderer是在哪里赋值的?

源码全局搜索下：我们发现ViewRootImpl的enableHardwareAcceleration方法中有创建mThreadedRenderer的操作。

private void enableHardwareAcceleration(WindowManager.LayoutParams attrs) {
// Try to enable hardware acceleration if requested

    ...
final boolean hardwareAccelerated =

                    (attrs.flags & WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED) != 0;
//这里如果attrs.flags设置了WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED，则表示该Window支持硬件加速绘制
if (hardwareAccelerated) {

// Persistent processes (including the system) should not do
// accelerated rendering on low-end devices.  In that case,
// sRendererDisabled will be set.  In addition, the system process
// itself should never do accelerated rendering.  In that case, both
// sRendererDisabled and sSystemRendererDisabled are set.  When
// sSystemRendererDisabled is set, PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED
// can be used by code on the system process to escape that and enable
// HW accelerated drawing.  (This is basically for the lock screen.)

//Persistent的应用进程以及系统进程不能使用硬件加速
final boolean fakeHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FAKE_HARDWARE_ACCELERATED) != 0;
final boolean forceHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED) != 0;

if (fakeHwAccelerated) {


                    mAttachInfo.mHardwareAccelerationRequested = true;

            } else if (!ThreadedRenderer.sRendererDisabled

                            || (ThreadedRenderer.sSystemRendererDisabled && forceHwAccelerated)) {
if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mThreadedRenderer.destroy();

                    }

                    ...
//这里创建了mAttachInfo.mThreadedRenderer

                    mAttachInfo.mThreadedRenderer = ThreadedRenderer.create(mContext, translucent,

                                    attrs.getTitle().toString());
if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mHardwareAccelerated =

                                            mAttachInfo.mHardwareAccelerationRequested = true;

                    }

            }

    }

}

这里源码告诉我们：

• 
  
• 1.硬件加速是通过attrs.flags 设置WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED标识来启动的、
  
• 2、因为硬件加速是一个耗内存的操作，只是硬件加速渲染环境初始化这一操作，就要花掉8M的内存，
  所以一般永久性的进程或者系统进程不要使用硬件加速标志，防止出现内存泄露。
  

再看哪里调用enableHardwareAcceleration方法?
通过源码查找我们注意到ViewRootImpl的setView方法中：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
//注释1
if (view instanceof RootViewSurfaceTaker) {

		mSurfaceHolderCallback =

				((RootViewSurfaceTaker)view).willYouTakeTheSurface();
if (mSurfaceHolderCallback != null) {

			mSurfaceHolder = new TakenSurfaceHolder();

			mSurfaceHolder.setFormat(PixelFormat.UNKNOWN);

			mSurfaceHolder.addCallback(mSurfaceHolderCallback);

		}

	}


	...

// If the application owns the surface, don't enable hardware acceleration
if (mSurfaceHolder == null) {//注释2

		enableHardwareAcceleration(attrs);

	}


}

注释1处：表示当前view实现了RootViewSurfaceTaker接口，且view的willYouTakeTheSurface返回的mSurfaceHolderCallback不为null，
则表示应用想自己接管所有的渲染操作，这样创建出来的Activity窗口就类似于一个SurfaceView一样，完全由应用程序自己来控制它的渲染

基本上我们是不会将一个Activity窗口当作一个SurfaceView来使用的，
因此在ViewRootImpl类的成员变量mSurfaceHolder将保持为null值，
这样就会导致ViewRootImpl类的成员函数enableHardwareAcceleration被调用为判断是否需要为当前创建的Activity窗口启用硬件加速渲染。

好了我们回到ViewRootImpl的draw方法：

1.先来看软件绘制

软件绘制调用的是drawSoftware方法。
进入

private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,
boolean scalingRequired, Rect dirty) {

	...

	canvas = mSurface.lockCanvas(dirty);//1


	mView.draw(canvas);//2


	surface.unlockCanvasAndPost(canvas);//3


}

软件绘制基本就分三步走：

• 
  
• 步骤1：lockCanvas：每个Window都关联了一个Surface，当有需要绘制UI时，就调用lockCanvas获取一个Canvas对象，这个Canvas封装了Skia提供的2D图形绘制api、
  

并且向SurfaceFlinger Dequeue了一块Graphic buffer，绘制的内容都会输出到这个buffer中，供SurfaceFlinger合成使用。

• 
  
• 
  

  步骤2：draw：调用了View的draw方法，这个就会调用到我们自定义组件中View的onDraw方法，传入1中创建的Canvas对象，使用Skia api对图像进行绘制。

  
  
  
• 
  

  步骤3：unlockCanvasAndPost：绘制完成后，通知SurfaceFlinger绘制完成，可以进行buffer的交换，显示到屏幕上了，本质是给SurfaceFlinger queue 一个Graphic buffer、
  关于什么是Queue和Dequeue看下图：

  
  
  

软件绘制条形简图：

2.硬件加速分析：

硬件加速分为两个步骤：

• 
  
• 1.构建阶段
  
• 2.绘制阶段
  

构建阶段：

这个阶段用于遍历所有的视图，将需要绘制的Canvas API调用及其参数记录下来，保存在一个Display List，这个阶段发生在CPU主线程上。

Display List本质上是一个缓存区，它里面记录了即将要执行的绘制命令序列，这些命令最终会在绘制阶段被OpenGL转换为GPU渲染指令。

视图构建阶段会将每个View抽象为一个RenderNode，每个View的绘制操作抽象为一系列的DrawOp，
比如：
View的drawLine操作会被抽象为一个DrawLineOp，drawBitmap操作会被抽象成DrawBitmapOp，每个子View的绘制被抽象成DrawRenderNodeOp，每个DrawOp都有对应的OpenGL绘制指令，同时内部也握有需要绘制的数据元。

使用Display List的好处：

• 
  
• 1、在绘制窗口的下一帧时，如果某个视图UI没有发生变化，则不需要执行与他相关的Canvas API操作，即不用重复执行View的onDraw操作，
  而是直接使用上一帧的Display List即可
  
• 2.如果绘制窗口下一帧时，视图发生了变化，但是只是一些简单属性变化，如位置和透明度等，则只需要修改上次构建的Display List的相关属性即可，也不必重复构建
  

Display List模型图：

接下来我们从源码角度来看下：

前面我们分析了硬件加速入口是在ThreadedRenderer的draw方法：

mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this)

进入这个方法看看：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

	...

	updateRootDisplayList(view, callbacks);//1

	...
int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2通知RenderThread线程绘制

}

ThreadedRenderer主要作用就是在主线程CPU中视图的构建，然后通知RenderThread使用OpenGL进行视图的渲染（注释2处）。

注释1处：updateRootDisplayList看名称应该就是用于视图构建，进去看看

private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {
//1.构建参数view(DecorView)视图的Display List

	updateViewTreeDisplayList(view);

//2
//mRootNodeNeedsUpdate true表示需要更新视图
//mRootNode.isValid()  表示已经构建了Display List
if (mRootNodeNeedsUpdate || !mRootNode.isValid()) {
//获取DisplayListCanvas

		DisplayListCanvas canvas = mRootNode.start(mSurfaceWidth, mSurfaceHeight);//3
try {
//ReorderBarrie表示会按照Z轴坐标值重新排列子View的渲染顺序

			canvas.insertReorderBarrier();
//构建并缓存所有的DrawOp

			canvas.drawRenderNode(view.updateDisplayListIfDirty());

			canvas.insertInorderBarrier();


			canvas.restoreToCount(saveCount);

		} finally {
//将所有的DrawOp填充到根RootNode中，作为新的Display List

			mRootNode.end(canvas);

		}

	}

}

注释1：updateViewTreeDisplayList对View树Display List进行构建

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;

}

看View的updateDisplayListIfDirty方法。

/**

 * Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)

 * @hide

 */
@NonNull
public RenderNode updateDisplayListIfDirty() {
//获取当前mRenderNode
final RenderNode renderNode = mRenderNode;
//2.判断是否需要进行重新构建
if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0

                || !renderNode.isValid()

                || (mRecreateDisplayList)) {

if (renderNode.isValid()

                    && !mRecreateDisplayList) {

			mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;

			mPrivateFlags &= ~PFLAG_DIRTY_MASK;
//这里用于当前View是ViewGroup，且自身不需要重构，对其子View的DisplayList进行构建

			dispatchGetDisplayList();

return renderNode; // no work needed

        }

		...
final DisplayListCanvas canvas = renderNode.start(width, height);
try {
if (layerType == LAYER_TYPE_SOFTWARE) {
//软件绘制

				buildDrawingCache(true);

				Bitmap cache = getDrawingCache(true);
if (cache != null) {

					canvas.drawBitmap(cache, 0, 0, mLayerPaint);

				}

			} else {

				...
if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {
//View是ViewGroup，需要绘制子View

					dispatchDraw(canvas);

					...

				} else {

					draw(canvas);

				}

			}

		} finally {
//将绘制好后的数据填充到renderNode中去

			renderNode.end(canvas);

			setDisplayListProperties(renderNode);

		}

	}

}

updateDisplayListIfDirty主要作用：

• 
  
• 1.获取当前View的RenderNode。
  
• 2.如果需要或者支持则更新当前DisplayList
  

判断是否需要进行重新构建的条件如下：

• 
  
• 1.mPrivateFlags 设置了 PFLAG_DRAWING_CACHE_VALID，表明当前缓存已经失效，需要重新构建
  
• 2.!renderNode.isValid()：表明当前Display List的数据不合法，需要重新构建
  
• 3.mRecreateDisplayList的值等于true，一些其他原因需要重新构建
  

mRenderNode在View的构造方法中初始化：

public View(Context context) {

	...

	mRenderNode = RenderNode.create(getClass().getName(), this);

}

构建过程如下：

• 
  
• 1.使用renderNode.start获得一个与当前View关联的DisplayListCanvas。
  
• 2.使用draw(canvas)，将当前View以及子View绘制到当前DisplayListCanvas
  
• 3.使用renderNode.end(canvas)，将已经绘制在 DisplayListCanvas 的 Display List Data 填充到当前 View 关联的 Render Node 中
  

通过上面几个步骤就将View树对应的DisplayList构建好了。而且这个构建过程会递归构建子View的Display List

我们从绘制流程火焰图中也可以看到大概流程：

红色框中部分：是绘制的DecorView的时候，一直递归updateDisplayListIfDirty方法进行Display List的构建
其他颜色框部分是子View Display List的构建

绘制阶段

这个阶段会调用OpenGL接口将构建好视图进行绘制渲染，将渲染好的内容保存到Graphic buffer中，并提交给SurfaceFlinger。

回到ThreadedRenderer的draw方法：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

    ...

    updateRootDisplayList(view, callbacks);//1

    ...
int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2

}

在注释1中创建好视图对应的Display List后，在注释2处调用nSyncAndDrawFrame方法通知RenderThread线程进行绘制

nSyncAndDrawFrame是一个native方法，在讲解nSyncAndDrawFrame方法前我们先来看ThreadedRenderer构造函数中做了哪些事。

ThreadedRenderer(Context context, boolean translucent, String name) {
//这个方法在native层创建RootRenderNode对象并返回对象的地址

	long rootNodePtr = nCreateRootRenderNode();

	mRootNode = RenderNode.adopt(rootNodePtr);

	mRootNode.setClipToBounds(false);
//这个方法在native层创建一个RenderProxy

	mNativeProxy = nCreateProxy(translucent, rootNodePtr);

}

nCreateRootRenderNode和nCreateProxy方法在android_view_ThreadedRenderer.cpp中实现：

static jlong android_view_ThreadedRenderer_createRootRenderNode(JNIEnv* env, jobject clazz) {

    RootRenderNode* node = new RootRenderNode(env);

    node->incStrong(0);

    node->setName("RootRenderNode");
return reinterpret_cast(node);

}
static jlong android_view_ThreadedRenderer_createProxy(JNIEnv* env, jobject clazz,

        jboolean translucent, jlong rootRenderNodePtr) {

    RootRenderNode* rootRenderNode = reinterpret_cast(rootRenderNodePtr);
ContextFactoryImpl factory(rootRenderNode);
return (jlong) new RenderProxy(translucent, rootRenderNode, &factory);

}

RenderProxy构造方法：

RenderProxy::RenderProxy(bool translucent, RenderNode* rootRenderNode, IContextFactory* contextFactory)

        : mRenderThread(RenderThread::getInstance())//1

        , mContext(nullptr) {

    ...

}*>

注意到mRenderThread使用的是RenderThread::getInstance()单例线程，也就说整个绘制过程只有一个RenderThread线程。

接着看RenderThread::getInstance()创建线程的方法：

RenderThread::RenderThread() : Thread(true)

	...

	Properties::load();

    mFrameCallbackTask = new DispatchFrameCallbacks(this);

    mLooper = new Looper(false);

    run("RenderThread");

}

居然也是使用的Looper，是不是和我们的主线程的消息机制一样呢？哈哈
调用run方法会执行RenderThread的threadLoop方法。

bool RenderThread::threadLoop() {
...
int timeoutMillis = -1;
for (;;) {
int result = mLooper->pollOnce(timeoutMillis);
...
nsecs_t nextWakeup;
{
...
while (RenderTask* task = nextTask(&nextWakeup)) {
workQueue.push_back(task);
}
for (auto task : workQueue) {
task->run();
// task may have deleted itself, do not reference it again
}
}
if (nextWakeup == LLONG_MAX) {
timeoutMillis = -1;
} else {
nsecs_t timeoutNanos = nextWakeup - systemTime(SYSTEM_TIME_MONOTONIC);
timeoutMillis = nanoseconds_to_milliseconds(timeoutNanos);
if (timeoutMillis < 0) {
timeoutMillis = 0;
}
}

if (mPendingRegistrationFrameCallbacks.size() && !mFrameCallbackTaskPending) {
...
requestVsync();
}

if (!mFrameCallbackTaskPending && !mVsyncRequested && mFrameCallbacks.size()) {
...
requestVsync();
}
}

return false;
}

石锤了就是应用程序主线程的消息机制模型，

• 
  
• 
  
  1. 
     
  2. 空闲的时候，Render Thread就睡眠在成员变量mLooper指向的一个Looper对象的成员函数pollOnce中。
     
  
  
  
• 
  
  2. 
     
  3. 当其它线程需要调度Render Thread，就会向它的任务队列增加一个任务，然后唤醒Render Thread进行处理。Render Thread通过成员函数nextTask获得需要处理的任务，并且调用它的成员函数run进行处理。
     
  
  
  

这里做个小结：
ThreadedRenderer构造方法中

• 
  
• 1.初始化mRootNode指向native层的一个RootRenderNode
  
• 2.初始化mNativeProxy指向native层的RenderProxy
  
• 3.在native层创建RenderProxy时，同时也会创建RenderThread线程，这个线程机制和我们主线程消息机制一直，轮询等待获取绘制任务。
  

好了回头看nSyncAndDrawFrame的native方法

nSyncAndDrawFrame同样也在android_view_ThreadedRenderer.cpp中实现：

static int android_view_ThreadedRenderer_syncAndDrawFrame(JNIEnv* env, jobject clazz,

        jlong proxyPtr, jlongArray frameInfo, jint frameInfoSize) {

    LOG_ALWAYS_FATAL_IF(frameInfoSize != UI_THREAD_FRAME_INFO_SIZE,
"Mismatched size expectations, given %d expected %d",

            frameInfoSize, UI_THREAD_FRAME_INFO_SIZE);

    RenderProxy* proxy = reinterpret_cast(proxyPtr);

    env->GetLongArrayRegion(frameInfo, 0, frameInfoSize, proxy->frameInfo());
return proxy->syncAndDrawFrame();

}*>

这个方法返回值是proxy->syncAndDrawFrame()，进入RenderProxy的syncAndDrawFrame方法：

int RenderProxy::syncAndDrawFrame() {
return mDrawFrameTask.drawFrame();

}

这里的 mDrawFrameTask.drawFrame其实就是向RenderThread的TaskQueue添加一个drawFrame渲染任务，通知RenderThread渲染UI视图。

如下图：

mDrawFrameTask是DrawFrameTask中的函数

int DrawFrameTask::drawFrame() {

	...

    postAndWait();

return mSyncResult;

}

void DrawFrameTask::postAndWait() {

    AutoMutex _lock(mLock);

    mRenderThread->queue(this);

    mSignal.wait(mLock);//锁住等待锁释放

}

void RenderThread::queue(RenderTask* task) {

    AutoMutex _lock(mLock);

    mQueue.queue(task);
if (mNextWakeup && task->mRunAt < mNextWakeup) {

        mNextWakeup = 0;

        mLooper->wake();

    }

}

看到这就知道了drawFrame其实就是往RenderThread线程的任务队列mQueue中按时间顺序加入一个绘制task，并调用mLooper->wake()唤醒RenderThread线程处理。

说到底还是主线程消息机制那套东西。

注意DrawFrameTask在postAndWait的mRenderThread->queue(this)中是将this传入任务队列，所以此任务就是this自己。后面执行绘制任务就使用到了OpenGL对构建好的DisplayList进行渲染。

经过上面的分析，整个硬件绘制流程就有个清晰模型了

点到为止，后面代码大家可以自行找到源码阅读。

绘制阶段这块可能比较复杂些，因为基本上都是native层的东西，有的消化下。

硬件加速和纯软件绘制对比

呈现模式分析工具

Android 4.1（API 级别 16）或更高版本的设备上，

执行以下步骤开启工具：

• 
  
• 1.启动开发者选项；
  
• 2.在“监控”部分，找到“GPU呈现模式分析”（不同厂商命名有所区别）；
  
• 3.点击“GPU呈现模式分析”，弹出页面中，选择“在屏幕上显示为条形图”即可。
  

这时，GPU 呈现模式工具已经开启了，接下来，我们可以打开我们要测试的APP来进行观察测试了。

视觉呈现

GPU 渲染模式分析工具以图表（以颜色编码的直方图）的形式显示各个阶段及其相对时间。

Android 10 上显示的彩色部分：

注意点:

• 
  
• 1.一个应用对应一个图形
  
• 2.沿水平轴的每个竖条代表一个帧，每个竖条的高度表示渲染该帧所花的时间（以毫秒为单位）。
  
• 3.中间绿色的线是16.6ms的分割线，高于绿色线表示出现了掉帧
  
• 4.通过加宽竖条降低透明度来反应比较耗时的帧
  
• 5.每个竖条都有与渲染管道中某个阶段对应的彩色区段。区段数因设备的 API 级别不同而异。
  

颜色块含义

Android 6.0 及更高版本的设备时分析器输出中某个竖条的每个区段含义：

4.0（API 级别 14）和 5.0（API 级别 21）之间的 Android 版本具有蓝色、紫色、红色和橙色区段。低于 4.0 的 Android 版本只有蓝色、红色和橙色区段。下表显示的是 Android 4.0 和 5.0 中的竖条区段。

GPU 呈现模式工具，很直观的为我们展示了 APP 运行时每一帧的耗时详情。我们只需要关注代表每一帧的柱状图的颜色详情，就可以分析出卡顿的原因了。

好了，现在来回答标题帧的内容，既然硬件优化这么好用，为啥没被普及？

理由如下：

• 
  
• 1.稳定性，开启硬件加速后，有小概率出现画面崩溃，所以在一些视频播放器会给个开关让用户手动开关。
  
• 2.功耗：GPU的功耗远远大于CPU，所以使用场景比较少，一般在游戏端开启硬件加速辅助游戏运行。
  
• 3.内存消耗：使用OpenGL接口初始化就需要8M作用的内存。
  
• 4.兼容性：不兼容某些接口和api。
  

这就是所谓的双刃剑吧！用得好还好，用不好就鸽蛋了。。