背景

发现有一个问题，那就发现在user版本的手机设备上发现无法抓取相关的winscope，哪怕可以抓取也发现没办法导出来分析。

binder讨论的一些场景面试题

问题1：binder中有多个进程作为客户端通过servicemanager获取service的bpbinder，bpbinder都会有一个handle，那么多个进程获取同一个service对应的handle一样么？

是的，多个进程获取同一个服务对应的 BpBinder 的 handle 是一样的。

从Android 12开始，Android的绘制系统有结构性变化， 在绘制的生产消费者模式中，新增BLASTBufferQueue，客户端进程自行进行queue的生产和消费，随后通过Transation提交到SurfaceFlinger，如此可以使得各进程将缓存提交到SufrfaceFlinger后合并到同一事务后同步提交，在同一帧生效。实际上，从Android12到Android14整个绘制系统在各个环节也都有了或大或小的调整，比如Android13发布了1.3版本的Vulkan, Android14新增了TextureView，等等。本文基于Android14。1

一、SurfaceFlinger介绍

SurfaceFlinger是Android系统中的一个重要组件，它主要负责窗口管理与界面显示。具体来说，SurfaceFlinger作为系统的显示引擎，负责接收各应用程序发来的图像数据，并组合成一张完整的画面，并输出到显示屏上。SurfaceFlinger通过重绘整个屏幕或部分屏幕来更新UI界面。它还提供了多种硬件加速技术，如OpenGL ES、Vulkan等，使应用程序能够更快地渲染UI界面。

GraphicBuffer用于管理图形缓存数据的类，GraphicBuffer的构造方法如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

//frameworks/native/libs/ui/GraphicBuffer.cpp
class GraphicBuffer
    : public ANativeObjectBase<ANativeWindowBuffer, GraphicBuffer, RefBase>,
      public Flattenable<GraphicBuffer>{
	GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight, PixelFormat inFormat,
	                             uint32_t inLayerCount, uint64_t inUsage, std::string requestorName)
	      : GraphicBuffer() {
	    mInitCheck = initWithSize(inWidth, inHeight, inFormat, inLayerCount, inUsage,
	                              std::move(requestorName));
	}
}

GraphicBuffer 的构造函数非常简单, 它只是调用了一个初始化函数 initWithSize：

Surface的connect方法用于建立与BufferQueueCoreAndroid13 BufferQueueLayer onFirstRef流程分析-CSDN博客#new BufferQueueCore连接，代码如下：

SurfaceControl是Android系统中的一个类，用于管理和控制Surface的创建、显示和销毁，SurfaceControl的创建过程如下：

在Android13版本中，SurfaceFlinger是由Android.bp去启动init.rc文件，然后再解析文件去加载SurfaceFlinger。