大家好！你有没有使用过 Visual Studio Code（简称 VS Code）？如果你是一名开发人员，那么你很可能使用过这款流行的开源代码编辑器。在这篇文章中，我将分享 VS Code 团队如何通过名称混淆技术将其 JavaScript 代码的大小减小了 20%。这不仅意味着你需要下载和存储的代码更少，还意味着启动时间更快，因为在运行 JavaScript 之前需要扫描的源代码更少。这是一项令人印象深刻的优化工作，而且并没有删除任何代码或进行任何重大的代码重构。
发现问题
VS Code 团队一直致力于提升性能，包括优化热门代码路径、减少 UI 重排或加速启动时间。其中之一就是减小 VS Code 的 JavaScript 代码大小。然而，多年来，几乎所有的变化都是增加。虽然我们会仔细考虑要将哪些功能集成到 VS Code 中，但随着时间的推移，新功能的增加不可避免地增加了我们发布的代码量。
然而，我们发现代码大小的增加会导致性能下降。例如，八年前的 VS Code 核心 JavaScript 文件 "workbench.js" 的大小是现在的四倍。当考虑到八年前的 VS Code 缺少现在许多人认为是必需的功能，比如编辑器标签或内置终端时，这种增加可能并不那么可怕，但也不容忽视。
名称混淆的概念
为了减小 JavaScript 代码的大小，我们考虑使用名称混淆技术。名称混淆是指将代码中的长标识符名称（如变量名或函数名）替换为更短的名称，以减小代码文件的大小。在 JavaScript 中，代码以源文本的形式传输，因此减小标识符名称的长度实际上会减小程序的大小。虽然在编译语言中，这种优化可能显得有点荒谬，但在 JavaScript 的世界中，我们非常愿意接受这样的改进。
然而，名称混淆也需要谨慎使用。如果一个潜在的优化使你的源代码变得不易读或不易维护，或者需要大量手动工作，那么除非它能够带来真正显著的改进，否则几乎不值得使用。因此，我们需要寻找一种方式，能够在不引入太多风险或额外工程工作的情况下，实现这种优化。
解决方案：名称混淆私有属性
为了减小代码的大小，我们首先考虑混淆私有属性的名称。按照惯例，私有属性的名称通常以下划线 "_" 开头。我们认为私有属性的名称可以安全地进行混淆，而且在类外部的代码不会受到影响。然而，很快我们发现，在一些情况下，子类可能会将继承的受保护属性公开。虽然这可能是错误的，但在实际代码库中，有时候我们需要禁用名称混淆。
由于 TypeScript 中的 "private" 关键字在编译到 JavaScript 时基本上被移除，这就意味着不能阻止位于类外部的代码访问私有属性。因此，我们必须谨慎更改属性名称，以避免在对象扩展、序列化和不同类共享相同属性名称时引发问题。
使用 TypeScript 确保安全
为了提高对混淆构建的信心，我们决定使用 TypeScript 进行验证。与其将混淆应用于编译后的 JavaScript 代码，我们可以将混淆应用于 TypeScript 源代码，然后使用 TypeScript 编译器编译带有混淆标识符名称的新 TypeScript 代码。这一编译步骤将大大提高我们的信心，因为它可以确保我们没有意外破坏我们的代码。
此外，使用 TypeScript，我们可以真正找到所有的私有属性，而不仅仅是那些以 "_" 开头的属性。我们甚至可以使用 TypeScript 的重命名功能来智能地重命名符号，而不会以不符合预期的方式更改对象的形状。
结
果和进一步工作
经过努力，我们成功地实现了混淆私有属性的构建步骤。这一步骤将 VS Code 的主要 "workbench.js" 脚本的大小从 12.3 MB 减小到 10.6 MB，减小了近 14%。这也加快了代码加载速度，因为需要扫描的源代码更少了。这对于几乎没有额外工程工作的优化来说，效果不错。
在混淆私有属性之后，我们继续思考其他潜在的优化机会。我们发现可以使用相同的方法来混淆导出的符号名称，只要这些导出仅在内部使用。这个工作在上一次迭代中完成，进一步减小了 "workbench.js" 的大小，从 10.6 MB 减小到 9.8 MB。总的来说，通过混淆，这个文件现在比不使用混淆时小了 20%。在整个 VS Code 项目中，混淆删除了 3.9 MB 的 JavaScript 代码。这不仅减小了下载和安装的大小，还减少了每次启动 VS Code 时需要扫描的 JavaScript 代码量。
结论
通过名称混淆技术，我们成功地减小了 Visual Studio Code 的 JavaScript 代码的大小，提高了性能，减少了下载和存储的开销。这项工作展示了如何在不进行大规模代码更改或昂贵的重写的情况下，通过识别潜在的优化机会，以及谨慎地进行优化，可以在 VS Code 中找到显著的改进。
优化是一个持续不断的过程，而不是一次性的事情。通过持续监测代码大小，我们能够意识到多年来代码的增长。这种意识无疑有助于阻止代码大小的进一步扩大，并鼓励我们不断寻找改进的机会。虽然名称混淆在一开始看起来可能是一种有吸引力的技术，但在深入研究之前，它几乎不可能被认真考虑。只有在我们努力降低风险、创建正确的安全保障和使采用名称混淆的成本几乎为零的情况下，我们才最终有足够的信心在我们的构建中启用它。
我为最终的结果感到非常自豪，也为我们达到这个结果的方式感到自豪。
关键词：
