激活慢怎么查?
结论
用「开发人员:显示正在运行的扩展」看每个插件的激活耗时和激活事件。再用扩展二分定位是谁拖慢启动。优化目标是推迟激活,并缩短 activate 里同步工作的时间。
展开
排查顺序:
- 命令面板运行「Developer: Show Running Extensions」。看启动激活还是按需激活,耗时多少。
- 如果一启动就出现,检查是不是写了
*、过宽的workspaceContains,或在别的启动插件里被executeCommand连带激活。 - 「Developer: Startup Performance」可以看到启动各阶段。扩展宿主被某个
activate堵住时,这里能对上时间。 - 不确定是哪个插件时用「扩展二分」。编辑器会一半一半禁用,帮你找到导致慢或功能异常的那个。
代码里常见的慢:
activate里同步递归扫描仓库- 等语言服务器完全就绪才让
activate的 Promise 完成 - 顶层 import 了一个很重的分析库,模块加载时间也算进激活
- 读取很多配置并立刻建索引
改法:
- 激活事件改成
onLanguage、onView、onCommand activate只注册,扫描放后台- 重依赖动态
import(),第一次真正用到再加载 - 缓存放到
globalStorageUri,不要每次重算
耗时应以用户机器上的跟踪为准,不要只在空仓库里感觉「很快」。
容易讲错的点
- 激活耗时不包括用户后来点命令的执行时间。命令慢要另做计时。
- 打包进
extension.js的体积会影响加载。激活函数很短但包巨大,时间会花在加载模块上。 - 远程时要分清慢的是本地 UI 还是远端宿主。两边各有一份运行扩展列表。