前言经过前面系列文章的学习，我们的已经理解了SurfaceFlinger运行机制以及同步机制，但是SurfaceFlinger又是以什么方法是把需要刷新的信号发送给App进程的，本文将会和探讨这个问题。 如果遇到问题可以来本文进行讨论：ht

前言在前文中，我们已经讨论了Android 渲染体系中整体流程。但是对于fence，每一个厂商对它的理解都有点点不同，但是大体的思路和框架是跟着Android渲染体系走的。就以上一篇的msm8960为例子，在hwc_set中执行了hwc_s

前言整个图元的合成，大致上分为如下6个步骤： 1.preComposition 预处理合成 2.rebuildLayerStacks 重新构建Layer栈 3.setUpHWComposer HWC的渲染或者准备 4.doDebugFla

前言经过上一篇文章的探索，我们已经熟知了图元是如何消费的。当一旦有图元进行过消费，SF就会决定刷新整个屏幕，大致上分为如下6个步骤： 1.preComposition 预处理合成 2.rebuildLayerStacks 重新构建Laye

前言经过前两篇文章的解析，我们彻底的理解GraphicBuffer的生产端究竟做了什么。本文就来讨论GraphicBuffer是怎么消费。 整个图元的消费到合成，最后到通过hwc发送到fb。由于整个流程十分长，中间有许多细节，我将会挑出核心