翻出了4年前实习期间手绘梳理的Android图形框架，其实有些细节都记不清了。 所以这里再文字梳理一边，加深理解也作为一个积淀，接下来希望能梳理清楚Android系统如何进行HDR上屏的。
先笼统来说，我们知道，我们将某个图像在Androids设备上显示涉及下述环节：
1. 我们将要显示的数据交付给Android系统（Canvas、OpenGLES、Vulkan），
2. Android系统将要显示的内容处理成相应的buffer（GUI+芯片），
3. 显示硬件根据buffer数据使显示屏每个像素发出对应的光（LCD、OLED屏幕设备）。
GUI架构处理的就是上述的第二步。
———— ———— ———————————————————————————
推荐相关文章：
从Android的基本View组件解释view hierarchy如何与Android GUI协作：
https://www.zhihu.com/question/25811504
GUI最重要成员Surface、SurfaceFlinger介绍：
Android 卷I-Surface系统，从Android的基本View组件解释view hierarchy如何与Android GUI协作：
https://wiki.jikexueyuan.com/project/deep-android-v1/surface.html
SurfaceFlinger 图形系统：
https://blog.csdn.net/freekiteyu/article/details/79483406
SurfaceFlinger 用于应用程序的典型绘图流程：
https://blog.csdn.net/xuesen_lin/article/details/8954840
SurfaceFlinger如何OpenGLES联动起来：
https://blog.csdn.net/xuesen_lin/article/details/8954553
承载图像信息的Buffer的介绍：
罗神的Android帧缓冲区（Frame Buffer）硬件抽象层（HAL）模块Gralloc的实现原理分析： https://blog.csdn.net/Luoshengyang/article/details/7747932
———— ———— ———————————————————————————
从手绘纸最上面开始说吧，Android 框架提供了各种用于 2D 和 3D 图形渲染的 API，可与制造商的图形驱动程序实现代码交互，
应用开发者可通过三种方式将图像绘制到屏幕上：使用画布、OpenGL ES 或 Vulkan。2D指的没有开启硬件加速的Canvas，但是针对Android 4.0以上的系统，默认开启了硬件加速，所以我们基本上可以理解图像绘制目前市面上Android手机都会用到GPU处理。
不过不管是2D还是3D、Canvas还是gles或是Vulkan，我们都会把绘制数据画到Surface上去。注意这里Surface不等于我们常说SurfaceView。最直接理解，Surface就是作为SurfaceFlinger的代理，SurfaceFlinger作为系统服务，是系统资源，供各个App使用，每个App要去用这个资源就需要代理交接，而这个代理对接什么呢？window，窗口。
Window拥有一个Surface，在Surface里绘制Window里的内容。一个application通过ViewRoot向Windows Manager Service申请创建窗口，WMS也是系统服务负责分配窗口资源，Windows Manager为每一个窗口创建Surface来让application在上面绘制各种物体。我们看到android机上各种图案都是通过一个个win来组织的，win有很多种 比如systemWindow，status bar（电量、wifi、信号那块）、navigation bar（home页，前进，后退）、还有我们开发者最熟悉的Activity对应的win，application window。各种window，z轴叠加，如果布局不好会挡住，这也是为什么各种刘海屏幕、曲面屏幕，手机厂商都有一定的适配工作。
Activity内的各种子view布局就灵活很多，最终布局也会由ViewRoot来管理，管理的结构是一个叫View Hierarchy（视窗继承关系）根据这个关系，View Root把Activity里的各种子View 布局好规划好映射到 Surface里的buffer里去，这样子，当我们一个View内容发生改变的时候，我们不用整个surface里面的buffer更新，只用更新部分区域，这个过程就是下图中的invalidate和draw。
说到这里，可以引出 SurfaceView，它独立于Activity，有自己的线程（当然 生命周期还是需要依附于Activity），有自己独立的window，我们知道window是z轴排列的，所以一般SurfaceView是与Activity是存在“覆盖”关系的，在有的比较低性能的手机上我们切换应用的时候，可以看到activity与surfaceview是分开的，activity的一般会布局上“挖个透明区域”留给SurfaceView显示。由于SurfaceView的独立线程特性，使得它很适合用来做一些相对耗时可能会block的事情，比如视频媒体相关的。
同时媒体展示还有一个常用的控件，叫做TextureView，参考到Google Android Developer：https://developer.android.com/reference/android/view/TextureView，这个控件通过SurfaceTexture可以使用GPU资源，这点跟SurfaceView一样，但是它没有自己独立的window，它跟其他控件一样从属于ViewRoot，对应的是整个Activity的window，在View Hierarchy结构中，也是为什么这个控件可以轻易的“ moved, transformed, animated, etc.”。还有一个东西叫GLSurfaceView，这个是封装好了的SurfaceView，也能够配置HDR色域，而且吧这个控件游戏常用到，也就是说，HDR技术也可以落地到游戏上去。
一个有独立的window，一个从属于ViewRoot的window，所以SurfaceView为什么transform往往需要开发者自行开发，但是ViewRoot早已预设了控件transform的能力，SurfaceTexture沿用就好。
到这里简单描述一下我理解得的 常见的activity、surfaceview如何“承上”（承载App里各种view）了，接下来就是比较难的Android GUI的内容了，我把它概括为启下？把我们期待App的中各个区块的内容填充告诉到Android 系统服务。
启下的起点就从surface开始吧，
上面我们提到了 surface，surface在我看来是两个东西组成，一个是buffer queue，实现一套生产者消费者模式；一个是缓存，buffer queue传送的东西，存储着我们“承上”来的绘制或者素材数据，比如我粗暴地理解成bitmap。
消费者生产者模式，我们的应用、系统应用、各种窗口生产出要上屏的内容，这些内容以surface的形式，交由给SurfaceFlinger进行整合生产出整块屏幕显示内容给Display HAL层去上屏；怎么交由呢？surface中还有一个可以跟SurfaceFlinger系统服务打交道的代理，我们应用的surface当然在我们应用进程，要跟 SurfaceFlinger 打交道需要跨进程，所以不是即时的，我们常常说屏幕的刷新帧率多少，比如120hz屏幕，其实也对应着SurfaceFlinger需要每秒钟整合多少次屏幕内容，或者我们可以理解成每1/120s，SurfaceFlinger就把这段时间，各个进程送来的上屏内容收集，然后一层一层的摞起来，整合成一个整个屏幕的画面数据；SurfaceFlinger与Display HAL之间也有一个 buffer queue， 一个存放当前上屏数据，一个存放着下一个上屏数据，120hz屏幕每1/120s交替一次。
以上就是根据我的理解大致的描述发生在Android系统服务中上屏过程，如若有什么地方说的错误的，望指正；
那么HDR这个能力是怎么在Android的上屏过程中实现的呢？我通过上网查阅资料以及分析Dump下来的SurfaceFlinger的信息，大致脑补出了一个workflow，仅供参考：
首先，我们知道，对于上屏内容处理，SurfaceFlinger处理的单元是Layer，确实每一Layer都有字段标识它是不是HDR以及HDR mode。
所以对于第三方开发，我们需要做的就是把HDR信息配置到window上去，这个信息最终会配置到对应的Layer上。Google Android Developer有介绍一些方法。https://developer.android.com/training/wide-color-gamut
然后我们知道SurfaceFlinger每次要处理很多Layer，一般UI layer的数据是8bit sRGB，而如果有一个layer是 10bit HDR RGB。与此同时平时厂商介绍手机的时候，色域的介绍基本上都是覆盖P3 or DCI-P3色域百分之多少，其实也就是说，即使layer是 10bit HDR，其实就目前的手机屏幕支持的色域能力而言，我们手机也展示不了真实的BT 2020的色域下的表现，是转到了P3色域下的表现。所以在这个屏幕的广色域模式下，任何颜色最终都是映射到P3色域上。
SDR的layer经过一次 Color Gamut转化，将BT709的颜色映射到P3的色域下；而HDR的layer除了需要经历Color Gamut转化，将BT2020的颜色映射到P3的色域下之外还需要color-transfer的转换，比如说PQ模式，由于屏幕硬件设备的Gamma值是固定的，假定是值a，芯片可以通过对PQ模式下Layer的RGB值乘上一个系数，Color-Transfer（PQ）/ a , 最终也实现了对应的Color-Transfer的作用，当然可能因为手机屏幕远达不到HDR标准值的亮度值要求，Color-Transfer（PQ）值可能被优化过,相较之下 iOS的HDR能力反而做的好得多。
接下来谈下HDR跟屏幕之间的关系。
目前常常各大厂商PR稿在介绍屏幕能力的时候会着重强调自己的屏幕是OLED屏幕。其实OLED屏幕之前，主流的手机的屏幕是LCD屏幕。OLED屏幕虽然有很多被人吐槽的点，比如说烧屏、低频PWM调光晃眼睛，但是它的发光特性却非常适合HDR功能。OLED屏幕是屏幕整齐排布的是自行发光体，而LCD屏幕是屏幕排布的只是滤镜元件，亮度通过背光实现，有点像是皮影戏，后面打着大灯控制亮度，前面带有颜色的滤镜片控制颜色，这种背光的模式导致即使屏幕要显示带有黑色的画面，但是黑色区域也不是真正的无光，只是相对的黑，但是OLED屏幕就可以控制黑色区域完全不发光就可以实现“极致的黑”，所以当分母为0，亮度比就可以非常非常大，所以OLED屏幕的亮度比远大于LCD屏幕。而我们知道，HDR技术的目的是让明暗细节都能在同一帧画面中体现出来，OLED的屏幕的特性就与HDR目的非常契合，所以移动端的HDR技术常常和OLED屏幕联系起来。
絮絮叨叨先说到这里了。
