在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时，它们表达的意思都是等价的。