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