根据我的理解，在gwt.xml中使用ERROR: invalid input syntax for integer: "social"
LINE 3: social = t->'social'::int,
^
，编译器为所有浏览器生成一个排列。结果文件大15％到20％。
除了文件大小增加外，还有其他原因导致我不能使用integer进行制作吗？
例如，它是否剥离了与浏览器相关的逻辑和css，从而导致应用程序可能与使用默认排列编译时的工作和/或外观不同？
在我的应用程序中，我注意到cache.js大小增加了100KB，所有deferredJs文件与collapse-all-properties相比增加了50KB。
但是当与gzip，代码分割和缓存相结合时，与重要的快速编译时间和一般易用性相比，较小文件大小的好处似乎微不足道。
让我想知道我是否可以将它用于制作。
答案 0 :(得分：8)
除了您已经说过的原因之外，您没有理由不能在生产中使用它，并且如果您希望大多数用户通常使用填充的缓存来访问（应用程序没有＆＃39;经常更改，并且大多数用户经常调出应用程序），那么你的大小点意义不大是正确的。将大型JS应用程序加载到内存并构建所有必需的方法仍然需要花费，但我怀疑与从服务器加载额外的100kb相比，它没有意义。
我不相信崩溃所有属性本身会禁用你的分裂点（deferredJs文件），或者我误解了你说你的分裂点增加了大约50kb。
如果您希望用户运行应用程序的最低功耗计算机上的性能似乎可以接受，我不会担心 - 无需针对不适用于您的情况进行优化。
我会对其他区域设置（特别是当新图像用于不同的区域设置时）以及基于形状因子的属性（可能希望以构建为代价保持移动/平板电脑的速度）保持警惕次）。我还会考虑禁用未使用的浏览器 - 虽然大多数现代浏览器只集中在少数几个必需的实现上，但旧的浏览器仍需要额外的代码和其他方法来处理clientbundle等功能（无法将内嵌图像转换为数据网址）。如果您能够从应用程序中删除这些浏览器，则可能会恢复大量您所看到的增长。
在一般的GWT路线图中已经讨论过完全删除排列，因为它们在很大程度上是从每个浏览器的行为与其他浏览器表现非常不同的时候的延续，但是当我们仍然有IE8 / 9支持时，它将很难。未来的现代浏览器专用GWT可能会完全抛弃排列，并鼓励以不同的方式解决区域设置等问题。