gwt - 在生产中使用 ？

Question

据我了解，与 collapse-all-properties在 gwt.xml 中，编译器为所有浏览器生成一种排列。生成的文件要大 15% 到 20%。

除了文件大小增加之外，还有其他原因为什么我不应该使用 collapse-all-properties用于生产？

例如，它是否剥离了依赖于浏览器的逻辑和 css，从而导致应用程序可能工作和/或看起来与使用默认排列编译时不同？

在我的应用程序中，我注意到 cache.js 的大小增加了大约 100KB，并且所有 deferredJs 文件的增加 50KB 与 collapse-all-properties 相结合。 .

但是当与 gzip、代码拆分和缓存结合使用时，与显着的快速编译时间和一般易用性相比，较小文件大小的好处似乎微不足道。

让我想知道我是否可以将它用于生产。

Answer 1

除了您已经说明的原因之外，您没有理由不能在生产中使用它，并且如果您希望大多数用户通常会使用填充的缓存(应用程序不会经常更改，并且大多数用户会提出应用程序频繁)，那么您是正确的，尺寸点意义不大。将大型 JS 应用程序加载到内存中并构建所有必需的方法仍然存在成本，但我怀疑与从服务器加载额外的 100kb 相比，这没有意义。

我不相信折叠所有属性本身会禁用您的分割点(deferredJs 文件)，或者我可能误解了您说分割点增加了大约 50kb。

如果您希望用户在其上运行应用程序的最低功耗机器上的性能似乎可以接受，我不会担心 - 无需针对不真正适用于您的情况进行优化。

我会有点担心额外的语言环境(尤其是当新图像用于不同的语言环境时)和基于“外形”的属性(可能希望以构建时间为代价保持移动设备/平板电脑的快速运行)。我还会考虑禁用未使用的浏览器 - 虽然大多数现代浏览器只收敛于少数必需的实现，但旧浏览器仍然存在，它们需要额外的代码和其他方法来处理 clientbundle 等功能(不能将图像内联到数据 url 中) )。如果您能够从您的应用程序中删除这些浏览器，您可能会恢复所看到的大量增加。

在 GWT 的总体路线图中已经讨论过完全删除排列，因为它们主要是从每个浏览器的行为与其他浏览器的行为非常不同的时代遗留下来的，但是虽然我们仍然支持 IE8/9，但这将是困难的。 future 的仅支持现代浏览器的 GWT 可能会完全抛弃排列，并鼓励以不同的方式解决诸如语言环境之类的问题。