tinyshare微博账号
你的VS Code拓展很慢?教你怎么让它提速 四月 1, 2019

- Extensions Rock -

VS Code用户(我们中的很多人)非常喜欢我们的拓展,有数千个VS Code拓展可选,而且我们中很多人都安装了一些。它们照亮了你喜爱的编程语言,格式化代码,或者让你的主题更加地多彩。

你是否意识到,有一些拓展在VS Code启动之后,需要花费几分钟来初始化?是什么引起的这种延迟?

关于这个问题,你能做点什么?事实上,你可以做很多。跟我一起来看看你可以为喜爱的拓展更快地加载做些什么。

一个可能的原因,是文件的数量和拓展的大小。一些拓展里面有非常多的功能,这些功能会随着时间让拓展越来越慢。

等等,为什么是这样

当我们为web构建app时,我们写了几十个或数百个JavaScript,CSS 和 HTML文件。我们不想通过网络向一个浏览器发送一千个文件,因为这样的体验很差,会一直等待着加载。当我们没有尽可能地让我们写的代码针对浏览器进行优化,体验也很差。现代化的工具通过将多个文件压缩成一个(或一个小集合)文件来帮我们解决这个问题,一个流行的工具叫WebPack

如果你使用命令“Developer: Show Running Extensions”,你讲看到你的VS Code实例中一个被激活的拓展的列表。在列表的右侧,你也将看到每个拓展要激活所需要的毫秒数。

这是发现哪个拓展激活缓慢的非常好的一个方法。注意看下面我的VS Code中安装的拓展,和它们的激活时间。明显地,一些拓展比其它拓展耗费更长的时间来加载,因为它们做的事情更多。

如果一个拓展耗费更长的时间,你可以做什么?(可能1000ms?)

让拓展更快

最近,VS Code团队发布了一个使用WebPack来打包拓展的文件的功能。

这篇文章真的涵盖了所有,在打包一个拓展的时候是有帮助的。

我发现我的拓展Peacock将48个文件打包到一个包里。我做了一些调整,我把这个削减了很多。

首先,我将一些文件添加到.vscodeignore文件中。

# Files I excluded
azure-pipelines.yml
ISSUE_TEMPLATE.md
PULL_REQUEST_TEMPLATE.md
vsc-extension-quickstart.md
node_modules/**/test/**

# After webpack, we have more to ignore
node_modules
out/
src/
tsconfig.json
webpack.config.json

然后,我为我的拓展创建了一个新的分支,我查阅了VS Code文档中步骤,使用WebPack更新了我的项目。

我的目标是让下面这些仍然能工作:

  • 使用 npm run package 打包
  • 使用 npm run publish 发布
  • 使用 npm run test 做本地CI测试
  • 使用F5和 launch.json 调试
  • 使用F5和 launch.json 调试测试

这种方法让我用Webpack和TSC编译测试和调试。

这是我的项目:https://github.com/johnpapa/vscode-peacock

改变package.json中的main文件:

"main": "./dist/extension",

package.json 中的npm scripts:

"scripts": {
  "package": "npx vsce package",
  "publish": "npx vsce publish",

  "vscode:prepublish": "webpack --mode production",
  "compile": "webpack --mode none",
  "watch": "webpack --mode none --watch",

  "postinstall": "node node_modules/vscode/bin/install",
  "just-test": "node node_modules/vscode/bin/test",
  "test-compile": "tsc -p ./ && npm run compile",
  "test": "npm run test-compile && node node_modules/vscode/bin/test"
},

launch.json中调试运行和测试的configurations:

"configurations": [
  {
    "name": "Run Extension",
    "type": "extensionHost",
    "request": "launch",
    "runtimeExecutable": "${execPath}",
    "args": ["--extensionDevelopmentPath=${workspaceFolder}"],
    "outFiles": ["${workspaceFolder}/dist/**/*.js"],
    "preLaunchTask": "npm: test-compile"
  },
  {
    "name": "Extension Tests",
    "type": "extensionHost",
    "request": "launch",
    "runtimeExecutable": "${execPath}",
    "args": [
      "${workspaceFolder}/testworkspace",
      "--disable-extensions",
      "--extensionDevelopmentPath=${workspaceFolder}",
      "--extensionTestsPath=${workspaceFolder}/out/test"
    ],
    "outFiles": ["${workspaceFolder}/out/test/**/*.js"],
    "preLaunchTask": "npm: test-compile"
  }
]

下面这整个repo里你可以看到上下文中说到的任何东西👇

https://github.com/johnpapa/vscode-peacock

它能有什么影响?

这是一个很好的问题,也是一个我们绝对要回到的问题。我的意思是,毕竟,任何代码更改都必须有一定的价值。我可以获得分享一些两个你可能使用过的拓展的性能统计(非官方测试)的权限(感谢VS Code团队和Erich Gamma)。

这两个拓展都有一个非常大量的逻辑在里面,且都做了一些相当让人印象深刻和有用的事情。

Azure Account

Azure Account拓展的大小和文件的数量减少的相当多。。。就像从"我的天"到"还不坏"。

热激活是一个术语,表示拓展之前已经安装过了(不是第一次)还需要多久才能启动。这个拓展的热激活被砍了一半,总之不算太坏。

  • 下载大小(.vsix):6.2M到840K
  • 打包文件数:4300到11
  • 热激活时间:676ms到338ms

Docker

Docker拓展有一个值得注意的是,热激活提升到2秒内。但是,关键的方面是冷激活时间。领激活是拓展被安装时需要多少时间来激活。

  • 热激活时间:3.5s到小于2s
  • 冷激活时间(第一次安装之后):20s到2s

Tips

一些事情受使用webpack来打包一个拓展的影响。这就是为什么测试所有这些非常重要。

  • 在你的调试中本地运行这个拓展(并且测试你可以打断点)
  • 打包这个拓展,并从菜单中加载它(从VSIX加载)
  • 用debugger来运行你的测试(而且,你可以打断点测试)
  • npm test 来运行你的测试脚本

但是,我不写拓展

没事,但是如果你喜欢拓展,考虑为它的仓库创建一个pull request(PR)来启用webpack打包。

关于OSS很棒的一点,是每个人都有发言权,这是一个很棒的方式来帮你喜欢的项目和你的同事。