BBQ 机制介绍：https://www.jianshu.com/p/50a30fa6952e
BBQ 原理解读：https://www.jianshu.com/p/cdc60627df90
BBQ 运用场景：https://www.jianshu.com/p/384a5cd2e304

一、背景

Android S版本之前，关于应用显示方面面临几个问题：应用程序在缓冲区的提交中灵活性不足，窗口与应用绘制之间无法做到同步，多进程数据无法做到同步。BLAST 旨在解决这两个问题，同时简化 SF 中的模型。

1、Android S 版本之前

• 应用绘制缓冲区仅能通过 BufferQueue IGBP（IGraphicBufferProducer） 提交；
• 应用窗口Geometry的改变仅能通过事务（Transaction）提交；
• 通过合并事务（Transaction.merge()）或延迟事务来更改应用窗口间的Geometry；
• 多进程缓冲区之间无法做到同步。

2、Android S 或更高版本

• 应用绘制缓冲区可以通过事务Transaction.setBuffer()进行提交；
• 应用窗口Geometry的改变可以通过BlastBufferQueue进行提交；
• 应用绘制的缓冲区和应用窗口Geometry可以进行同步；
• 多应用绘制的缓冲区之间可以进行同步。

二、优化场景

1、优化SF进程处理逻辑，将BufferQueue组件架构移到客户端，由客户端自行管理，增强了客户端缓冲区操作的灵活性，利用BlastBufferQueue机制，通过事务提交图形缓冲区：

应用进程提交合成

2、提供了应用绘制与WMS窗口管理之间进行同步的渠道。
之前的Android版本并不具备多进程之间的缓冲区与窗口几何属性之间的同步，Android 12版本上，利用BBQ机制，将应用准备提交合成的缓冲区交给事务，同时可以将事务跨进程传递给系统服务，系统服务会根据需要将任意窗口的几何修改融入到该事务一并提交，保证在同一帧下生效：

应用绘制数据交由WMS进行提交

3、通过System Process控制多个Client Process之间绘制的同步。

系统服务可以是所有进程之间的中介，利用这点，各应用进程之间的图像缓冲区也可以通过BBQ机制来进行同步：

多进程数据同步提交

三、总结
BBQ 机制打通了进程已进程、Buffer 与 Geometry 之间的联系，使得显示各模块之间自由度更高，利用该机制系统服务的很多逻辑也得到了进一步优化。