[JS/TS] VS Code性能远超其他Electron应用？解析其底层架构与优化策略

关于 Electron 这个开源项目，背后其实有一段非常有趣的故事。一个有趣的事实是，当年击败了 Atom 编辑器的 VS Code，其底层使用的正是 Atom 开源的 Electron。

2014 年，编辑器市场的领头羊还是 Sublime Text 这样的闭源软件。于是，GitHub 的创始人 Chris Wanstrath 站了出来，认为 GitHub 作为代码托管平台，是时候为开发者打造一款完全开源、高度可定制的代码编辑器了，这就是后来的 Atom。由于 Atom 从一开始就决定使用 Web 技术来实现跨平台，在开发编辑器之前，GitHub 团队先创造了一个名为 “Atom Shell” 的框架。它的思路很简单：用 Web 技术来降低开发跨平台桌面客户端的成本。后来，“Atom Shell” 宣布改名，变成了大家熟知的 Electron。

2022 年 12 月 15 日，GitHub 正式关停了 Atom 项目。然而，Atom 背后的 Electron 却保留了下来，并成就了它曾经的竞争者：VS Code。

如今，当我们谈论 Electron 时，它常被拿来与 Tauri 等基于 WebView 的框架比较。动辄几百兆的安装包和不低的内存占用，让许多人形成了这样的印象：如果只是给 Web 项目套一个桌面端壳子，用 Electron 就足够了。

但事实显然并非如此。VS Code 正是基于 Electron 开发的，其初代安装包仅几十兆。经历了近十年的迭代，安装包大小也不过扩大了一倍。更重要的是，相较于其他 Electron 应用，VS Code 的性能表现似乎格外出色。出于好奇，我们查阅了大量资料，并对其中可理解的部分进行了总结。

首要原因是其强大的开发团队。微软不仅请来了 Erich Gamma（《设计模式》作者之一，也被誉为 Eclipse 之父）来主导项目，还结合了自身在 Visual Studio 开发中积累的丰富经验。这使得 VS Code 的开发团队在起步阶段就拥有了豪华配置。在微软 2018 年的技术博客（“Text Buffer Reimplementation”）中，VS Code 团队详细讲述了他们如何为了优化编辑器的核心组件“文本缓冲区”而采取一系列措施，包括引入全新的数据结构“Piece Tree”，以及在布局渲染和更新中使用原生 JavaScript 实现替代 C++ 代码，从而解决了编辑器打开大文件时崩溃的难题。

在 2019 年的分享（“The First Second”）中，开发团队讲述了他们如何通过分阶段启动、优化 V8 代码缓存、优先加载文件树和编辑器界面等策略来提升启动速度。值得注意的是，VS Code 并未使用任何像 React 或 Vue 这样的前端框架/工程化，而是选择了原生实现。架构上，它采用了多进程设计，将 UI 渲染与业务逻辑分离，并将插件逻辑放在额外的进程中执行（这意味着即使插件崩溃，也不会影响主界面的流畅运行）。此外，项目还大量采用了 WebAssembly 等高性能方案，并利用语言服务器协议（LSP）进行代码解析以实现高亮和补全，而非传统的语法分析方式，同时对进程间通信协议进行了深度优化。这类优化细节在 VS Code 官方博客中比比皆是，因此有人调侃说，VS Code 的优化举措足够写成一本书。

在查阅了大量资料后，我们发现 VS Code 已经不能完全算作一个典型的 Electron 应用了。Electron 在其中只占很小一部分，更像是 VS Code 的一个外壳，其内部早已充满了微软独特的技术印记。当然，VS Code 的性能优势主要是相较于它的前辈 Atom 以及其他仅用 Electron 简单“打包”的客户端应用而言。如今，随着像 Zed 这类利用原生 GPU 渲染的高性能编辑器崛起，VS Code 在极限性能上或许已不占优势。但在当今众多的代码编辑器中，VS Code 仍然是各方面表现最为均衡的那一个。

如果你对这类优秀开源实战项目的技术细节和演进故事感兴趣，欢迎在云栈社区与其他开发者一同交流探讨。