我们一直都非常推崇标准和最小抽象。我们的整个界面都使用常规 DOM 节点构建,只使用了几个辅助库。我们已经开始将其中一些组件移入 base-elements,这是一个低级可复用组件库。就像我们的大多数技术一样,我们一直在迭代它,直到我们做对为止,但作为一个团队,我们感觉我们在这方面正朝着正确的方向前进。
$ bkr fork dat://0ff7d4c7644d0aa19914247dc5dbf502d6a02ea89a5145e7b178d57db00504cd/ ~/my-fork $ cd ~/my-fork $ echo "My fork has no regard for the previous index.html!" > index.html $ bkr publish
这是个很好的问题,又不是市面上没有屏幕录制工具!我们觉得现有选项要么太复杂、太昂贵,要么太受限。没有一个感觉完全符合我们的日常需求。我们也认为,当我们用来工作的工具是开源的,每个人都可以帮助塑造它们时,这很棒。构建 Kap 最终也关乎我们没有做的事情。一切都在细节里,是小改进的累积构成了我们想要使用的工具的轮廓。
使用 Electron 提供的资源进行屏幕录制是最大的挑战。它们性能不足以满足我们的需求,在我们看来会导致项目失败。虽然这不是 Electron 本身的错,但原生开发与使用 Web 技术构建桌面应用之间仍然存在差距。
我们花费了大量时间试图解决 getUserMedia API 性能不佳的问题,这个问题源于 Chromium。我们着手开发 Kap 的主要目标之一是使用 Web 技术构建整个应用。在尝试了所有可能的方法使其工作(最低要求是在 Retina 屏幕上达到 30 FPS)后,我们最终不得不寻找其他解决方案。
我们都知道 Electron 应用可能有点爱用内存(RAM),但这确实是 Chromium 的问题。这是它的工作方式的一部分,而且很大程度上取决于你运行什么,例如 Kap 和 Hyper 通常使用不到 100MB 的内存。
我们看到的一个最大改进领域是应用包大小(payload),特别是 Electron 如何分发 Chromium。一个想法是拥有一个共享的 Electron 核心,并让应用安装程序检查系统上是否已经存在它。
创建跨平台 Electron 应用的体验可以更好。现在,不同平台之间存在太多不一致、特定于平台的 API 和缺失的功能,导致你的代码库充满了 if-else 语句。例如,vibrancy 效果只在 macOS 上支持,自动更新器在 macOS 和 Windows 上工作方式不同,在 Linux 上甚至不支持。透明度在 Linux 上时好时坏,通常是不行。
调用原生系统 API 也应该更容易。Electron 提供了一套非常好的 API,但有时你需要它不提供的功能。创建一个原生的 Node.js 插件(addon)是一种选择,但使用起来很痛苦。理想情况下,Electron 应该自带一套好的外部函数接口 (FFI) API,比如fastcall。这将使我们能够用 JavaScript 而不是 Swift 来编写那部分代码。