看后 Metal 的开发文档后，除了官方所宣称的一些长处外（比方说更easy理解和使用的
API。更直接和精细的硬件控制，降低 GPU 使用过程中的 CPU 额外开销等等），从我有限的 GLES 开发经验看来，下面一些方面更让人兴奋。

更方便和友好的多线程 GPU 渲染支持

GLES 的设计，全部东西都必须跟一个 GL Context 绑定。由 GL Context 内部所控制的状态机驱使，而 GL Context 又跟单个线程本身紧密绑定在一起，导致非常难支持构建一个良好的多线程 GPU 渲染架构，Chrome 的解决的方法是在 GL 之上构建了一套 GL Context 的 Proxy 机制，Proxy GL Context 同意多个线程创建不同的实例。而每一个 Proxy GL Context 内部使用一个 Command Buffer 跟真正的 GL Context 进行通讯和保持同步。

而 Metal 在设计时就考虑了怎样更好地支持多 CPU 线程同一时候“使用“ GPU，它的 Command Queue/Command Buffer 的模型尽管有点类似 Chrome 的 Proxy 机制。不同的 CPU 线程能够 Encode Commands 到不同的 Command Buffer，然后放入同一个 Queue 里面等待 GPU 的真正运行。

可是 Metal 的这样的内建的支持当然比 Chrome 在 GL 上面的封装来的更方便，易用和高效，也没有那么多限制。

GPU 渲染和计算的无缝整合（Rendering and Compute）

尽管 GLES 未来也会支持 Compute Shader，可是是否能做到 Metal 这样无缝的衔接（包含 Command 的运行和资源的共享）就比較难说了。

统一的资源内存管理模型，同意 CPU 直接訪问 Metal Resource （Buffer/Texture） 的存储内存。并设定了明白的 CPU/GPU 同步时机

尽管 GLES 3 能够通过 Pixel Buffer Object 支持一块 GPU 控制的内存可供 CPU 直接訪问，可是毕竟限制太多，用途有限（另外也因为 GLES 本身缺少良好的多线程支持）。而 Android 的 GraphicsBuffer 系统/硬件兼容性问题成堆。性能參差不齐。没有明白的 CPU/GPU 同步时机，也仅仅能用于特定场景。

简而言之。Metal 让 CPU/GPU 之间的协作更紧密和高效，同意 CPU 通过许多其他方式，使用更灵活 GPU。我们投入了大量的其他任务的 GPU 去完成。