大型plist解析后被拆散，导致加载时间增加几十倍的问题

Creator 2.x
#17

你的图集有多大，什么样的，能不能优化结构等等
有可能是你的使用姿势不对，要么就发个重现demo，让别人帮你看看

#18

就是没有合并请求的原因 其实这些图片应该是动态加载的 如果一次性全部加载完压力确实很大 就算合并了JSON 下载图片也得很久 初次加载体验极差

#19

图片本身不大，数量比较多，1000+的小图片。使用TexturePacker生成了5个plist合集，开发环境下creator会把plist分散成一个个的json。这就导致即使调试一个单个小场景也要通过http发送总共2000+的请求。刚刚有同学提到js也是单个文件，这样方便调试可以理解，但是把plist分散成一堆小json，这样并看不出有什么方便的地方，

#20

你这好几千个的图片，都是同时摆放到场景里显示的吗

#21

是的，都是一些独立的小动画。在同一个场景里随机显示

#22

一个小动画打一个plist动画，单个动画做成一个预制
随机显示用代码动态加载

#23

尝试过。预制并不能阻止引擎去把plist分散成一个个json

#24

纠结那个json也改变不了什么，谁让你图多，还不能放远程服务器上呢

#25

哎，难道没有引擎团队给个合理的解释或者解决方案吗

#26

理解一下都不容易，PS里面图太多还卡呢，手机东西多还运行卡呢
你都这么大的项目了还在乎那七八秒，这让c++的看了都羡慕死了

#27

@jare 引擎开发大神，这个问题你们有什么解决方案吗；当原始plist文件过大时，通过HTTP加载的巨量json耗时太久了

#28

确实构建后加载速度会变快了，做的消消乐么

#29

你好，我们目前发布微信小游戏也遇到了这种问题。策划们接受不了用到的时候加载，放在loading里时间又长，我们发现也是巨量的json在请求下载。请问您最后是如何解决的，或者有没有替代方案？

#30

非常抱歉，这是引擎本身机制的问题。这个问题仅在预览的时候会发生，之后我们会优化这种情况下的预览性能的。

1赞
#31

微信小游戏，我在动态加载(loader.loadres) resource目录下的 plist(atlas spriteFrame)，发布版也出现了在下载大量的json，这个是用法不对吗？

#32

很老的版本才会这样

#33

目前的方案，就是把多个SpriteFrame资源通过组件引用， 然后做成 prefab。打包之后，引用的资源都会被打包到prefab 里，只需要加载 prefab就行了

#34

预览测试时, 加载了两个plist, 生成了大量json请求, 每次都要近十秒才能进游戏…
时间2002年

#35

能不能预览模式也优化, 一次调试要好久, 真是硬伤啊

#36

合并json