在该章之后的几个小节会讲解解android显示系统的框架,主要为以下3点:
a.显示驱动framebuffer的原理及改进
b.多任务系统的显示:必定有一个显示管理者
c.android显示系统框架初探
首先我们先来看看显示驱动framebuffer的原理及改进
深入了解,请参考:
Android Graphic UI with GPU Hardware Acceleration
https://community.nxp.com/docs/DOC-93612
初学,暂时不去深究
显示系统的原理及改进
根据上图在一个芯片中,存在cpu,Display Controller,一般会在内存开辟一段空间(framebuffer)用来显示,SOC(运行操作系统的芯片)还会连接LCD,假设我们的lcd是600*800,如果每个字节用十六个像素(两字节)来表示,那么他对应的framebuffer = 800*600*2,也就是说每一个像素,都使用两个framebuffer描述他。
在上图中,我们可以看到,framebuffe只存在一个,当我们需要显示的时候,应用程序往framebuffer中写入数据,同时Display Controller会源源不断的把framebuffer的数据,搬运到LCD上进行显示。这个时候就存在两个动作同时访问framebuffe,一个写操作,一个读操作。
下面是只有一个framebuffe的缺点:
1.假设应用程序往framebuffer中写数据的速度非常慢,那么我们在LCD上看到图片变化会十分的缓慢,这样的效果是十分难接受的。
2.如果APP写FB的速度不快不慢,那么就会出现闪烁的现象。
3.APP写FB速度快,一切都OK(但是一般都没有那么快)
因为以上缺点,所以需要对驱动程序进行改进,怎么改进呢?其实就是多增加一个或者多个framebuffer,当APP往一个framebuffer完全写入数据的时候,才让驱动去读取framebuffer,当Display Controller在搬运数据的时候,APP可以往另外一个framebuffer写入数据,形成一个循坏,就能解决以上问题了。
下面是手机界面的两张图片:
可以看到在状态栏,除了时间之外,其他的都是一样的,导航栏是完全一样的,后面的壁纸是一样的,唯一不同的是那些应用程序的图标,那么如果我们的程序需要显示这两个图片,应该怎么做。
按照以前的办法显示图片:
1.framebuffer上面先描述状态栏。
2.描绘出导航栏。
3.描绘背景。
4.在把APP的图片也在framebuffer上进行描述。
对于2张图片都要进行相同的动作,其中的重复工作由那些:
1.状态栏(假设没有变化)。
2.导航栏。
3.背景。
那么有没有改进的额办法呢?,这里就需要硬件进行协助。同时引入了层的概念,如以下方式分层
第一层:状态栏,导航栏
第二层:背景
第三层:图标
然后把上面的3层合并在一起进行输出,这里的合成,是硬件(HardWare ConPoser)帮助我们进行合成,现在很多芯片都支持了硬件合成。
驱动支持HWC(即硬件合并):
一般来说,每一层都对应一个驱动:/dev/fbx。
APP操作某一层时,直接写对应的Framebuffer,硬件会自动进行合并。所以我们执行
ls /dev/graphics/fb*
可以看到多个:
/dev/graphics/fb0
/dev/graphics/fb1
/dev/graphics/fb2
/dev/graphics/fb3
/dev/graphics/fb4
/dev/graphics/fb5
/dev/graphics/fb6
/dev/graphics/fb7
其中一般来说,fb0到fb4对应芯片中的ch0到ch4(如果有兴趣,可以看一些LCD控制芯片的手册)。