我没深入研究mp不懂。如果你都找不到详尽资料，cocos的人一样找不到。用户少、讨论少，厂家支持也少，说明可能会有无数暗坑需要引擎组或者开发者填。码畜35就要退休了，何必呢
等你推广的时候，或者妹子邀请你进入她 的游戏对局的时候，你就知道秒插入跟30秒的体验差别了
还推广，都快死掉了。
好好的一个建议贴。。。让你们搞的。。。都不会学着客气点是么。。。
2赞
没一点优势？？ 那你快换。
扯远了，我只是想表达一个观点，cocos 生成产物还有很大的压缩空间，性能优化空间。 至于用什么样的技术手段来压榨这个空间，欢迎大家来喷。
我只是提供了一点思路做引子，技术有限，眼界有限，考虑问题没有那多条框，也可能很幼稚。各位不喜勿扰。
我不知道引擎组能不能找到，或者自己测试，只是提建议而已，实现与否是引擎组的决定。
像早几年就建议引擎组在fileutils中加个追加写的方法，引擎组愣是不加，也没人说啥啊
json会有流量/内存，跟json解析的时间消耗问题, 这优化过Cocos Creator游戏的人大概都遇过吧? 因为这个问题是解决不了的(除非换引擎), 所以只好找些奇怪的方法,希望用户不会因为这些等待时间而流失掉…
说真的也不求引擎组去改什么, 只希望能开放些接口或方法, 让我们有机会自己处理读取资源就够好了, 引擎组也有他们的难处, 也不是想改就改. 最好的技术不一定比上了一段时间而且稳定的技术好.
至于生气倒不必, 真受不了换引擎不就没这问题了吗? 没了盲肠就不会得盲肠炎…
臣附议
谢谢反馈，其实现在都支持 gzip 了，这个服务端一行配置的事情，所有浏览器都支持。这就没必要 Cocos 做了吧？你用 js 写的二进制解析代码，效率能高过浏览器自带的 C++ 实现？
你说微信小游戏不支持 gzip？人家微信小游戏有自己的压缩格式，wxpk，效果一样的。
另外，原生游戏咋办？现在的移动端的应用本身就是压缩包了，虽然压缩比可能没有自己 zip 好，但是效果也大同小异。Cocos 没必要造这个轮子。
不是的，项目构建后，这些 json 会尽量合并的。如果你发现文件过多，那是因为你都放在了 resources 目录下，挪出来就好了。
如果对编辑器默认合并 json 的结果不满意，我们会在 2.3 提供更强力的 json 合并参数的。到时候你想把所有 json 合成一个都可以的。
2赞
我们现在就是在cdn及源服务器都提供了gzip压缩传输。
但比较诡异的是，本地没缓存，第一次请求的时候，gzip并不生效。。。。
有缓存后就生效了。。。
那么问题来了，2.3啥时候出来
恩。了解。我是想说把产物中的res 目录整个做一次gzip 压缩。而不是对单个文件进行压缩。 这样既达到压缩包体的目的，同时又能减小网络请求数据数量。
我有看到一个页游是这样子搞的。还是个3D的，瞬间就加载完成可以开始战斗了，抓包看了一下，他是保留了一个简单的闪屏场景，然后只有一个600K的 zip资源下载。整个大小还没有cc引擎文件大。但是游戏内容还丰富的很。
自发光材质什么时候支持？
有不同意见没啥不好的。
2.2 已经支持环境光（全局光）
1赞
我提供一下优化json文件数量的方法，动态加载的图片大部分是不需要裁剪的，spriteFrame可以根据下载的Texture的大小创建，这些图片放在一个web资源服务器上，不放在项目resources文件夹里面
重点提醒：发布小游戏，网页游戏等，web服务器或者cdn一定要开gzip压缩
2赞