呵呵，说话不要这么冲。 你如果觉得这是问题，那你完全可以不把这些资源用cocos管理，把资源放到随便一个web服务器上，远程加载，自己解析plist，动态生成spriteframe
发布并没有解决本地调试的问题
不好意思，这对我来说就是个问题，我使用creator就是看中资源管理的便捷，如果还要每次更改都要把资源上传到远程服务器，这样我觉得不是一个好的解决方案
我感觉问题所在的原因是 在没有打包的情况下 可能会对JSON文件进行频繁的修改 如果早在编辑器里面和在一起 你可以想象一下 实时处理一个巨大的JSON文件对性能还是挺有影响的 可能会造成编辑器卡顿 你这个8秒也不慢 现在我跟服务器通讯和读取本地JSON表起码10秒往上走 只能通过一些加载动画在后台偷偷的读取JSON表
你的图集有多大，什么样的，能不能优化结构等等
有可能是你的使用姿势不对，要么就发个重现demo，让别人帮你看看
就是没有合并请求的原因 其实这些图片应该是动态加载的 如果一次性全部加载完压力确实很大 就算合并了JSON 下载图片也得很久 初次加载体验极差
图片本身不大，数量比较多，1000+的小图片。使用TexturePacker生成了5个plist合集，开发环境下creator会把plist分散成一个个的json。这就导致即使调试一个单个小场景也要通过http发送总共2000+的请求。刚刚有同学提到js也是单个文件，这样方便调试可以理解，但是把plist分散成一堆小json，这样并看不出有什么方便的地方，
你这好几千个的图片，都是同时摆放到场景里显示的吗
是的，都是一些独立的小动画。在同一个场景里随机显示
一个小动画打一个plist动画，单个动画做成一个预制
随机显示用代码动态加载
尝试过。预制并不能阻止引擎去把plist分散成一个个json
纠结那个json也改变不了什么，谁让你图多，还不能放远程服务器上呢
哎，难道没有引擎团队给个合理的解释或者解决方案吗
理解一下都不容易，PS里面图太多还卡呢，手机东西多还运行卡呢
你都这么大的项目了还在乎那七八秒，这让c++的看了都羡慕死了
确实构建后加载速度会变快了，做的消消乐么
你好，我们目前发布微信小游戏也遇到了这种问题。策划们接受不了用到的时候加载，放在loading里时间又长，我们发现也是巨量的json在请求下载。请问您最后是如何解决的，或者有没有替代方案？
非常抱歉，这是引擎本身机制的问题。这个问题仅在预览的时候会发生，之后我们会优化这种情况下的预览性能的。
1赞
微信小游戏，我在动态加载(loader.loadres) resource目录下的 plist(atlas spriteFrame)，发布版也出现了在下载大量的json，这个是用法不对吗？
很老的版本才会这样