| 背景： 可以为AndroidOS、SyberOS基于微内核的双系统方案提供参考。 知识： 1. AndroidOS下GUI系统的必备模块SurfaceFlinger(AndroidO)： SurfaceFlinger属于系统的底层支撑服务； Android的多app同时运行必然存在应用的前后台快速切换、半透明特效等需求， 因此每个app都是有自己的显示缓存的；
扫描二维码关注公众号，回复：
8595770 查看本文章
基于多app共存结构， SurfaceFlinger与BufferQueue(缓存管理，含申请)、VSync(显示时序信号)协作， 合成用户最终所见的图像(基于多App显示缓存的切换、混合) 也因此SurfaceFlinger及其队友实现了GUI系统上层的平台无关性。 差不多可以说，SurfaceFlinger之上归Android管，SurfaceFlinger之下归linux管。 2. SurfaceFlinger所需支撑(AndroidO)： 2.1 OpenGL ES 这是一个概念，是一个绘图标准，具体实现是库。 当它实例化成为一个.so，就属于HAL层的东西。 这是SurfaceFlinger的图像生成、混合的基础，这个库可能是由GPU厂商(如Mali)实现(一般就可以使用GPU计算)，也可采用软实现(纯CPU计算)。(当然，其他程序也可能会直接调用) 2.2 EGL 为OpenGL ES创建环境，如绘图区域像素大小、格式等等(对绘图不懂)。 2.3 Gralloc 属于硬件厂商的HAL层内容，负责图形缓冲区的分配/释放，属于对OpenGL ES的支持。同样可以硬实现、软实现。 2.4 HAL 我猜想，OpenGL ES的硬实现会是同GPU架构统一 (如Mali家的GPU可能共享一个.so的代码，Adreno家的GPU共享同一个.so， Gralloc的硬实现会是每个硬件厂商都不同(如华为的，高通的)。 3. 内核中的设备节点： 3.1 Ion 对于上述HAL层.so的硬实现， 谷歌通过添加Ion设备(DTS)来实现HAL层对内核内存的使用。 Soc中GPU与CPU共享物理内存，GPU对内存的获取方式为ion。 3.2 fb0 fb0本就是linux的FrameBuffer，最终通往呈现给用户的帧内容在此 3.3 mali/adreno/**0 硬件厂商GPU操作的设备节点，属于HAL层， 从外部看到Gralloc对内存alloc/free均经过此设备节点， 是GPU加速缓存(显存？？) (因为我认为上层调用OpenGL ES中间量、结果都应该是放到Gralloc分配的内存)， 4.Android绘制界面 (Ps：仅为绘制实例，可有多种绘制路线) 4.1 app绘制 4.2 BufferQueue贡献内存 4.2.1 BufferQueue从Gralloc取内存 4.2.1.1 Gralloc(软实现为malloc，硬实现经Ion取内存)获得显存 4.2.2 BufferQueue管理内存 4.3 OpenGL ES渲染细节(软/硬) 4.4 结果放入app所申请GRALLOC_USAGE_HW_FB属性的显存 4.5 SurfaceFlinger结合用户操作混成显示页面至FrameBuffer(fb0) 失败： 1.XL启动DomainU时，生成设备树。 2.无Ion节点。 3.无fb0节点。 4.无GPU*0节点。 分析： 1.在x86中，由qemu完成设备的虚拟。 2.在Debain实现了DomainU中画面显示，但这是通过Xfce4+VNC，并未操作相关设备节点； 即，DomainU中的Debain在用户态用软件画出了图形界面，然后通过VNC由IP层送出， 与Android的显示实现方式有本质不同。 3.Ion节点的缺失可以通过分析XL代码，添加相应设备实现，工作量未知。 4.fb0节点的缺失，其实也可以通过代码模拟(qemu就能模拟，但arm中无法使用) 5.mali0设备节点缺失通过使用gralloc.default.so库可软件模拟 结论： DomainU中启动Android的GUI存在基础模块缺失，不能启动；必须通过编码解决，工程量需要深入评估。 写于2018.6月 |
