Skia已经非常好了，为什么Flutter还要开发Impeller？

哈喽，我是老刘

前几天有朋友联系到我，希望帮忙用Flutter开发一个linux上的应用。
他们的需求比较特别的一点就是程序最终运行在一个基于树莓派的Ubuntu系统上。
所以需求中有非常明确的性能优化的部分。
因为项目中某些页面有大量的图表，在树莓派上测试发现这类Flutter页面会比较卡顿。
接下来我解释一下为什么树莓派运行Flutter程序会卡顿，以及Impeller能带来哪些优化。

其实Flutter在低性能平台的卡顿现象，一方面因为Flutter设计的主要目标场景就不是低性能平台。
另一方面Flutter的渲染引擎skia也有承担一定的责任。
这一点在后续的Impeller引擎中会得到一定程度的优化。
接下来我们就来看看Skia的问题。

Skia是一个通用渲染引擎

Skia作为Android的官方渲染引擎，经过了这么多年的发展和优化，应该已经非常的成熟和稳定了。
那为啥还会有很多性能瓶颈，需要Flutter专门开发一款渲染引擎呢？
我觉得最根本的问题就是Skia是一款通用的2D图形库。

Skia 的设计初衷是为了服务于广泛的应用和平台，而不是专门为某个特定的框架或应用定制。
这就造成了以下的一些问题：
通用性带来的损失
由于 Skia 需要支持多种不同的应用和平台，它必须包含丰富、全面的功能。
为了实现这种丰富和全面每个功能的增加和修改都必须要考虑非常多的场景。
因此就必然带来代码实现上的复杂性，这会很大程度上影响开发和维护的效率。
另一方面是会带来性能的影响。
在一个平台上比较好的算法，在另一个平台上可能效果就不理想。
因此skia的开发者必须要找到一个在不同平台、框架下都表现不错的选择。
因此就不可能针对某一个平台或者框架做优化。

资源和优先级分配
Skia 的开发团队可能需要将资源和优先级分配给更广泛的用户群体和需求。
那么当Flutter需要底层的引擎提供某些功能，或者尽快修复某些bug的时候，Skia开发团队可能无法提供快速的响应。

技术栈和架构限制
Skia 的现有技术栈和架构可能限制了它在特定优化方面的灵活性。
例如，动态着色器编译可能是 Skia 的一个固有特性。Flutter可能希望它提供预热类的功能。
但是因为前面说过的资源分配问题和自身架构，迟迟得不到开发。

总的来说，Skia 面临的挑战在于它需要平衡广泛的应用需求和特定框架的优化需求，这可能导致它在某些方面难以完全满足 Flutter 的特定需求。
而这些也是Flutter 团队开发 Impeller的主要原因。
他们可以更自由地进行优化，以满足 Flutter 的特定需求，从而提供更好的性能和用户体验。

那么Impeller都带来了哪些优化呢？下面就简单盘点一下。

Impeller相对Skia的优势

专门针对 Flutter 优化：
Impeller 是专门为 Flutter 设计的渲染引擎，与通用的 Skia 图形库相比，可以更有效地针对 Flutter 的需求进行优化。
GPU 利用效率更高：
Impeller 能够更有效地利用 GPU 资源，减少渲染动画和复杂 UI 元素所需的工作量，从而提高渲染速度。
图形渲染优化：
采用 tessellation 和着色器编译技术，提前优化图形渲染，减少设备上的硬件工作负载，实现更快的帧速率和更流畅的动画。
预编译着色器：
与 Skia 动态编译着色器不同，Impeller 会提前编译大部分着色器，减少渲染延迟，降低动画过程中的卡顿。
简化的分层架构：
Impeller 采用新的分层架构，简化渲染过程，允许每个组件以最大效率执行特定任务，减少转换 Flutter Widget 到像素的步骤。
硬件抽象层（HAL）：
提供统一的接口，抽象不同图形 API 的细节，确保 Impeller 的跨平台能力，同时在性能上扮演重要角色。
抗锯齿和裁剪优化：
Impeller 通过多重采样抗锯齿 (MSAA) 技术优化抗锯齿效果，使用模板缓冲区优化裁剪操作，提高执行效率。
应用大小和启动时间：
尽管预编译着色器可能会增加应用大小和启动时间，但 Impeller 设计的着色器相对简单，有助于保持应用的启动时间和整体大小。
底层优化：
在底层对昂贵的操作如抗锯齿和裁剪进行了优化，提高了整体的渲染性能。
易于维护和更新：
分层结构的设计使得引擎更加高效，并且更易于维护和更新，因为不同的关注点被分离。