一、前言：

之前讲述了native层如何使用SurfaceFlinger，我们只是看到了简单的API调用，从本文开始，我们逐步进行SurfaceFlinger内部结构的分析。话不多说，莱茨狗~

二、类图：

2.1、总体架构：

先看下SurfaceFlinger的关键成员和我们BootAnimation侧关键成员如何对应起来，这不是严格的UML类图，但是这么画我觉着很容易理解，就先这么画了。

可以看出：

• SurfaceFlinger侧会为BootAnimation创建一个Client，其实，SF会为每个APP都创建一个Client；
• SurfaceFlinger侧有一个BufferQueueLayer（Layer的子类）对应APP侧的SurfaceControl，允许有一个APP有多个Layer，同时，SF会生成多个SurfaceControl；
• BufferQueueLayer是一个buffer队列，队列有一个消费者mConsumer和一个生产者mProducer；
• APP侧的SurfaceControl当中有一个Surface；
• Surface当中又有一个数组mSlots表示64个buffer，对应SF当中其实也有这么一个数组，如果数组来管理这些buffer，这个是比较复杂的流程，后面单独写一篇文章介绍；

2.2、代理关系：

上面看到好多类似于SurfaceCompser的字眼，到底啥关系呢？我给你画个图：

熟悉Binder机制的朋友都应该能看懂，Bpxxxx一般就是代理类，Bnxxxx一般就是本地类，这样APP侧调用mClient就像调用Client一模一样的，底层Binder帮你处理了。一种RPC的思想。

三、APP连接SurfaceFlinger：

前面画了静态的类图，接下来我们看下APP如何去和SurfaceFlinger建立连接。

1. APP侧获得SurfaceFlinger服务：

   • 在BootAnimation构造函数中，我们会通过mSession = new SurfaceComposerClient();来获取SF的代理类。

     BootAnimation::BootAnimation(sp<Callbacks> callbacks): Thread(false), mClockEnabled(true), mTimeIsAccurate(false),mTimeFormat12Hour(false), mTimeCheckThread(