如题,我之前使用1.4.1 beta版本构建一直没问题。使用1.4.2正式版构建后出现了许多新文件,而且许多旧的文件也不见了导致无法差异化提交。如图所示，而且我看了下setting.js文件也变得比之前更大了。
我之前已经发过一次贴了,可是官方的人员都不看的,可以麻烦关注下么？@Jare
我看了下setting.js 发现
一个小图对应d524ccf5-6cb2-42be-8681-28ee4090ae8f,然后新版本加了一个蛋疼的转换,又为这个uid加了一个
这样的一个对应的key？你这是为什么？这样做不仅大大增加了js的体积，还多了很多的文件。有什么作用?@Jare
用了新版本打包后变成
settings 的体积，一直都有计划进行压缩。不过优先级不是很高因为印象中你是第一个吐槽的。
至于你说的多出的新文件，缺少了旧文件，这些不都是引擎实现上的问题吗？你似乎不应该太在乎这个。
你应该关注的是构建出来后，文件总数是否变多？文件总体积变大多少？引擎运行时效果对不对？
这个是因为 1.4 默认勾选了内联所有 SpriteFrame。理论上这个 SpriteFrame 不应该创建出独立的 json 了。但是这个 SpriteFrame 又存在于 resources 下，有可能被你用 loadRes 单独加载。所以还是要生成一个独立的包，这个包只包含一个 SpriteFrame，这个包仅仅在 loadRes 时会加载到。
你没看么，我说的问题都是构建出来的。setting.js变大了
你的意思是我不要勾选内联就ok了？
settings.js 变大是变大了，不过总包体增大的比例应该不会超过 1%，代价是换来了文件数量的大幅度减少。这是预期之中的结果，内联 SpriteFrame 这个选项上的 tooltip 也有说明了这一点。
如果你不想要这笔交易，可以在构建时不要勾选 内联 SpriteFrame。
内联spriteFrame是把散图合并了是吧，也就是说如果本身没有散图的话，这个操作其实是没有意义的对吧
是把精灵帧合并，而不是把纹理合并。这个操作不论是否把纹理合并成图集都有意义。
你可以对比下加载场景时的网络请求数量。差别应该是很明显的。
嗯。。。我有时间试试，不过对我来说.setting.js是比较大的瓶颈对于初次加载来说。这个setting.js由原来的1.6m升到2.4m还是无法接受。
这个应该是因为你 resources 下的精灵帧太多了。记住 loadRes 用不到的任何资源都不要放在 resources 下。
可惜都是要loadRes，其实稍微大点的项目用那么多精灵帧是完全正常的。
好的我们会尽快压缩 settings.js
麻烦了。。。