IT先森

Android下HWC以及drm_hwcomposer普法(下)引言不容易啊，写到这里。经过前面的普法(上)，我相信童鞋们对HWC和drm_hwcomposer已经有了一定的认知了。谷歌出品，必须精品。我们前面的篇章见分析到啥来了，对了分析到了HwcDisplay::init，然后设置Backend后端来着！

当VSync信号到来时，SurfaceFlinger被唤醒，处理Layer的新建，销毁和更新，并且为相应Layer设置期望的合成方式。所有Layer更新后，SurfaceFlinger调用validateDisplay，让HWC决定每个Layer的合成方式。

在VSyncDispatchTimerQueueEntry的callback方法中，会调用类型为CallbackRepeater::callbackk，然后在该方法中接着调用mCallback(vsyncTime, wakeupTime, readyTime)方法，而这里的mCallback(指向DispSyncSource::onVsyncCallback，最后回调EventThread的onVSyncEvent方法。由于偏移量不同VSync-sf信号和VSync-app信号的回调时机也不同。

Android Graphics图形栈SurfaceFlinger之间各种Layer以及对应Buffer之间的关系。Android Graphics图形栈SurfaceFlinger之间各种Layer以及对应Buffer之间的关系。

SurfaceFlinger::setTransactionState中比较复杂容易忽略将TransactionState state放入mTransactionQueue的过程，mTransactionQueue在后面创建hwc layer的时候会用到。mClient->createSurface会调用到android12\frameworks\native\services\surfaceflinger\Client.cpp 中Client::createSurface。app端创建Surface。

因为要预研Android Video overlay，需要将SurfaceView对应的GraphicBuffer从drm_hwcomposer中剥离出来，这就需要们了解SurfaceView对应的GraphicBuffer的前世今生，以及它的数据流向以及在各个模块之间的对应关系。这里我们对该函数单独站看来分析下，ensureOutputLayer将创建Output layer，不是所有layer都会创建对应的hwc layer，创建出来的这些layer最后是要显示到屏幕上的。我先分析下，再告诉你！

这个我的理解它主要是Layer的一个前端,主要用来处理Layer合成相关的,!表示一个"前端"Layer，跟Layer相对应，用于处理Layer在合成阶段的工作。机会是每年一个版本，前进的胶布不能停啊，继续干。Display: 表示所有输出层最终对应的显示设备，可以有硬件合成器支持的显示设备，也可以对应虚拟显示设备。这里的Layer.State主要存储了该Layer相关的数据，例如长宽，各种矩阵，阴影等。这里需要注意CompositionState对应的域空间，不要和Layer里面的搞混淆了！

在跟进hwc_layer是如何产生的，并如何被填充上GraphicBuffer的，怎么也找不到被填充的GraphicBuffer的来源，最终找到了，它的来源是客户端的BLASTBufferQueue传递过来的，我们这里跟进下这个流程。一. BLASTBufferQueue是如何传递GraphicBuffer到SurfaceFlinger端的BufferStateLayer的。我们接着继续往下看，layer->setBuffer会调用子类的setBuffer，子类是BufferStateLayer。

因为前端就是gralloc hal的接口定义，都是一致的，然后后端backend抽象出来，然后根据实际的情况，调用具体的gpu用户层接口实现！这里我们可以看到这里抽象出来了几种典型的GPU的backend，然后再根据前面获取到的drm的驱动名称进行匹配，匹配到了则返回合适的backend，没有则返回NULL。这里我们以evdi为例子来进行相关的分析。minig的核心主要是提供gralloc的HAL实现，但是我看它也提供了私有的HIDL service实现，关于HIDL的实现这个暂时不在我们考虑的范围之内。

native_handle/native_handle_t只是定义了一个描述buffer的结构体原型,这个原型是和平台无关的,方便buffer在各个进程之间传递,注意成员data是一个大小为0的数组,这意味着data指向紧挨着numInts后面的一个地址.我们可以把native_handle_t看成是一个纯虚的基类.对于native_handle和native_handle_t，以及private_handle_t这三个类型可以看作是同一个东西,而buffer_handle_t则是指向他们的指针.

通过上述的代码我们可以看到在启动之初就搭建好了EGL环境，并将当前线程与context绑定，为后面使用gl命令做好准备，然后创建了ImageManager 线程，这个线程是管理输入Buffer的EGLImage，然后创建了GLFrameBuffer，用来操作输出的buffer。当需要GPU合成时，会通过生产者RenderSurface::dequeueBuffer请求一块图形缓存，然后GPU就合成/绘图，把数据保存到这块图形缓存中，通过RenderSurface::queueBuffer提交这块缓存。

至此，SurfaceFlinger刷新的主体函数分析完了，可以看出来，如果是走device合成，SurfaceFlinger是直接把layer信息提交给hwc，由hwc去合成.prepareFrame 的作用是根据hwc的能力选择合成方式，如果是device合成则直接走hwc present上屏，如果是GPU合成后面则走hwc validate，然后根据hwc过来的变化改变layer的合成方式。composeSurface的主要核心逻辑是针对GPU合成，对于device合成，则直接return了。

handleMessageInvalidate主要作用是执行 latchBuffer 去 acquire 应用queue过来的Buffer，然后拿到queueBuffer时设的Bufferslot一些状态属性给到BufferQueueLayer的mBufferInfo，同时还把这个Buffer做成EGLImage为后面的GPU合成做准备，期间都是数据之间的传递，所以说SurfaceFlinger并未真正触碰Buffer的内容。总之，青山不改绿水长流先到这里了。本篇引用的代码，主要是Android R的。

SurfaceFlinger进程 和 IAllocator服务进程之间通过 hidl_handle 类型的数据传递 图形buffer共享内存的fd数据传输中对 hidl_handle 类型数据特化处理，并把binder数据类型设置为 BINDER_TYPE_FDAbinder内核对 BINDER_TYPE_FDA 类型数据特化处理同时在 IAllocator.allocate 的回调函数中调用 IMapper.importBuffer 把内存映射到当前进程。

GTK+和QT是GUI toolkits，属于软件库，类似c语言的stdio.h，win32，java里import的各种外部包，可以任开发者调用（应该是C/C++使用的库）去创建一些图形界面里面的控件，例如button，下拉菜单，窗口等。而人机交互的本质，是人脑通过人的输出设备（动作、声音等），控制终端的输入设备，终端经过一系列的处理后，经由终端的输出设备将结果输出，人脑再通过人的输入设备接收电脑的输出，最终实现“人脑终端”之间的人机交互。这是一个非常耗时的操作，GPU 的引入就是为了加快栅格化。

      Android dump渲染和合成图层GraphicBuffer指南引言  博客停更很久了，提起笔来渐感生疏啊！看来，还是得抽出时间来更新更新啊！好了，感慨也发完了，是时候切入正题了。本篇博客将主要详细介绍如何dump Android渲染和合成图层GraphicBuffer，并通过YUV软件查看流程！通过本篇博客，读者将会至少学会如下两点:通过dump Android渲染图层GraphicBuffer，查看Android渲染结果是否正确通过dump Android合成图层Graph