硬核万字长文：我是如何把Skia的体积“缩小”到1/8的？( 二 )

这么复杂的项目我打算从以下几个方向来依次阐述它的核心技术：

GPU硬件加速能力的抽象
硬件加速之所以快，在于运算单元多，并行能力强。同样也带来一些限制，参与运算的数据必须符合并行计算的要求。下图描述了大致的流程。

渲染抽象层的设计
目前消费电子设备基本都配备了硬件显卡，但是很不凑巧主流设备中的显卡驱动存在较大的差异。因此想要构建完善的硬件加速渲染器，对不同厂商的GPU驱动做一层抽象是非常有必要。

这里叫RAL（RenderAdapterLayer）这只是一个名称。在游戏引擎行业中大家更习惯于叫它RHI（RHI一般还涉及线程和异步的相关策略），详细可以参考Unreal的设计。
那么RAL到底涉及哪些东西？这就要说到显卡的差异了，就目前来说主流的图形技术在所有显卡中都是相通的。显卡核心组成部件都类似（高级显卡存在一些新的着色器流程，暂时我们不会用到）。只是驱动在所在的平台存在差异，也就是显卡功能性的描述接口存在差异。这部分差异主要存在于2个方面（当然还存在一些细微细节不一样，比如窗口坐标系和NDC的差异，纹理采样坐标系的差异）。

其中API的差异可以通过对驱动接口的包装来抹平（有点繁琐），编程语言就相对来说非常麻烦了。 Skia内部内置了自己的一套显卡编程语言叫SKSL ，可惜文档比较少。为了达到缩减包体积的效果，设计了一套自己的编程语言。我管它叫RSL 。
设计一套新的Shader编程语言
为什么要设计一套新的编程语言和语法？为什么不直接使用glsl的语法？
这里有2方面的思考（主要为了方便我实现编译器或者叫转化器）：
在这之前我尝试让OpenglES运行在iOS的Metal之上（小游戏引擎的内核项目），手写过glsl的编译器。用来转化到Metal的MSL语法之上。由于glsl的Spec文档有点多而且复杂，为了测试编译器的稳定性，抓取了ShaderToy（一个交流webglshader的网站）1w5千个左右的shader进行测试。语法分析通过率只有95%多点，总有一些我没有考虑到语法。所以说还是不太稳定，工作量有点大。
glsl规范比较老，缺乏语义的支持。
应该还有其他的理由，比如我自己设计的语法。但凡有不太容易实现的部分，我可以选择剔除掉。

为了缩小包体积，我尝试把Shader的编译拆分成离线和在线两个端。和大多编译器的项目类似，或许他们都管这叫编译前端和后端。
离线端：编译源码，抽取语义得到AST（抽象语法树），由于这部分离线运行，可以任意选择开源项目配合实现，不用在乎包体积。现在开源的编译器项目很多，比如Flex和Bison很容易就可以构建出离线端。理论上应该对AST进行优化操作，奈何我本人对优化算法知之甚少。所以目前还没有实现任何优化相关的部分。最后对AST进行序列化，也可以稍微做点处理，一切以方便设备端翻译工作为目的，然后就可以内嵌或者动态下发到目标端上面了。
在线端：一般指的就是设备端，接收到AST的序列化文件后就可以重构AST数据结构，并进行翻译。目前主要搞定了OpenglES和Metal两个主力平台， Vulkan正在进行中。