为什么企业喜欢「再造轮子」，比如 Flutter 的 Dart ，Apple 的 Swift_AI阅读总结 — 包阅AI

今天刚好在知乎收到这样一个话题，这里感觉可以闲扯一下，因为这个疑惑或者“不满”，相信挺多开发者都会有，而且这个话题也适合展开聊聊。

这个问题的答案也很简单，大家应该也都明白，其实目标就是为了更可控和更自主得发展，

关于这个话题，其实早在Objective-C时代就有过类似经历，现在的流行的 Clang 也是 Apple 发起的一个产物，Clang 的设计初衷是提供一个可以替代 GCC 的前端编译器，因为GCC 的发展不符合 Apple 的节奏和需要，同时受限于License，苹果公司无法使用 LLVM 在 GCC 基础上进一步提升代码生成质量，因此苹果公司决定从头编写 C、C++、Objective-C 语言的前端 Clang，以彻底替代GCC。

所以，苹果不是第一个这么做的，也不是最后一个，不严谨的例子：

成熟的开源，或者说其他企业的开源，或者开源基金维护的开源，他们多少都需要在通用性质上去考量，很多你需要的改动，可能并没有办法被合并或者推进。

所以就算有 Java、Kotlin 甚至 C# 后来的开源，但是苹果还是选择了自研 Swift ，因为自己掌控的项目才可以更贴合自己的需求。

尽管这些语言和框架可能思想和 API 很接近。

类似的 Google 上也有被很多人诟病的 Dart ，其实 Dart 本来已经凉了，但是谷歌 chrome 团队在做一些内部项目测试的时候，倒腾出来了 Flutter ，如果按照广大开发者的想法，你这时候只要用 JS/TS ，其实就能避免很多早期的困境，但是它最后还是选择了 Dart。

所以可以看到 Dart 一直是 Flutter 被人「吐槽」的原因，因为大家无法理解或者无法接受这样一个“小众语言”的存在。

但多年过去，你可以看到几乎每个版本里 Dart 都可以贴合 Flutter 的需求去调整，每个版本也都是跟随 Flutter 需要的节奏，甚至为了 Flutter Web 的路线， Dart 团队可以去推进 Wasm GC 的落地，这就是取舍。

另外的原因，可以参看类似的： Skia 明明已经很成熟，为什么 Flutter 还搞自研 Impeller ？

答案自然是问题的推进。

Skia 肯定是一个优秀的通用 2D 图形库，例如 Google Chrome 、Android、Firefox 等设备都是用了 Skia ，但是也因为它的「通用性」，所以它不属于 Flutter 的形状，它无法专门针对 Flutter 的要求去进行优化调整，例如 Skia 附带的许多功能超出了 Flutter 的要求，其中一些可能会导致不必要的开销并导致渲染时间变慢，例如着色器预热等 。

与 skia 的不同在于，Impeller 会提前预编译大多数着色器，从而减少渲染延迟，并消除与动态着色器编译相关的卡顿，因为预编译发生在 Flutter 应用的构建过程里，所以可以确保着色器在应用启动后立即可用。

这也是为什么会「再制造轮子的原因」，因为 Skia 需要考虑的问题很多，它是一个通用性的平台，而 Impeller 是专门为 Flutter 而生，它主要核心就是优化 Flutter 架构的渲染过程，它渲染方法在 Flutter 上可以比 Skia 能更有效地利用 GPU ，让设备的硬件以更少的工作量来渲染动画和复杂的 UI 元素，从而提高渲染速度。

所以不是 Impeller 就比 Skia 优秀，而是 Impeller 可以更贴合 Flutter 需要的形状。

类似的例子还有最近发布的 Flutter GPU ，Flutter GPU 作为 Flutter 内置的底层图形 API，它可以通过编写 Dart 代码和 GLSL 着色器在 Flutter 中构建和集成自定义渲染器，而无需 Native 平台代码。

而 Flutter 团队也表示过，Impeller 的 HAL 和 Flutter GPU 都没打算成为类似 WebGPU 这样的正式标准，相反，Flutter GPU 主要是由 Flutter 社区开发和发展，专职为了 Flutter 服务，所以不需要考虑「公有化」的兼容问题。

所以，从这里可以看出，在通用性和专用性质的取舍。

类似的还有 Facebook 的 React Native ，Hermes JS 和 JSI 也是规模下的产物，因为对于 JSC 的表现不满意，推进难度和节奏考虑，所以最终自研 Hermes JS 作为 React Native 的 JS 引擎。

扯了这么多题外话，再回到 Apple ，事实上现在 iOS 上的 Metal 底层渲染 API 也是一个例子，尽管已经有 OpenGL 的存在，但是 iOS 还是选择了全面自研的 Metal ：

Metal 里资源在 CPU 和 GPU 之间的同步访问是由开发者自己负责，它提供更快捷的资源同步 API，可以有效降低 OpenGL 里纹理和缓冲区复制时的耗时；另外 Metal 使用 GCD 在 CPU 和 GPU 之间保持同步，CPU 和 GPU 是共享内存无需复制就可以交换数据。

Metal 是 Apple 的，它不需要像 OpenGL 和 Vulkan 考虑过多通用型，它甚至可以帮开发者做好一些操作，例如：

Metal 会自动帮助开发者处理幕后管理工作，它会执行更多自动化操作来处理加速视觉效果和增强性能等后台管理，然而 Vulkan 是更多提供 API，主要取决于开发者自主的控制。

类似的，鸿蒙上已经有 ArkTS 为什么还仓颉？其实华为也给出了答案：仓颉未来是一款面向全场景应用开发的现代编程语言，以及一系列相关自研配套工具。

所以为什么放着已经有的开源不用，不去推进已有开源项目进一步适配，而是转头又开始搞新轮子呢？诚然的有的企业就是单纯为了 KPI 在考虑，而对于项目“经历风雨”之后还能存在的情况，那就只能是它表现出自己的价值。

所以答案其实就很明显了：因为可以更自主可控，因为可以更贴合需求，可以更快解决问题，当时也会增加更多成本。