有时候一张图集里会放一些小的动画帧，碎图比较多，用texturePacker输出plist，这个plist文件里面都是些重复字段名，导致比较大，官方有没有打算优化这个问题
比如在打包的时候自动转换下格式，去除多余字段
同样一张图集，.plist是278k，如果用texturePacker输出EaselJS/CreateJS格式的json，大小仅为23k
可见优化一下效果还是很明显的，特别是这种文件都是要被json或者xml解析的，缩小的不仅仅是文件读取和下载的时间，还能减少解析时候的cpu占用
换个思路 你把XML自己预解析成另外一种格式 然后程序中读取
倒是已经这么干了，但还是想官方支持
cocos 编辑器构建时已经把 plist 转成 json 格式了吧. (然而体积似乎比 plist 更大…每个帧成员都要生成一个 spriteFrame 信息)
不过 json 合并后应该可以接受, 因为大部分字段的值相同, 压缩时会被共用.
感觉对这个问题彻底优化下，会对在小游戏平台的游戏提升很大的启动性能
嗯?能说得详细一些吗?
你看看引擎怎么干的
public parsePlist (file: string, options: IDownloadParseOptions, onComplete: CompleteCallback) {
let err: Error | null = null;
const result = plistParser.parse(file);
if (!result) { err = new Error(‘parse failed’); }
onComplete(err, result);
}
修改这个地方的流程，先自己解析出来还原成xml,再传给plistParser.parse
引擎只关心有没有这个功能能不能跑 优化是开发者的事 论坛里很多说优化的方案 引擎基本不语！只有影响到没法玩了他们才会去优化
自带的自动图集不香吗
肯定是不香嘛，不太好搞多纹理
图集导入后就都拆分成引擎运行时用的 SpriteFrame 了，而且构建的时候会进一步压缩。
因此图集大小请以构建后为准，项目里面的没有参考价值。
引擎要集成某种特性，至少要满足以下条件：
必要性：
比如楼主说的这个方案，引擎本来就不是用 plist，所以没有优化必要。
可行性：
有实际数据对比，知道性能在什么平台、什么机型、什么项目里面获得多少提升。对大多数平台、大多数品类的游戏都有提升。指标全面，不是只有单项指标上升（比如 DrawCall），而是整体性能提升。稳定性可靠，可以大规模推广。
通用性：
引擎是一个完整产品，优化方案要能具备跨平台的可能性，解决方案能覆盖到引擎的各个模块。而不是针对部分组件能有效果，其它组件没效果。如果方案不具备通用性，那引擎的实现将会四分五裂，平台差异扩大到一定程度将变成代码的
山，无能力长远维护。
可用性：
方案必须有一定的可行性、易用性，文档能写得清楚，使用成本低，如果会带来很多新问题的话我们将无法承担相应的技术支持成本。
一个东西要做出来不难，难的是产品化、商用化。
说白了，今天自研引擎跟商业引擎的竞争，不在一个维度上。商业化产品靠的是成熟度、完整度、编辑器体验和生态，去 PK 各个大厂的自研引擎。商业引擎要考虑到全面发展，确实没办法像自研引擎那样针对各个项目进行深度定制和裁剪。所以如果单论具体的性能、包体、某些渲染特效、迭代速度，商业产品和自研引擎肯定是会有差距的。实际上大厂即便使用了商业引擎，往往也需要对其进行深度定制，有些项目甚至改得妈都不认得。
所以引擎才有开源的必要，一个易扩展、易定制的底层至少提供了可能性，不会成为特定项目的阻碍。
不符合上面一些特性，比如某些黑科技很实用但是并不能保证全平台通用，能通过插件的方式去扩展一下吗，不集成到引擎中
感谢大佬,我去试试
该主题在最后一个回复创建后14天后自动关闭。不再允许新的回复。
