本文深入探讨了Android显示系统的架构，重点介绍了Surfaceflinger的角色和功能，包括它如何合成2D、3D surface，以及如何通过OpenGL与硬件交互。此外，文章还详细阐述了JNI与Surfaceflinger之间的通信机制，以及Surfaceflinger与libui、OpenGL和显示设备的连接过程。
一、Overview
上图的原型取自高通的文档，由于原图无法描述现有的架构，我在原图的基础了做了些修改，主要是增加了 overlay 部分，另外其他部分根据现有的软件也做了些许改动。下面先对上图做个大概的介绍，后面会针对重点部分做详细的分析。
最上面一层为应用程序，根据数据类型以及应用的不同可以分为几种。
第一种是最普通的应用，如 UI 界面的显示，这部分通常数据类型为 RGB 格式，数据无须再经过特殊的处理。该应用可以说遍布各个应用程序，几乎是实时存在的。
第二种是针对大块 YUV 数据的应用，如 camera 的 preview 、视频的播放等。该应用只针对特定的应用程序，开启时通过 overlay 直接把大块的 YUV 数据送到 kernel 显示。
第三种其实和第一种类似，只不过由于应用的需求在显示之前需要对数据进行 2D 、 3D 的处理（使用 OpenGL 、 OpenVG 、 SVG 、 SKIA ），处理之后的流程和普通的显示就没什么差别了。一般在 Game 、地图、 Flash 等应用中会用到。
应用之下是 framework ，其中最核心的就是 surfaceflinger 了，它为所有的应用程序的显示提供服务。由于 overlay 的接口挂在 surfaceflinger 里面（虽然 2 者在功能上不相干），所有使用 overlay 的 AP 需要通过 surfaceflinger 才可以访问 overlay ；另外，由于 surfaceflinger 需要使用 OpenGL 来 compose surface ，这也就是为什么 surfacelfinger 会调用 EGL wrapper 了， EGL wrapper 是对 Graphics HAL 的封装，除了 surfaceflinger 会调用它来 compose surface 外，上层的 2D 、 3D 应用也会调用它来进行图形处理。
再下一层就是 HAL 了。
首先一个是 overlay 模块，对上提供 control channel 和 data channel ；对下则通过系统调用到 kernel 中的 MDP driver 。
再一个是 Gralloc 模块，注意它是和 overlay 并列的，它包含 2 个部分，一部分是为上层提供 pmem 的接口，另一部分则是对 framebuffer 进行刷新，这里的 framebuffer 其实就是 UI 的数据。由此可见上层有 2 个通道把显示数据送到 kernel 中， framebuffe
最低0.47元/天 解锁文章
扫一扫
1913
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
