该系列文章总纲链接:Android GUI系统之SurfaceFlinger 系列文章目录
说明:
- 关于导读:导读部分主要是方便初学者理解SurfaceFlinger代码中的机制,为后面分析代码打下一个更好的基础,这样就可以把更多的精力放在surfaceFlinger的业务逻辑分析上。
- 关于代码分支:以下代码分析均在android5.1.1_r3分支上,目录frameworks/native/services/surfaceflinger为root目录
1 surfaceFlinger作者简介
surfaceFlinger是一个名为Mathias Agopian的工程师编写的。作者Mathias Agopian有着BE和PalmSource的工作经历,于2006年加入了Android团队。他是一个晚睡晚起的人,常常很晚到公司,也很晚才离开。他是一个喜欢专注写代码而尽量避开所有会议的人。他是一个童年时期就学习电脑编程,并有所成就的人(曾为雅达利猎鹰开发图形和音频程序,并未计算机杂志撰写文章,后为Be开发了打印机驱动程序)。刚刚加入Android时,Mathias的工作主要是开发操作系统底层的东西,他曾对memcpy和memset进行优化,通过手写汇编代码来提升memcpy的效率,使性能有了巨大地提升。
2 PixelFlinger,平台思维的经典之作
对于图形系统而言,Mathias主要是实现surfaceFlinger的功能,用于显示应用程序生成的图形缓冲区,而这个系统当时需要依赖的底层功能当时还没有,所以需要从这些东西开始写。当时,Mathias假设surfaceFlinger需要用到GPU,将会使用OpenGLES来实现底层功能。此时问题就来了,没有GPU,又要用到GPU,这该怎么办?一般的产品思维是开发周期紧,所以我们要优先实现相关功能,等以后再调整,这是一个常规的解决方案,但还不够好。Mathias是图形方面的技术人员,对GPU渲染的趋势是有一定了解的,他预感到GPU会成为未来手机的主流标配,因此他做了这样一个决定:没有GPU硬件,那就虚拟一个GPU出来,这个虚拟的GPU软件可以理解为pixelFlinger,然后通过OpenGLES发送指令给这个pixelFlinger实现会长功能。也许这个决策会让短期内的工作量加大,但长期来看,这个技术的选型如果正确将会大大的减少整体的工作量,因为将要适配的产品并不只是当下这一款。
当然pixelFlinger的存在时间并不长,毕竟后来被GPU直接取代了。它的重要性不在于提供了什么功能,而在于它对平台的意义,构建具有前瞻性的功能,推动架构和生态系统进入硬件加速的未来,这一点无可匹敌。
3 SurfaceFlinger设计本质和原则
有了PixelFlinger和OpenGLES,就开始构建SurfaceFlinger了。SurfaceFlinger设计的本质就是应用程序图形操作和OpenGLES层之间的粘合剂,负责传递缓冲区并显示给用户。
为了实现流畅的图形渲染,设计原则之一就是确保任何一个应用都不会导致其他应用程序的渲染性能受到影响。所以应用程序将自己的图形绘制到缓冲区,SurfaceFlinger从那里开始接手工作。这个可以理解为今天代码中的dequeue和queue的操作的起源。
4 HWC(hardware Composer)
Mathias不仅搞定了SurfaceFlinger,还搞了一个硬件合成器HWC,SurfaceFlinger将UI绘制到窗口上,但绘制的像素由好多个窗口组成。因此就需要HWC需要将这些窗口以一种合理的方式显示出来。HWC将不同的窗口发送到不同的图层,将这些图层组合在一起并显示出来,让他们看起来是一个无缝衔接的屏幕,但实际上就是几个不同进程的产物、比如状态栏、导航栏、背景,多个应用等。
那么为什么使用HWC而不是GPU呢?因为HWC更省电,也更适合做单一的合成工作。但GPU耗电量大,同时对于游戏/高耗能3D渲染的应用,GPU的资源也很宝贵。