Android Overlay优化方案.docx

Android Overlay优化方案摘要:总所周知overlay在android操作系统中，主要用于处理Camera preview和视频输出，以及地图图层叠加等。本文主要介绍android图层处理overlay模块从android 1.5（以marvell 310平台为例）至android 2.x改进和个人部分地方优化方案。1、Marvell 310平台的overlay特性分析从310cupcake（android1.5）开始，marvell就有使用overlay了，只是这个overlay真是太差强人意。源代码位于AR9960\vendor\marvell\littleton\overlay2display，其实就一个文件display.cpp，编译后位libMrvlOverlay.so，然后其他地方可以直接调用。可以看出，marvell自己做的相当省事，估计310平台的局限性吧，它也没把overlay做成一个通用的hal。其实overlay说起来很简单的东西，一个display.cpp 300多行代码，主要是对/dev/graphics/fb2进行内存映射，然后写入yuv图像数据，屏幕就出现图像了。关于overlay，其实它是对应framebuffer中的一层，即fb2这层。在310平台中，处于最底层的是fb0，这个就是所谓的主framebuffer，往上面就是fb2（overlay），fb1也算是overlay，不过是用于ui显示的，最上面的是fb3，用于显示硬件鼠标。Mavell 310平台的特性，fb0支持全透明不支持半透明，fb2不支持透明，fb1都支持。我们可以发现，不管是在cupcake，还是在donut，一旦使用了overlay，fb2都是盖住下面的主屏幕，导致系统显示无法透出来，在camera preview中就是这样的特性，所以marvell的camera preview就优先使用Surface纯软输出，没使用overlay。在video playerback中，更能发现，当视频正常播放时，全盘状态，没任何系统菜单时，播放显示都很流畅。但是，当点击屏幕，出现进度条时，就会发现屏幕闪了一下，播放开始迟钝。这就是marvell 310overlay的缺陷问题，他们自己都没去很好解决。当全屏播放时，确实使用了overlay，直接投影到屏幕的fb2上，当点击屏幕出现进度条时，就关闭了overlay，使用系统Surface软件输出，效率就大大降低。可以修改android_surface_output.cpp的代码，让视频播放时一直用overlay，这时候我们就会发现当点击屏幕时，进度条并看不到，这就是fb2挡住了fb0的原因。原来cupcake和donut的时候，即使使用了软件surface的输出，但是camera preview还算是很流畅，但是到了éclair，camera菜单图层叠加更加复杂，使用软件surface输出时，整个preview很卡，所以，我们不得不使用overlay。2、underlay方案通过对marvell 310平台datasheet的研究，发现framebuffer图层这边的层次关系可以做出调整，如下图所示，原先的默认方案是fb0处于最底层，通过对相关寄存器的配置，我们可以配置成underlay的方案，此方案fb0置于fb2的上面，由于fb0可以做到全透明，所以fb2就能透出来。underlay方案看似可以解决我们上面碰到的问题，但是，由于fb0无法做到半透明，所以camera和video等应用使用到overlay时，就无法看到半透明的菜单或是进度条效果。underlay的方案还要求定义透明色，在驱动这边通过设置相应寄存器，定义某种特殊的透明色，一旦fb0上有这种透明色，fb2就可以透出来。我们选择的透明色是0xf81f。这样，我们得定义一个规则，当使用camera或是video时，在显示范围内，当是黑色的，即0x0000时，就在hal中的framebuffer中把0x0000转换成0xf81f，最后再写入fb0。3、两种方案的比较除了上面这种underlay的方案，另外一个方案就是原来的video使用的方案。也就是说，在使用overlay时，overlay所在的区域不能有其他系统显示，不然会被挡住，当有菜单弹出来时，或是当overlay不应该显示在最顶层时，关闭overlay马上改用系统软件surface输出。很明显，这个方案更加不好，在video中，我们也了解到，弹出进度条时，会闪动一下，严重影响用户体验，而且当用到软件surface输出时，整个系统的显示效率很低。在android2.1中，如果不适用overlay，camera preview是很慢的，所以如果采用这种方案，当用户