VSCode架构

VSCode中包含主进程，渲染进程，同时因为VSCode提供了插件的扩展能力，又出于安全稳定性的考虑，图中又多了一个Extension Host，其实这个Extension Host也是一个独立的进程，用于运行我们的插件代码。并且同渲染进程一样，彼此都是独立互不影响的。Extension Host Process暴露了一些VSCode的API供插件开发者去使用。

VSCode的进程结构

VSCode采用多进程架构，启动后主要由下面几个进程：

• 后台进程
• 编辑器窗口 - 由后台进程启动，也是多进程架构
  • HTML编写的UI
    • ActivityBar
    • SideBar
    • Panel
    • Editor
    • StatusBar
  • Nodejs异步IO
    • FileService
    • ConfigurationService
  • 插件宿主进程
    • 插件实例
      • 插件子进程 - 如TS语言服务
    • 插件实例
    • 插件实例
  • Debug进程
  • Search进程

后台进程

后台进程是 VSCode 的入口，主要负责管理编辑器生命周期，进程间通信，自动更新，菜单管理等。

我们启动 VSCode 的时候，后台进程会首先启动，读取各种配置信息和历史记录，然后将这些信息和主窗口 UI 的 HTML 主文件路径整合成一个 URL，启动一个浏览器窗口来显示编辑器的 UI。后台进程会一直关注 UI 进程的状态，当所有 UI 进程被关闭的时候，整个编辑器退出。

此外后台进程还会开启一个本地的 Socket，当有新的 VSCode 进程启动的时候，会尝试连接这个 Socket，并将启动的参数信息传递给它，由已经存在的 VSCode 来执行相关的动作，这样能够保证 VSCode 的唯一性，避免出现多开文件夹带来的问题。

编辑器窗口

编辑器窗口进程负责整个 UI 的展示。也就是我们所见的部分。UI 全部用 HTML 编写没有太多需要介绍的部分。

Nodejs异步IO

项目文件的读取和保存由主进程的 NodeJS API 完成，因为全部是异步操作，即便有比较大的文件，也不会对 UI 造成阻塞。IO 跟 UI 在一个进程，并采用异步操作，在保证 IO 性能的基础上也保证了 UI 的响应速度。

插件进程

每一个 UI 窗口会启动一个 NodeJS 子进程作为插件的宿主进程。所有的插件会共同运行在这个进程中。这样设计最主要的目的就是避免复杂的插件系统阻塞 UI 的响应。但是将插件放在一个单独进程也有很明显的缺点，因为是一个单独的进程，而不是 UI 进程，所以没有办法直接访问 DOM 树，想要实时高效的改变 UI 变得很难，在 VSCode 的扩展体系中几乎没有对 UI 进行扩展的 API。

Debug进程

Debugger 插件跟普通的插件有一点区别，它不运行在插件进程中，而是在每次 debug 的时候由UI单独新开一个进程。

搜索进程

搜索是一个十分耗时的任务，VSCode 也使用的单独的进程来实现这个功能，保证主窗口的效率。将耗时的任务分到多个进程中，有效的保证了主进程的响应速度。