Hardware Composer



转自http://blog.csdn.net/new_szsheep/article/details/41348581

Hardware Composer HAL ("HWC") 首次在Android 3.0被引进，经过数年已经变得很稳定了。它主要的目的是选择最高效的途径来合成buffer。作为HAL，它的实现是依赖设备的，并通常由OEM显示硬件厂家完成。

这个方法的价值在于可以很容易的识别你该什么时候用”Overlay planes“。Overlay plane的使用目的就是把多个buffer在显示器而不是GPU那里合成起来。举个例子，假设你有一台Android手机竖着摆，屏幕上有状态栏和导航栏以及其他地方是应用UI。每一个图层的内容都在分开的buffer里。你可以先把应用的内容画好在一个草稿图层那里，接着把状态栏的图层着色，接着是导航栏，最后把草稿图层的buffer发往显示设备。又或者，你可以把三个buffer都送到显示设备硬件，然后告知它从三个不同的buffer获取内容，在屏幕的不同部分进行着色。明显，最后的办法更高效。

正如你所想的，不同显示设备的处理能力明显有区别。overlay的数量，图层是否可旋转或混合，以及对位置和重叠的束缚会比较困难通过API来展现。因此HWC如下工作：

1. SurfaceFlinger提供给HWC一个完整的图层列表，并询问”你将如何处理它“
2. HWC通过在每个图层上标明”重叠 overlay"或”GLES 合成“来响应。
3. SurfaceFlinger来处理所有的GLES合成，把输出buffer发给HWC并让HWC处理剩余的事情

因为这个决定的代码是可以由硬件提供商客制化，故此这是最有可能获取最高表现。

        当屏幕没有更新的情况下，overlay plane比GL合成显得更低效率。这尤其在overlay的内容有透明像素，并且重叠图层混合在一起时候。这种情况，HWC可以选择请求GLES来合成一些或全部图层，同时保留合成的buffer。如果SurfaceFlinger又回来要求合成同样的buffer组时候，HWC可以仅仅只显示之前合成好的草稿buffer。

       Android 4.4一般支持四个overlay plane。尝试合成比存在的图层更多的图层会导致系统使用GLES来合成部分图层。因此，应用使用的图层数量可以对电池消耗以及性能只有有数的影响。你可以通过adb shell dumpsys Surfaceflinger的命令来确切的显示SurfaceFlinger的工作情况。