时间真的是很巧,本来没打算写Surface系统的(相比AudioFlinger来说,Surface变化之后的难度真的是毛毛雨了),但为了庆祝泷泽萝拉发第二部大作,我决定还是要坚持一下。
下面将延续Audio的分析风格(),从几个层面来介绍Surface系统的变化(JB号称在Surface这块做过大量的优质的改进,无非就是引入在PC机上早都烂熟的VSYNC,Triple Buffering。但是JB,您能确保这套机制在单核机器上跑得开么?Win Phone 单核,都比多核Android机器流畅。恐怕还是Android上层Display架构有问题吧??!)
同Audio一样,想真正理解Surface系统工作原理,最好了解它的演化历史。《深入理解Android 卷I》第8章已经把2.2的Surface系统从上到下都撸过一遍了。那帮整天吵嚷着因为大片里边有马赛克而不爽的屌丝们,你们是否把书里因为不懂而产生的”马赛克“搞清楚了??
一 Surface工作流程
先说一下Surface的工作流程(只在Native层):
上面这个流程,在JB中,是没有变化的。从2.2一直到4.1,都是这个流程。
这块流程变化基本没有,大家可以直接杀进去看看。
二 SurfaceFlinger变化说明
3.1 SF成员变化说明
SF变化很大,主要是它的兄弟们变化较大。我们分别来说,先看图1。
图1 DisplayHardware和兄弟们
图1的简单说明如下:
JB为了支持VSYNC,修改了DisplayHardware和HardwareComposer(这个鬼类,其实是3.0出现的,)。简单来说,VSYNC就是一个同步事件。同步嘛,都是到这个点了,大家把状态对一下。就好像美国大片那些特工们,干某些事情前总要晃晃手表,对下时间一样。至于拿到这个同步事件后到底去干什么,以后看代码就知道了。
VSYNC原则上显示芯片(以后简称显卡)提供的。但JB走得太快了,很多硬件或者没支持,或者接口上没支持。所以,不能保证每台JB手机都有来自硬件的VSYNC事件。咋整?终于,JB干出了一个VSyncThread,它是一个线程,用来定时回调以模拟硬件VSYNC事件(这个时间必须比较准确,所以线程优先级必须比较高)。看,这又是一个铁证,说明JB不适合在单核CPU上跑(我觉得双核也可能不太适合)。
为了支持硬件VSYNC事件,HardwareComposer也增加了相应接口。
DisplayHardware同时从DisplayHardwareBase和HardwareComposer的内部类EventHandler派生。从EventHandler派生无非是想基础它的onVsyncReceived函数。这个函数将在到VSYNC事件时被调用。
由于层层的封装(就和国内工程层层转包一样),DisplayHardware内部又定义了一个VsyncHandler虚类,希望人家去继承它的onVsyncReceived函数。由于使用DH的是SF,所以,大家可大胆猜测这个onVsyncReceived会由SF这一层去处理了。如果去看代码的话,屌丝们会发现DisplayHardware实现的onVsyncReceived函数其实没干什么有毛意义的事情,就是去调用某个实现了VsyncHandler对象的onVsyncReceived函数。(有点绕口令吧?再仔细看看!)
再来看图2:
图2 SF和它的兄弟们
图2解释如下:
先看左上部分。对,你没看错。这里也有MessageHandler,Looper,MessageBase。这以前仅是Java层的东西(所以说,原理是相通的,语言只是工具,如果你懂Java层Message相关的知识,这里又有神马理由说不懂呢?除非你没真正理解Java层Message的东西,参考这篇文章 )。注意其中的MessageBase,它是一个虚类,一方面它实现了父类的handleMessage函数,另一方面需要子类实现handle函数。这一点和Java层的Message不一样。所以,当你在SF中发现有地方往MessageQueue抛消息的时候,就不要去找Handler了,先直接看看这个消息的handle函数!
SF保存了一个MessageQueue对象,作为显示的服务端,它也采取了消息队列的方式来驱动自己工作。这种方式在4.0中已经这么做了,但还不够完全,不够彻底。JB中,SF的threadLoop函数就一句话:waitForEvent()。对于这种改变,我只能说:很好,很强大!
SF保存了一个EventThread对象,这又是一个线程类,它从VsyncHandler派生,实现了onVsyncReceived函数。
SF新增IDisplayEventConnection跨binder接口,数据通道是BitTube(MD,Tube的意思就是pipe。无语了。开发SF的人一定和开发AF的人坐得很远很远..)。这个类的作用就是收集底层的VSYNC事件,然后派发给各个Connection。大胆猜测下,是不是有些APP所需要的FPS不同,所以需要先由DisplayHardware提供一个最小单位的VSYNC时间,然后再由EventThread根据应用申请的VSYNC时间去触发。类似时钟分频嘛!
大胆猜测,小心求证。恩,希望你们掌握这个方法。