GUI系统之SurfaceFlinger(7)应用程序的典型绘图流程

文章都是通过阅读源码分析出来的，还在不断完善与改进中，其中难免有些地方理解得不对，欢迎大家批评指正。
转载请注明：From LXS. http://blog.youkuaiyun.com/uiop78uiop78/

GUI系统之SurfaceFlinger章节目录：
blog.youkuaiyun.com/uiop78uiop78/article/details/8954508

1.1.1 应用程序的典型绘图流程

我们知道，BufferQueue有最多达32个BufferSlot，这样设计的目的是什么？一个可能的原因就是提高图形渲染速度。因为假如只有两个buffer，可以想象一下，当应用程序这个生产者的产出效率大于消费者的处理速度时，很快它就会dequeue完所有缓冲区而处于等待状态，从而导致不必要的麻烦。当然，实际上32只是最大的容量，具体值是可以设置的，大家可以结合后面的ProjectButter小节来理解一下。

前面小节我们已经学习了BufferQueue的内部原理，那么应用程序又是如何与之配合的呢？

解决这个疑惑的关键就是了解应用程序是如何执行绘图流程的，这也是本节我们叙述的重点。不过大家应该有个心里准备，应用程序并不会直接使用BufferQueue。和Android系统中很多其它地方一样，“层层包裹”在这里同样是存在的，因而我们要尽量抓住其中的重点，并辅以一定的手段，才能更好更快地从诸多错综复杂的类关系中找出问题的答案。

出于以上原因的考虑，我们选取系统的开机动画这一应用程序，来分析整个图形绘制的流程。值得一提的是，这个开机动画的实现符合前面提到的两个改进的图形系统中的第一个，即应用程序与SurfaceFlinger都是使用OpenGL ES来完成UI显示，不过因为它是一个C++程序，所以不需要上层GLSurfaceView的支持。

当一个Android设备上电后，正常情况下它会先后显示最多4个不一样的开机画面，分别是：

l  boot-loader

这显然是第一个出现的画面。因为boot-loader只是负责系统后续模块的加载与启动，而且要求文件体积很小，所以一般我们只让它显示一张静态的图片

l  kernel

在进入内核后，同样会在物理屏幕上有所显示。和boot-loader一样，默认情况下它也只是一张静态图片

l  android(2个)

Android是系统启动的最后一个阶段，也是最耗时间的一个。它的开机画面既可以是静态文字描述、静态图片，也可以是动态画面。通常第一个是文字或者静态图片(假如指定路径下的图片不存在的话，就显示文字。关于这方面的资料很多，大家可以自行查阅，我们这里不作过多叙述)，另外一个则是动画，如下图所示：

图 11‑14 原生态Android系统中的开机动画

 

这个开机动画的实现类是BootAnimation，它的内部就是借助SurfaceFlinger来完成的。另外，因为它并不是传统意义上的Java层应用程序，这使得我们可以抛离很多上层的牵绊，以最直观的方式来审视BufferQueue的使用，是分析本节问题的最佳选择。

BootAnimation是一个C++程序，其工程源码路径是/frameworks/base/cmds/bootanimation。和很多native应用一样，它也是在init脚本中被启动的，大概来看下这一过程。

service bootanim /system/bin/bootanimation     class main     user graphics