openGL in iOS（一）：基本概念和发展历史

kirin77 · 发表于 2022-4-20 08:07

1. khronos 简介

image.png

khronos 是由 170 家企业组成的开源、非盈利的成员驱动型组织，主要负责开发、发布和维护免税版权标准，其范围涉及到 3D图像学、虚拟现实、增强现实、并行计算、视觉加速和机器学习。该组织制定的标准及其相关的适应性测试提高了软件和中间软件的创作，而且加速了动态多媒体的在跨平台设备上的回放。

khronos 是 OpenGL ES 标准的制定者、维护者，有什么疑问直接去官方找资料即可：

https://www.khronos.org/registry/OpenGL/specs
2. OpenGL 和 OpenGL ES

OpenGL ES 是 OpenGL 的子集，专门为嵌入式设备而设计，如手机端，另外 Play Station 也有使用；

嵌入式设备的因为诸多限制，比如能耗，所以 GPU 和 CPU 性能一般不如 PC 端，所以 OpenGL ES 的设计相对 OpenGL 就很精简、高效，比较典型的区别如下：

glDrawArrays等函数中数据必须紧密排列，即间隔为 0；
7.各种数据的堆栈深度较低；

3. iOS 中 OpenGL ES 的版本

在学习时，一般参考 OpenGL 的官方教程：

https://learnopengl-cn.github.io/

但是需要注意的是，OpenGL 和 OpenGL ES 还是有很大的不同，比如 #version 的声明，所以一些图形学的概念可以参考 openGL 中的教程，但是涉及到具体的 Api 差异或者版本问题，最好直接看 OpenGL ES 的官方文档；

这里是 openGL 和 openGL ES 相关文档的归档：
https://www.khronos.org/registry/OpenGL/specs/es/

image.png

3. version

按照 LearnOpenGL 中的示例代码，编译着色器时如果使用到了#version 330 core，跑在 iOS 设备上，必定是会报错的，报错信息大概如下：
ERROR: 0:1: '' : version '330' is not supportedERROR: 0:1: '' : syntax error: #version
那为什么会报错呢？原因是因为 OpenGL ES 中的 GLSL 最高版本为 320，且使用 GLSL ES 时，需要这样：
#version number es
而 OpenGL 中，3.3 版本发生了重大更新，所以一般使用 OpenGL 3.3 版本，对应的 GLSL 为 330，具体可以上官网查询。而 OpenGL 中版本声明一般这么写：
#version number core
关键就在于版本号和 es 、core 的区别；

来看看官方文档中的描述吧~~~

这里是 3.1.0 的版本：GLSL_ES_3.1.0

最新版本为 3.2.0，iOS 中支持的 GLSL ES 最高版本为 3.0.0，但是 version 部分基本没什么变化，所以直接那 3.1.0 中的文档来看了；

关于 #version 的描述如下：

image.png

比较重要的几个结论：

再来看看 iOS 中的 OpenGL ES，iOS 支持 openGL ES 3.0，相关文档如下：

image.png

这里其实有待商榷，Apple 官方文档中没有找到 OpenGL ES 的具体版本，只知道是 OpenGL ES 3.0 以上的。可以做下测试，如果着色器代码中声明 #version 320 es 被支持，也就是最新版本的 GLSL ES，是不是可以理解为：iOS 的 OpenGL ES 虽然被遗弃了，但是仍然是最新的？

测试 #version 320 es 和 #version 310 es结果如下：

image.png

测试 #version 330 es，结果如下：

image.png

也就是说，iOS 中的 GLSL ES 版本为 3.0.0。所以，iOS 对应的 OpenGL ES 也为 3.0.0，并不是 2019 年修订的 3.2 版本。
4. Apple 抛弃 OpenGL

iOS 从 iphone7 + iOS12 开始就已经抛弃了 OpenGL ES，开始主推自研的 Metal：

image.png

这里有个疑问：

已经有现成的 openGL ES 了，得罪开发者，而且自己也需要额外的工作量来开发新的 Metal 框架，同时还需要底层 GPU 支持自己的 Metal 框架，这么吃力不讨好的事情， Apple 为什么这么做？

其实这里可以拆解成几个问题：

首先第一个问题，查阅资料之后可以确定，openGL ES 已经无法满足 Apple 了。因为：

所以，对于第一个问题可以做出解答：

OpenGL/OpenGL ES 已经有点更不上现在 GPU 的发展，在性能和、更新周期、Api 设计上皆无法满足 Apple 的需求了，所以 Metal 势在必行；

第二个问题，Apple 是否对开发者不友好？这个要从几点来说明：

第三个问题，其实已经不用回答了，从 M1 芯片的推出，Apple 几乎已经大通了硬件+软件的全链路，自成一派了，自身的发展完全由自己掌握，包括后续的电车、增强现实、虚拟现实、机器学习、Aiot 框架等等，都可以由自己来支持。
5. 图形学框架常见名词和分层

常见的名词有：

这里以 Flutter 的图形架构图来展开：

image.png

从上图可以看出，基本上可以这样分层：

该层是面向 GPU 的图形 Api，也就是我们上文说到的 Vulken 、DirectX 、Metal、 OpenGL/OpenGL ES。OpenGL 已经被抛弃，所以主流的图形 Api 也就剩下三个了。

从上文可以看到，Flutter 使用 OpenGL ES 对低端机器进行支持，使用 Metal 支持 iOS 平台，使用 Vulken 支持 Android 平台。因为 DirectX 主要用于 PC 端，自然不在其框架内。

为什么需要中间层？

封装的主要原因是满足不同级别的抽象。面向 GPU 的图形学 Api 不可能直接提供给所有的开发者，所以系统需要为开发者提供 UI 框架。但是在开发这个框架时，也不太可能直接使用图形 Api，因为这样会有大量重复工作。

另外，有很多业务是不需要所有的上层开发者知道的，学习成本越低，那么框架的普及就越高效，所以就需要封装很多流程，比如渲染机制的封装。

所以中间层诞生了，这个主要供系统开发人员使用，同时也会部分提供给业务开发者；

如上图，Core Animation 主要是封装了渲染管线、CPU 和 GPU 的交互。苹果的员工在开发 UIKit 时，不需要自己去生成和计算顶点数据、着色器代码，也不需要去调用很多 openGLES/Metal 的接口就可以完成渲染操作。

skia 作为 Flutter 的核心渲染框架，也是同理。因为 Flutter 是跨平台的，所以 Skia 内部相对于 Core Animation，必定会多出很多跨平台判断、兼容的代码；

这一层就是系统 UI 框架的最上层，面向普通的开发者。比如 iOS 中的 UIKit，MacOS 中的 AppKit，Android 中的 View、Group 等，还有 Flutter 的 Flutter UI；

开发者可以使用该层架构提供的 Api 来快速完成 UI 相关的业务，就算是新手也可以使用几行代码就可以展示一个 Label、Button 或者是列表；

Unity 3D 没有使用过，个人理解，Unity 3D 类似于 UIKit 和 AppKit 框架，或者说是介于 UIKit 和 OpenGL/Metal 中间的一个框架。开发者可以使用 Unity 3D 提供的 Api 做出很多酷炫的动画和图形，从而简化游戏开发或者是重度绘制 App 的开发流程。

image.png

个人更偏向于把 Unity3D 放在和 Core Animation/Skia 平级，也就是直接操作图形 Api。Unity3D 作为跨平台游戏引擎，自然也是完成了对 OpenGL、Metal、Vulken 的封装。

上文中写道，不可能面向所有的开发者提供图形 Api，关键在于这个所有人的区分。工具人还是工程师，取决于你对原理了解的多少，对本质触及的多少，这些才最终决定了你是哪一类人。

6. Tips

image.png

总结：

7. iOS 和 OpenGL ES

几个结论：

比如如果 App 中有图形 Api 的需求，就应该基于 OpenGL ES 进行封装，产生一套自有的中间框架，而且 Api 应当尽量屏蔽硬件层的逻辑。如果这样做了，除非 Metal 不支持，后续更换 Metal，只需要将 OpenGL ES 的调用替换成 Metal 即可，相对而言会轻松一些；

		自动登录	找回密码
密码			立即注册

openGL in iOS（一）：基本概念和发展历史

本帖子中包含更多资源