Cocos 游戏优化建议

Creator 2.x
#1

Cocos 有没有考虑过用更高效的存储格式去存储场景资源文件，而不是用json。
json冗余内容太多，资源文件大多都是json，无形中浪费太多流量/内存，以及json解析的时间消耗。
如果能用二进制格式比如flatbuffer这种读取完全不产生额外消耗的形式， 那么场景/预制体这些加载过程肯定会更加流畅。包体也相对减小很多。 比如一个预制体制作的可能比较大，生成的json文件达到1M, 此时json解析的消耗将会很明显，而如果用一些流行的二进制存储方案，避免解析消耗，仅有内存申请消耗，完全可以让界面加载更加流畅。

或者cocos 能够支持对 res 目录做整体gzip 压缩， 然后加载时仅请求一次网络，下载压缩包，并解压，而不是res目录里成千上百的散碎小文件，这个网络请求消耗肯定是比一次请求消耗大很多，也不稳定很多，有一个资源请求超时/失败时，游戏基本就卡屏崩溃了。类似facebook 小游戏打包形式，最终就是提交一个zip压缩包，然后运行时在前端做一次解压缩，现在解压缩效率很高，总会比请求网络下载快很多。 这样即节省网络流量消耗，又能加快首次显示效果。

目前这么多游戏引擎，没有一点竞争优势，搞的大家都有点选择困难症了，能否在一些细节上实现更高的要求，是你们长久活下去的根本，请认真考虑。

@linshun @fylz1125

4赞
#2

要么就收钱做个好引擎出来，要么就不做，做的还一大堆bug，搞得连提审都提不了，还要等官方回应这个是不是bug

#3

顶 确实需要考虑这方面了 总得有所突破

#4

支持用二进制，studio1.x用的json，2.x用的flatbuffer，不知道为啥creator又给改回去了……

#5

我还不知道cocos 以前有尝试过 二进制格式，也是刚入坑。
做小游戏稍微做重度一点就出现各种资源爆炸的情况，又无法从根本上解决问题。

#6

有可能是由于二进制格式无法做到 上下兼容，引擎升级会导致旧项目文件无法正常解析吧。

#7

是出过问题，coco2d-x3.14升级3.15（大概，确切的版本不记得了）的时候升级过flatbuffer的版本，但是studio在3.10后就已经停止更新了。导致好多项目都没法升级，后来的版本又把flatbuffer的版本降了才解决的

但是讲道理，creator这种应该不会引擎和编辑器不同步升级吧，使用定制引擎的团队，兼容个二进制也不事吧

#8

赞:+1::+1::+1:

#9

你该 @jare 的，你@的两个人，一个不是开发人员，一个不是官方的……

#10

flatbuffer支不支持H5，靠不靠谱楼主研究过吗？微信、qq、vivo等平台有没有限制研究过吗？IOS/安卓/PC/MAC各平台支持到不到位研究过吗？

如果没研究过，就建议引擎换掉全平台最靠谱最常用的json，你是想挖坑？

如果用zip，我一个30MB的游戏，你得先下载完30MB再解压，首屏会比我下载4MB快？？？如果有更新，是下载整个30MB zip包？那跟不带热更新的native包有啥区别？这还是H5吗？这怎么节省流量？

如果是解压后单个文件根据md5更新，哥，你干脆别做H5吧。

我觉得你都没做过游戏。提建议之前，请认真考虑。

5赞
#11

二进制开发冲突不好处理。。。。。
不过倒时可以在构建的时候输出二进制文件，
开发依然使用json

1赞
#12

对的.编译生成的文件是二进制的即可. 同时生成产物 所有资源可以进行一次gzip压缩,只保留一个闪屏所需的场景和图片.

#13

1.大家只是建议，不是要求；
2.没人说要用flatbuffer，只是说以前引擎组用过，messagepack，protobuf这些你担心兼容的问题吗？
3.zip压缩不是压缩整个res，而是压缩imports，如果你告诉我你这个文件夹有30mb，我只能拜服。
4.戾气有点重啊……

#14

对呀，构建的时候加个选项多好

#15

2.flatbuffer是studio时代的选择，那时根本没考虑清楚H5。studio本身更是技术选型失败的典型，触控都扔掉了。所以以前用过，不代表正确。

messagapack在低端机浏览器有性能问题，你说我该担心吗？
protobuf在微信小游戏不兼容，要用指定老版本，你说我该担心吗？pb还有chrome的老爹谷歌背书呢。

二进制是好的，前提是保证各浏览器、native平台上的兼容和性能比json优秀。如果有，白鹭腊鸭、babylon、pixi早就跟进。

如果用了一个格式，过几个月发现头条不兼容、华为不兼容，到时又会有一篇“cocos游戏优化建议”：瞎折腾这些不靠谱的，用json多好？目前这么多游戏引擎，没有一点竞争优势。。。。

3.“或者cocos 能够支持对 res 目录做整体gzip 压缩”，摘抄楼主的话。如果你觉得我的理解是错的，我只能拜服。

4.这叫喷，不叫戾气。好好阅读楼主第二段话，你觉得有多少句话是对的？

3赞
#16

2.请教一下messagepack，我有找到文章说在低端浏览器下有性能问题，但是没有说明什么是低端浏览器？而且这个说法最早见于16年11月，今天是否还适用？不知道你是否是通过相同文章得出这个结论的，如果不是还请告知方法；
忘了微信了，protobuf确实不合适
3.你是对的，我理解错了，这么做确实不合适

#17

说的很有想法。
我只是遇到问题有感而发的贴子，首先我说我遇到的问题，包体大小超过30M, 已经脱离了小游戏的范畴，当我加载游戏需要等待超过1分钟的时候（移动流量网络）， 当我加载一个3M的人物格斗动作spine json需要忍受界面卡住10秒钟时， 我确实感到非常失望，然后愤然发帖，提出我的意见。
我没有做过考查，没有研究过他们已被证明过时的技术。只是以我的理解，期望能碰撞到更好的解决思路。我万不想相信Cocos 这么优秀的产品，却无法包体问题，却无法解决长时间加载解析的问题。解决不了别人的痛点，给不出理想的解决方案，难道真的如网上传唱的cocos 只适合做做小游戏，想要做大，做好游戏，只能去选择Laya,Unity等技术替代？
确实，如果我遇到的问题无法从官方得到答案，自己也没有能力解决的时候，就是我抛弃Cocos的时候。

再来说问题的解决方案：
包体问题： 一方面cocos 编译产物里充斥着大量的json文本，平均每个json 1K-几M 不等。对于磁盘来说，最低效的存储就是小文件存储及读写。不管cocos 以什么样的存储形式管理其开发工程，但我只期望生成产物能够尽量精简，类似json这种内容，一般的压缩比率可以达到1/10。 明明一个30M的包可能减小到10M,5M， 却以技术难实现为由迟迟没有解决方案。
不管是二进制格式，还是什么三进制格式，我们开发者只希望内容尽量的小，解析足够的快。实际遇到的问题已然证明json并非最优解，却大谈什么兼容问题。 上层的数据处理跟什么平台的兼容问题有多少关系？难道选用二进制后，CPU就无法正确解析处理了吗？
再说压缩资源？ 如果cocos的生成产物无法压缩打包，或者压缩比不高，那算我没说。 但实际证明，当我手工将一个3M的骨骼动画的json文件压缩到160K 的时候，我不觉得我的想法有什么问题。
同时，对于资源请求来说，并发请求上千个文件，跟只请求一个zip文件，如果你判断不出来哪个对于玩家更友好，对于游戏体验更友好，那也算我白说。
通过压缩资源达到降低网络流量，减少等待时间，降低千次请求出错概率等等一堆优点的情况下，你觉得我这是喷？

说白了，这叫懒，不愿思考，不愿改进，安于别人的方案无法自拔。谁喷谁愤自有人说。

1赞
#18

之前我们组做过spine的优化，其中一个就是在cocos-2d层，读取json改为读取二进制的方式，你可以去试试，但是小游戏就不清楚了

#19

第一你连回帖都不审题，也难怪你遇到问题都不思考。上面说我戾气，我说我这是喷，是我喷。

第二Laya也用Json，小文件比cocos还多，也是用的spine，你用啥替代啥？Unity在web就没造诣，你怎么替代？

你加载H5游戏要把所有资源先下载完？你异步下载资源界面要卡10秒？哥们儿，您先别对谁失望，我觉得你们入错行。

包体的问题，资源你可以自己zip压缩，可以整体压缩也可以分开压缩；就跟通讯的数据一样，你可以用protobuf压缩加密，但我喜欢LZstring压缩，你跟我们讲讲，cocos应该用哪种方案？还是说给出最基础的json，让项目自己选择？

你喜欢读进度先下载30MB的zip，我喜欢秒开游戏再按需加载，凭什么你觉得你的做法更友好？您看视频都是先下载完的吗？

如果你觉得“只是”上层处理，你更应该自己做而不是引擎做。Json你都自己压到160K了，你按自己需求打包成zip很难吗？

说白了，这叫懒，不愿思考，不愿改进，总幻想引擎满足你一切需求。

再给科普下Unity的AssetBundle怎么做的？Bundle可以整体一个300MB的包，也可以拆分上千个小包；你可以用它自带的压缩，也可以另外7zip压缩，不压缩也行。但不管哪种方案，请你自己写代码。

那cocos提供Json，让你自己写点代码，比unity不厚道了吗？:sleepy:

2赞
#20

我们游戏也有30多M，而且还要第一次把所有资源下载，但是首次整包加载也就30多秒吧。而且这种加载也只是用户第一次的加载，后面的更新就很快了。
:joy:

1赞