零、前言
为什么要去看 VSCode？因为我们团队在做的中后台快速研发平台云凤蝶也是一款类似 Web IDE 形态的产品：
我希望从 VSCode 身上看到什么？
大型复杂 GUI 软件（如 IDE 类）如何组织功能模块代码
如何使用 Electron 技术将 Web 软件桌面化
如何在打造插件化开放生态的同时保证软件整体质量与性能
一、VSCode 是什么
官方定义
https://code.visualstudio.com/
IntelliSense（代码提示）、 debugging（代码调试）、 git（代码管理） 都是围绕代码编辑的核心链路
extensions （插件）则肩负着打造开放生态的责任
点评：对于工具软件而言，需要内心能想清楚边界。哪些是自己应该专注去做的，哪些可以外溢到交给第三方扩展来满足。
发展历程
2019-05 发布 VSCode Remote Development
团队负责人：Erich Gamma . JUnit 作者之一，《设计模式》作者之一， Eclipse 架构师。2011 加入微软，在瑞士苏黎世组建团队开发基于 web 技术的编辑器，也就是后来的 monaco-editor。VSCode 开发团队从 10 来个人开始，早期成员大多有 Eclipse 开发团队的背景。
Visual Studio Code有哪些工程方面的亮点 维护一个大型开源项目是怎样的体验？「Shape Up」 适合中小团队的一种工作方式
Erich Gamma 在 GOTO 2016 发表了主题为 《The journey of visual studio code: Building an App Using JS/TypeScript, Node, Electron & 100 OSS Components》的演讲，详细讲解了这个项目的发展历程：
没时间观看视频的同学可以选择下载完整 PDF
PPT 的第一页，就是 Erich Gamma 截取自己正式加入微软之后收到的工作内容描述的邮件：
”探索一种全新的和桌面 IDE 一样成功的在线开发工具模式“
整个团队从大致 10 个人开始，混合老中新三代不同水平的程序员，在微软这个巨无霸的商业公司里面想要落地这样一个宏大的愿景是不容易的，团队一开始定下的思路就是像 start up 一样工作，每月每年都要 ship 东西。
同时他也提出早期会疯狂的在公司内部寻找落地场景，比如 Visual Studio Online 的在线 Code DIff 页面，TypeScript 的官网的 Playground 编辑器，OneDrive 代码文件，Edge 浏览器 Dev Tool 的代码浏览等。
一个重要转折点是微软本身发生的巨大变化：
产品定位
Erich Gamma 在 2017 SpringOne Platform 上有一个 关于 VSCode 的分享，讲解了在他开发 Eclipse 的过往经验基础上，对 VSCode 进行顶层设计时的诸多思路与决策，其中提到过对于 VSCode 的产品定位：
点评：生产力工具类的软件一定要守住主线，否则很可能会变成不收门票的游乐园
牛逼的产品背后一定有牛逼的团队，比如微软挖到 Anders Hejlsberg，接连创造了 C# 和 TypeScript
挖到 Erich Gamma，接连诞生了 monaco 和 vscode 这些明珠
二、Electron 是什么
上文提到 VSCode 有一个特性是跨平台，它的跨平台实质是通过 electron 实现的。所以我们需要先简单了解下 electron
官方定义
核心技术
使用 Web 技术来编写 UI，用 chrome 浏览器内核来运行
使用 NodeJS C++ Addon 去调用操作系统的 native API
应用架构
https://electronjs.org/docs/tutorial/application-architecture
1 个主进程：一个 Electron App 只会启动一个主进程，它会运行 package.json 的 main 字段指定的脚本
N 个渲染进程：主进程代码可以调用 Chromium API 创建任意多个 web 页面，而 Chromium 本身是多进程架构，每个 web 页面都运行在属于它自己的渲染进程中
进程间通讯：
Render 进程之间的通讯本质上和多个 Web 页面之间通讯没有差别，可以使用各种浏览器能力如 localStorage
Render 进程与 Main 进程之间也可以通过 API 互相通讯 (ipcRenderer/ipcMain)
点评：普通 web 页面无法调用 native api，因此缺少一些能力
electron 的 web 页面所处的 Render 进程可以将任务转发至运行在 NodeJS 环境的 Main 进程，从而实现 native API
这套架构大大扩展了 electron app 相比 web app 的能力丰富度
但同时又保留了 web 快捷流畅的开发体验，再加上 web 本身的跨平台优势
结合起来让 electron 成为性价比非常高的方案
三、VSCode 技术架构
多进程架构
主进程：VSCode 的入口进程，负责一些类似窗口管理、进程间通信、自动更新等全局任务
插件宿主进程：每个插件的代码都会运行在一个独属于自己的 NodeJS 环境的宿主进程中，插件不允许访问 UI
Debug 进程：Debugger 相比普通插件做了特殊化
Search 进程：搜索是一类计算密集型的任务，单开进程保证软件整体体验与性能
开发流程
开发文档：https://github.com/Microsoft/vscode/wiki/How-to-Contribute
主仓库：https://github.com/microsoft/vscode
其它关联项目：https://github.com/Microsoft/vscode/wiki/Related-Projects
# 检出代码 git clone [email protected] :microsoft/vscode.git cd vscode # 安装依赖 yarn # 启动 web 版 yarn watch && yarn web # 启动 桌面 版 yarn watch && ./scripts/code.sh # 打包 yarn run gulp vscode-[platform] yarn run gulp vscode-[platform]-min # platforms: win32-ia32 | win32-x64 | darwin | linux-ia32 | linux-x64 | linux-arm
源码组织
https://github.com/microsoft/vscode/wiki/Source-Code-Organization
下面是整个 VSCode project 的一些顶级的重点文件夹，后文会重点关注 src 与 extensions:
├── build # 构建脚本 ├── extensions # 内置插件 ├── scripts # 工具脚本 ├── out # 产物目录 ├── src # 源码目录 ├── test # 测试代码
VSCode 的代码架构也是随着产品阶段演进而不断更迭的：
1. 隔离内核 (src) 与插件 (extensions)，内核分层模块化
/src/vs/base: 通用的公共方法和公共视图组件
/src/vs/code: VSCode 应用主入口
/src/vs/platform：可被依赖注入的各种纯服务
2. 每层按环境隔离
内核里面每一层代码都会遵守 electron 规范，按不同环境细分文件夹:
common: 公共的 js 方法，在哪里都可以运行的
browser: 只使用浏览器 API 的代码，可以调用 common
node: 只使用 NodeJS API 的代码，可以调用 common
electron-browser: 使用 electron 渲染线程和浏览器 API 的代码，可以调用 common，browser，node
electron-main: 使用 electron 主线程和 NodeJS API 的代码，可以调用 common， node
点评：云凤蝶也遇到了类似问题，作为一个 低代码 + 可视化 的研发平台，许多功能模块的实现都需要横跨编辑态和运行态
如果代码不加以限制和区分，很容易导致错误的依赖关系和预期之外的 bug
因此云凤蝶最终也决定采用 (editor/runtime/common) 类似的隔离架构
3. 内核代码本身也采用扩展机制: Contrib
可以看到 /src/vs/workbench/contrib 这个目录下存放着非常多的 VSCode 的小的功能单元：
├── backup
Contrib 有一些特点：
Contrib 目录下的所有代码不允许依赖任何本文件夹之外的文件
Contrib 主要是使用 Core 暴露的一些扩展点来做事情
每一个 Contrib 如果要对外暴露，将API 在一个出口文件里面导出 eg: contrib/search/common/search.ts
一个 Contrib 如果要和另一个 Contrib 发生调用，不允许使用除了出口 API 文件之外的其它文件
接上一条，即使 Contrib 事实上可以调用另一个 Contrib 的出口 API，也要审慎的考虑并尽量避免两个 Contrib 互相依赖
VSCode 开发团队做这个设计的目的我猜可能是因为重型的工具软件功能点实在太多，如果这些功能代码直接采用原始的模块引用的方式聚合拼装起来，是一个自顶向下的架构，对维护性的挑战比较大。
而采用暴露扩展点的方式，可以将依赖关系反转，依附于扩展点协议，将核心功能和非核心功能分割开，独立的小功能的代码实现可以单独聚合，降低信息密度与提升维护性。
但是 VSCode Contrib 的具体业务代码组织其实看起来没有太多范式，而且这个内核代码的扩展机制 Contrib 和 VSCode 开放给外界的插件化机制 extension 是有差异的，读起来十分头疼。
通过和兄弟团队 CloudIDE 开发组的专家交流，我得到两条主要差异性：
extension 每一个都是运行在归宿于自己的独立宿主进程，而 contrib 的功能基本是要运行在主进程的
extension 只能依附于 core 开放的扩展点而活，但是 contrib 可以通过依赖注入拿到所有 core 内部实现的 class （虽然官方不推荐）
4. 依赖注入
上一小节提到了 VSCode 的代码大量使用了依赖注入，这项技术的具体实现细节本文不会展开细讲，感兴趣的可以阅读一些好的实现：
社区开源的强大的 http://inversify.io
TS 依赖注入常见的实现原理是使用 reflect-metadata 设置与获取元信息，从而可以实现在运行时拿到本来属于编辑态的 TypeScript 类型相关元信息，具体来说就是下面这些 API：
Reflect.getMetadata("design:type", , target, key): 获取 class 属性类型元信息
Reflect.getMetadata("design:paramtypes", target, key): 获取 class 方法参数元信息
Reflect.getMetadata("design:returntype", target, key)：获取 class 方法返回值元信息
Reflect.defineMetadata(metadataKey, metadataValue, target, propertyKey)：设置元信息
Reflect.getMetadata(metadataKey, target, propertyKey): 获取元信息
不过具体到 VSCode 的依赖注入，它没有使用 reflect-metadata 这一套，而是基于 decorator 去标注元信息，整个实现了一套自己的依赖注入方式，具体可以参考vscode 源码解析-依赖注入 这篇文章，大致包含如下几类角色：
举个例子来看，在 /src/core/platform 里面定义了大量 service，其他地方消费者 Client 都可以用依赖注入的方式使用到，伪代码如下：
class Client { // 构造函数参数注入（依赖注入方式的一种） constructor( // 必选 @IModelService modelService: IModelService, // 可选 @optional(IEditorService) editorService: IEditorService ) { // use services } } // 实例化 instantiationService.createInstance(Client);
5. 绝对路径 import
点评：绝对路径 import 是一个非常值得学习的技巧，具体的方式是配置 TypeScript compilerOptions.paths
相对路径 import 对阅读者的大脑负担高，依赖当前文件位置上下文信息才能理解
假设修改代码的时候移动文件位置，相对路径需要修改本文件的所有 import，绝对路径不需要
6. 命令系统
VSCode 和 monaco-editor 都有自己的命令系统，蚂蚁 CloudIDE 团队的同学也曾经对命令系统的优势做过总结：
传统的模块调用是个网状，不太好找到一个切面来理解或治理：
而命令系统是中心化的，各功能末端变成了扁平化的结构：
点评：云凤蝶编辑器也遇到这类问题，云凤蝶的自由画布编辑器有非常多的功能，参见 《打造媲美 Sketch 的自由画布》
而且很多情况下一个功能的触发方式是多种多样的，比如大纲树右键菜单触发，顶部工具栏触发，画布右键菜单触发，键盘快捷键触发等
这就要求该功能的实现函数能跨区域在多个位置调用，这很容易导致代码依赖关系异常混乱。而命令系统就是一种解决这个问题的很好思路
7. TypeScript
启动流程 （TLDR）
上文初步了解了 vscode 的技术架构与源码组织，手痒的同学估计有点等不及尝试走一遍 vscode 的启动流程了。
然后在正式发车之前，我需要给大家一点友情提醒，如果你没耐心看完下面的 VSCode 的启动流程，应该知道，人生得过且过 o(╥﹏╥)o
总体来看，VSCode 的启动代码真正 show 给我们看了一个复杂的客户端软件的代码会工程化到什么地步，这其中掺杂了大量的基于 TypeScript 的 OOP 式的代码组织，各种对边界，宿主环境，上下文的处理，本来简单的启动 APP 渲染一个页面流程变得极其复杂。
下面精简抽取核心启动链路的文件和方法看一看：
入口：package.json { "main": "./out/main" } : electron 的标准启动入口
'/out/main.js': 是构建产物的入口文件，它对应源码 '/src/main.js'
// /src/main.js 的精简核心链路 const { app, protocol } = require('electron'); app.once('ready', function () { // electron 启动好之后，调用 vscode 的入口 onReady(); }); async function onReady() { // 获取缓存文件目录地址和语言配置，执行启动 const [cachedDataDir, nlsConfig] = await Promise.all([nodeCachedDataDir.ensureExists(), resolveNlsConfiguration()]); startup(cachedDataDir, nlsConfig); } function startup(cachedDataDir, nlsConfig) {
// 先加载 vscode 自己开源的 AMD Loader https://github.com/Microsoft/vscode-loader/ // 再使用这个 loader 去加载 VSCode 的主入口文件 require('./bootstrap-amd').load('vs/code/electron-main/main'); } // /src/vs/code/electron-main/main.ts 精简核心链路 // 初始化主类 const code = new CodeMain(); // 执行主入口函数 code.main(); class CodeMain { main() { // vscode 的 class public 入口一般只是空壳，真正的都在 private 逻辑里面 this.startUp(); } private async startup() { // 先创建依赖的初始化 service const [instantiationService, instanceEnvironment] = this.createServices(); // 创建编辑器实例并调用 startUp 方法 return instantiationService.createInstance(CodeApplication).startup(); } } // /src/vs/code/electron-main/app.ts export class CodeApplication extends Disposable { async startup(): Promise { // IPC Server const electronIpcServer = new ElectronIPCServer(); // SharedProcess const sharedProcess = this.instantiationService.createInstance(SharedProcess, machineId, this.userEnv); // 创建一大堆依赖的 service // IUpdateService IWindowsMainService IDialogMainService IMenubarService IStorageMainService...... const appInstantiationService = await this.createServices(machineId, trueMachineId, sharedProcess, sharedProcessClient); // 打开一个窗口 const windows = appInstantiationService.invokeFunction(accessor => this.openFirstWindow(accessor, electronIpcServer, sharedProcessClient)); } private openFirstWindow() { const windowsMainService = this.windowsMainService = accessor.get(IWindowsMainService); return windowsMainService.open(); } } // /src/vs/platform/windows/electron-main/windowsMainService.ts export class WindowsMainService extends Disposable implements IWindowsMainService { open() { // 执行 open this.doOpen(); } private doOpen() { // 打开浏览器窗口 this.openInBrowserWindow(); } private openInBrowserWindow() { // 创建窗口 const createdWindow = window = this.instantiationService.createInstance(CodeWindow, { state, extensionDevelopmentPath: configuration.extensionDevelopmentPath, isExtensionTestHost: !!configuration.extensionTestsPath }); } private doOpenInBrowserWindow() { // 加载页面 window.load(configuration); } } // /src/vs/code/electron-main/window.ts export class CodeWindow extends Disposable implements ICodeWindow { load() { // 调用 electron 的 api 加载一个 url 的 html 页面 this._win.loadURL(this.getUrl(configuration)); } private getUrl() { // 获取要打开的 url let configUrl = this.doGetUrl(config); return configUrl; } private doGetUrl(config: object): string { // 终于看到 html 了！！泪流满面〒▽〒 // 打开 VSCode 的工作台，也就是 workbench 👏 return `${require.toUrl('vs/code/electron-browser/workbench/workbench.html')}?config=${encodeURIComponent(JSON.stringify(config))}`; } }
代码编辑器技术
因为本文关注的重点并不在真正的代码编辑器技术而是在调研一下大型软件的工程化，因此本文只会简要介绍一下代码编辑相关的的一些核心技术：
monaco-editor 文本编辑器，非常精深的领域，不展开聊，可以看一些有意思的细节：
language server protocol 语言提示， 也是 vscode 的一大创举：
不再关注 AST 和 Parser，转而关注 Document 和 Position，从而实现语言无关。
将语言提示变成 CS 架构，核心抽象成当点击了文档的第几行第几列位置需要 server 作出什么响应的一个简单模型，基于 JSON RPC 协议传输，每个语言都可以基于协议实现通用后端
Debug Adaptor Prototal: 调试协议
点评：monaco-editor 可以看出专家级人物的领域积累，属于 VSCode 的核心竞争力
language server protocol 和 Debug Adaptor Prototal 的设计就属于高屋建瓴
可以看出思想层次，把自己的东西做成标准，做出生态，开放共赢
四、VSCode 插件系统
理念差异
Visual Studio / IntelliJ：不需要插件，all in one （不够开放）
Eclipse: 一切皆插件 （臃肿、慢、不稳定、体验差）
