Android 4.1 Surface系统变化说明

Android 4.1 Surface系统变化说明

时间真的是很巧，本来没打算写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层）：

• Java层Surface的创建将导致JNI的Surface_init函数的调用。这个Surface还不是APP使用的Surface，中间会经历过乾坤大挪移的过程，请参考上面所提的书籍，写得非常详细。
• Surface_writeToParcel，将Surface传递到APP所在进程去使用。
• APP所在进程通过Surface_readFromParcel，还原一个Surface对象。此时，你的APP就有脸了。
• APP调用Surface_lockCanvas获得一块画布，APP然后在这块画布上作画。
• APP调用Surface_unlockCanvasAndPost，将数据推向SurfaceFlinger，完成此次作画。

上面这个流程，在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时间去触发。类似时钟分频嘛！

大胆猜测，小心求证。恩，希望你们掌握这个方法。

1 2 下一页