Android画⾯显⽰流程分析（2）
努⽐亚技术团队原创内容，转载请务必注明出处。
Android画⾯显⽰流程分析(1)
Android画⾯显⽰流程分析(2)
Android画⾯显⽰流程分析(3)
Android画⾯显⽰流程分析(4)
Android画⾯显⽰流程分析(5)
3. DRM
DRM，英⽂全称 Direct Rendering Manager, 即 直接渲染管理器。
DRM是linux内核的⼀个⼦系统，它提供⼀组API，⽤户空间程序可以通过它发送画⾯数据到GPU或者专⽤图形处理硬件（如⾼通的MDP），也可以使⽤它执⾏诸如配置分辨率，刷新率之类的设置操作。原本是设计提供给PC使⽤来⽀持复杂的图形设备，后来也⽤于嵌⼊式系统上。⽬前在⾼通平台⼿机Android
系统上的显⽰系统也是使⽤的这组API来完成画⾯的渲染更新。
在DRM之前Linux内核已经有⼀个叫FBDEV的API，⽤于管理图形适配器的帧缓存区，但不能⽤于满⾜基于3D加速的现代基于GPU的视频硬件的需求，FBDEV社区维护者也较少; 且⽆法提供overlay hw cursor这样的features; 开发者们本⾝就⿎励以后迁移到DRM上。
3.1. 基本组件
DRM主要由如下部分组成：
KMS(Kernel Mode Setting): 主要是配置信息管理，如改变分辨率，刷新率，位深等
DRI(Direct Rendering Infrastructure):　可以通过它直接访问⼀些硬件接⼝
GEM(Graphics Execution Manager): 主要负责内存管理，CPU， GPU对内存的访问控制由它来完成。
DRM Driver in kernel side: 访问硬件
在⾼通平台上其中部分模块所处位置见下图：
image-20210915104207418.png
其中KMS由frame buffer， CRTC, Encoder, Connector等组件组成
CRTC
⽽HWC Service正是那个使⽤libdrm和kernel打交道的⼈ ，它负责把SurfaceFlinger交来的图层做合成，将合成后的画画提交给DRM去显⽰。
制作android软件流程4.1. App到SurfaceFlinger
应⽤⾸先通过Surface的接⼝向SurfaceFlinger申请⼀块buffer, 需要留意的是Surface刚创建时是不会有buffer被alloc出来的，只有应⽤第⼀次要绘制画⾯时dequeueBuffer会让SurfaceFlinger去alloc buffer, 在应⽤侧会通过importBuffer把这块内存映射到应⽤的进程空间来，这个过程可以在systrace上观察到：
image-20210916102456850.png
之后App通过dequeueBuffer拿到画布， 通过queueBuffer来提交绘制好的数据， 这个过程可以在如下systrace上观察到：
image-20210915204636105.png
HWC Service负责将SurfaceFlinger送来的图层做合成，形成最终的画⾯，然后通过drm的接⼝更新到屏幕上去（注意：在DRM⼀章中给出的使⽤DRM的例⼦⼦demo的是通过page flip⽅式提交数据的，但hwc service使⽤的是另⼀api atomic commit的⽅式提交数据的，drm本⾝并不只有⼀种⽅式提交画⾯）
4.2. SurfaceFlinger到HWC Service
HWC Service的代码位置在 hardware/qcom/display, HWC Service使⽤libdrm提交帧数据的地⽅我们可以在systrace上观察到：
image-20210915202625562.png

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。