主线程MainThread与渲染线程RenderThread

在Android 5.0以前，Android应用程序的主线程同时也是一个Open GL线程。可是从Android 5.0以后，Android应用程序的Open GL线程就独立出来了，称为Render Thread.

Android系统的UI从绘制到显示到屏幕是分两步进行的：第一步是在Android应用程序进程这一侧进行的；第二步是在SurfaceFlinger进程这一侧进行的。前一步将UI绘制到一个图形缓冲区中，而且将该图形缓冲区交给后一步进行合成以及显示在屏幕中。其中，后一步的UI合成一直都是以硬件加速方式完成的。

 注：在3.0前，Android应用程序UI绘制不支持硬件加速。不过从4.0开始，Android系统一直以“run fast, smooth, and responsively”为目标对UI进行优化。 注意，上面咱们说Android系统不支持硬件加速的UI 绘制，针对的是Android应用程序2D UI绘制;  对于3D UI，例如游戏，一直是支持硬件加速渲染的。

 

在支持Android应用程序UI硬件加速渲染以前，Android应用程序UI的绘制是以软件方式进行的，为了更好地理解Android应用程序UI硬件加速渲染技术，咱们先回顾在Android应用程序窗口（Activity）实现框架简要介绍和学习计划这个系列的文章说起的软件渲染技术，如图1所示：

图1 Android应用程序UI软件渲染过程

      在Android应用程序进程这一侧，每个窗口都关联有一个Surface。每当窗口须要绘制UI时，就会调用其关联的Surface的成员函数lock得到一个Canvas，其本质上是向SurfaceFlinger服务Dequeue一个Graphic Buffer。Canvas封装了由Skia提供的2D UI绘制接口，而且都是在前面得到的Graphic Buffer上面进行绘制的。绘制完成以后，Android应用程序进程再调用前面得到的Canvas的成员函数unlockAndPost请求显示在屏幕中，其本质上是向SurfaceFlinger服务Queue一个Graphic Buffer，以便SurfaceFlinger服务能够对Graphic Buffer的内容进行合成，以及显示到屏幕上去。

 

      接下来咱们再来看Android应用程序UI硬件加速渲染技术，如图2所示：

图2 Android应用程序UI硬件加速渲染过程    

       从图2能够看到，硬件加速渲染和软件渲染同样，在开始渲染以前，都是要先向SurfaceFlinger服务Dequeue一个Graphic Buffer。不过对硬件加速渲染来讲，这个Graphic Buffer会被封装成一个ANativeWindow，而且传递给Open GL进行硬件加速渲染环境初始化。在Android系统中，ANativeWindow和Surface能够是认为等价的，只不过是ANativeWindow经常使用于Native层中，而Surface经常使用于Java层中。另外，咱们还能够将ANativeWindow和Surface看做是像Skia和Open GL这样图形渲染库与操做系统底层的图形系统创建链接的一个桥梁。

       Open GL得到了一个ANativeWindow，而且进行了硬件加速渲染环境初始化工做以后，Android应用程序就能够调用Open GL提供的API进行UI绘制了，绘制出来内容就保存在前面得到的Graphic Buffer中。当绘制完毕，Android应用程序再调用libegl库提供的一个eglSwapBuffer接口请求将绘制好的UI显示到屏幕中，其本质上与软件渲染过程是同样的，都是向SurfaceFlinger服务Queue一个Graphic Buffer，以便SurfaceFlinger服务能够对Graphic Buffer的内容进行合成，以及显示到屏幕上去。

 

   这里咱们首先要明确什么是硬件加速渲染，其实就是经过GPU来进行渲染。GPU做为一个硬件，用户空间是不能够直接使用的，它是由GPU厂商按照Open GL规范实现的驱动间接进行使用的。也就是说，若是一个设备支持GPU硬件加速渲染，那么当Android应用程序调用Open GL接口来绘制UI时，Android应用程序的UI就是经过硬件加速技术进行渲染的。所以，在接下来的描述中，咱们说起到GPU、硬件加速和Open GL时，它们表达的意思都是等价的。 

 

 

(一) Android应用程序UI硬件加速渲染技术简要介绍和学习计划

 

(二)Android应用程序UI硬件加速渲染环境初始化过程分析