聊聊 Android 的 GUI 系统( 四 ) _Android

当一个新的 Activity 被启动时候（startActivity），它首先需要在 AMS 中注册——此时 AMS 会生成一个 ActivityRecord 来记录这个 Activity ；另外，Activity 还承载着 UI 显示的功能，所以 WMS 也会对它进行记录——以 WindowState 来表示。WMS 除了利用 WindowState 来保存一个窗口相关的信息外，还使用 AppWindowToken 来对应 AMS 中的一个 ActivityRecord，从而将三者形成非常紧密的联系。

我是SurfaceSurface 对应了一块屏幕缓冲区，每个 window 对应一个Surface，任何 View 都是画在 Surface 上的，传统的 view 共享一块屏幕缓冲区。
我有一个庞大的家族体系，站在台前的 Android 为我们封装的处于 java 层面的 Surface，我们家族的幕后长老们同时也在 native 层默默贡献者他们的力量。在 Surface.java中 Android 是这样定义我的 Handle onto a raw buffer that is being managed by the screen compositor. 由此可以看出，首先我是一个 raw buffer(屏幕缓冲区)的句柄，可以通过我来管理一个 raw buffer ；其次，我本身又被一个叫 screen compositor 的家伙在管理。同时，我内部持有 IGraphicBufferProducer,而这个 IGraphicBufferProducer 则是 BufferQueue 的实现接口，如此我便又和 BufferQueue 搞上了。
前面说到，WMS 想要将内容展示出来，需要我的支持，具体的，以 addView 来说，我是在 ViewRoot 进行 performTraversals 时，向 WMS 申请一个 Surface 时诞生的。WMS 在创建 Surface 时，会生成一个 SurfaceSession ，然后将这个 SurfaceSession 作为参数来构造 Surface 。这个 SurfaceSession 就是 screen compositor 的一个会话链接。同时，在 java 层面上的 Surface 和 SurfaceSession 构造的时候，都会调用具体的 init 方法，唤醒我们在 native 层的长老们，他们主要聚集 framework/native/libs/gui 这个”山洞“中。
下面罗列的是其中涉及到的一些比较重要的成员和职责：

ISurfaceComposer：通过这个接口可以访问到 SurfaceFlinger，可以通过它建立一个会话，即ISurfaceComposerClient，也可以通过它去更新 Surface 的相关信息，这个是通过setTransactionState接口完成的，代表一个到 SurfaceFinger 的会话连接
SurfaceComposerClient：是 SurfaceFlinger 派出的“代表”，不论是 OpenGL ES 还是 Surface，都可以在这个类的协助下有序地申请和访问各 Buffer 缓冲区。持有 ISurfaceComposerClient 的客户端代理，在SurfaceComposerClient 初次实例化时，通过 ISurfaceComposer 的createConnection()接口得到一个ISurfaceComposerClient 的代理。同时，它也会管理 Surface 的状态，通过 ISurfaceComposer 更新Surface 状态
SurfaceControl：从字面上看，其作用是控制 Surface 。其实际作用是持有 ISurface 的代理及SurfaceComposerClient
ISurfaceTexture：对应具体的 buffer 管理
ANativeWindow：持有 ISurfaceTexture 的本地代理，通过它可以访问到 ISurfaceTexture 的实现。同时它继承了 ANativeWindow，而 Surface 类会继承 SurfaceTextureClient. ANativeWindow 代表的本地窗口
GraphicBuffer：GraphicBuffer 是一个 ANativeWindowBuffer，每一个GraphicBuffer 内部都包含有一块用来保存UI数据的缓冲区，它实际存储空间其实是在 ashmem 上的，具体是gralloc模块来完成分配的，然后映射到应用程序的进程地址空间

有了 Surface ，便可以得到一块屏幕缓冲区，但是这时我们的视图还是不能呈现在观众眼前的。于是便要将 Surface 添加到 BufferQueue 中，从而让 SufaceFlinger 来消费。
我是BufferQueue我是一名勤勤恳恳的老师，我对每个应用程序都进行“一对一在线辅导”，指导着 UI 程序的 “申请画板”、“作画流程”等一系列的繁琐细节。我与各应用程序是通过 IGraphicBufferProducer 建立关系的。
BufferQueue 是 Android 显示系统的核心，它的设计哲学是生产者-消费者模型，只要往 BufferQueue 中填充数据，则认为是生产者，只要从 BufferQueue中获取数据，则认为是消费者。有时候同一个类，在不同的场景下既可能是生产者也有可能是消费者。如 SurfaceFlinger，在合成并显示 UI 内容时，UI 元素作为生产者生产内容，SurfaceFlinger 作为消费者消费这些内容。而在截屏时，SurfaceFlinger 又作为生产者将当前合成显示的UI内容填充到另一个 BufferQueue，截屏应用此时作为消费者从 BufferQueue 中获取数据并生产截图。
站在应用程序的角度来说，应用程序可以调用 createSurface 来建立多个 Layer，每一个 Layer 都对应一个 BufferQueue，换句话说，应用程序与 BufferQueue 也是一对多的关系。为应用程序申请的 Layer，一方面需要告知 SurfaceFlinger，另一方面也要记录到各 Client 内部中。另外，Layer 也没有直接持有 BufferQueue 对象，而是通过 Layer 内部的 mSurfaceFlingerConsumer 来管理的。