使用ccreator一年，这些坑未能解决

Creator 2.x
#1

使用ccreator一年，这些坑未能解决。希望一起交流，找出解决方案。

本人使用的版本是cocos 1.9.3。所以以下问题紧针对1.9.3以及之前版本。新版本一直未敢尝试。

问题如下：

一.热更新bug。

游戏上线差不多也7，8个月了。热更版本也有将近100多次。每次更新资源很多时，都会有几个用户（我们日活跃用户差不多4，5千人）出现热更失败的问题。用户操作方式未知，可能是热更的任一阶段切入后台，或者断网，或者结束进程。用户网络情况未知。
bug的现象就是，用户的脚本和资源版本不匹配。目前遇到的都是脚本是老版本，但是资源文件已经更新。这种bug影响最大，因为表现出来的现象都是无逻辑的，各种不可预知的bug。
对于这个问题，目前做的处理方式是，增加了一个一键修复的功能。就是删除掉热更路径和缓存路径，然后重新热更。
更好的解决方案：方案1.找到热更失败的根本原因。流程设计漏洞，或者别的问题导致的。（不是文件下载出错，我对下载完成的文件做了md5验证，问题依然存在）。
方案2：应用启动之后，做文件校验。来校验客户端资源是否完整，不完整就做相关修复。

（对比了cocos2dx-lite的github，assetsmanager有更新，同步之后等下次整包更新加上，看能否解决问题）

二.内存释放问题解决

性能和内存，依然是现在面临的最大瓶颈问题。新项目比较复杂，包含很多动画和特效。所以对性能和内存要求更高，所以要确定新项目是否继续用creator，就要看是否能够解决内存问题。以及龙骨等动画的释放问题。之前版本场景切换调用gc，会几率导致ios闪退，以及部分ios机型gc并不能释放ios内存。所以后面就放弃了主动调用gc。creator内存如何管理？希望有解决方案的前辈给出相关策略。

三，切入切出后台，ios小几率无法播放音乐音效。

四，底层cocos creator js报错问题。

现有项目收集了js代码的错误信息。发现里面有两个渲染底层的错误，会重复报错。是精灵渲染update里面的错误。
2019-04-01 00:23:41 --> userid=206225&file=3&line=1111&error=Uncaught TypeError: Cannot read property ‘setSpriteFrame’ of null&version=1.1.16&os=Android&stack=[0]_applySpriteFrame@src/jsb_polyfill.js:8114
[1]set@src/jsb_polyfill.js:7932
[2]sample@src/jsb_polyfill.js:410
[3]r@src/jsb_polyfill.js:604
[4]7.d.update@src/jsb_polyfill.js:656
[5]update@src/jsb_polyfill.js:534
2019-04-01 00:23:41 --> userid=206225&file=3&line=1111&error=Uncaught TypeError: Cannot read property ‘setInsetTop’ of null&version=1.1.16&os=Android&stack=[0]_applySpriteFrameInsets@src/jsb_polyfill.js:8081
[1]_applySpriteFrame@src/jsb_polyfill.js:8108
[2]set@src/jsb_polyfill.js:7932
[3]sample@src/jsb_polyfill.js:410
[4]r@src/jsb_polyfill.js:604
[5]7.d.update@src/jsb_polyfill.js:656
[6]update@src/jsb_polyfill.js:534
这种错误每天都会有很多上传到服务器里。但是我测试服同样收集错误日志，但从来没出现过。也查了js源码。找不到相关报错的原因。主要还是不熟悉creator源码框架。有解决的朋友希望能给出解决方案。

5赞
#2

热更新bug和底层cocos creator js报错问题真的是困扰了我很久的问题，从项目上线就一直存在，也一直未能修复。而且bug我和我们测试都无法重现。所以也没法从根本解决。希望有遇到相同的问题，并且解决了的大佬，不吝赐教。

#3

这种小概率的情况确实头疼

#4

@jare @BigBear

#5

战略性mark，坐等大佬回答

#6

希望引擎开发大佬能给出第四个问题相关的一些技术支持。这些报错真的很妨碍错误日志收集。

#7

战略mark

#8

Mark

#9

同问，mark

#10

Mark

#11

玩家有覆盖安装apk的情况吗，这种情况有没有删掉之前的热更缓存

#12

mark

#13

你这个底层js报错我猜是因为用了延时调用吧，延时调用很容易出现“对象已经destroy了但是仍然调用其函数”。
热更的bug？不好意思，我们根本不敢用热更，都是全打包。
龙骨动画的释放bug？我们是每个关卡之间都插入一个“加载动画关卡”隔开，而且勾上关卡的资源自动释放，不然native端100%会被龙骨动画卡死！

你这些还不是最麻烦的问题，最大的问题还是像我们做的项目一样，小游戏、apk、iso三端同时上架，而且项目不小，到处都弥漫着平台判断的代码，而且经常这平台能用那平台又不能用……
如果不是因为老大一开始要三端同步，肯定是首选unity做native，然后小游戏就用creator做个导量版的，现在做的确实是头疼……

#14

那小游戏的包，你们怎么放下的啊，就算是全部是代码也放不下吧

#15

素材放远程服务器啊

#16

回答一下第二个问题。
我们这边也遇到过这样的问题，采取了引用技术来处理
https://forum.cocos.com/t/topic/65743/56

其实1.x系列还有许多问题没有解决，希望引擎组精益求精，把2.x 和 1.x 都做好来。

#17

这两天被热更搞的冒火，正想开个帖子，刚好看到这个，就一起交流一下吧。
我的项目在于2.0.2版本。
热更问题：
1.更新慢
线上的更新包经历了40+次更新了，新用户基本等于更新一个整包。不过总大小才30+m所以体积不是问题。
问题在import文件夹，2000+的文件……
解决方案：将import打包成zip，所幸assetsManager会自动解压，所以实现很简单。只是我看官方文档还有论坛都没提这个事，是太基础了不用聊，还是有啥坑？
2.热更死循环
问题表现： 发现有新版本=》执行更新=》更新完成=》重启=》发现新版本=》。。。
偶发性的，一次热更下去可能就一个用户有这种现象，多出现在ios用户。
从表现来看，似乎是manifest没有更新，但是从源码来看，是先更新manifest再发送更新完成事件的，所以为何会出现这个死循环我一直想不通。
解决方案：在发现新版时，记录更新的文件数量，如果结束更新时文件数量为0，可以视为进入死循环，删掉更新文件夹再次执行热更。类似修复按钮，只是没有把使用权交给用户，不知道靠谱不，这种偶发性的简直了，测也没法测，不知道有啥其他办法没。
3.更新后界面混乱
同样是偶发性的，更新完成后个别用户界面一篇混乱，但是按钮功能啥的都正常……估计是描述文件下载过程中出错了
官方文档印证了这个判断

由于下载过程中仍然有小概率可能由于网络原因或其他网络库的问题导致下载的文件内容有问题

解决方案：setVerifyCallback老实验证md5吧。
不得不吐槽一下官方提供的示例，根本就没做验证，直接返回的true，我也就照着抄了……

#18

是啊，素材全放服务器。不过，包里全是代码，你们放得下啊？

#19

这些都处理的。如果是这样的问题，肯定不是某个玩家。而是全部玩家。我是在c++层记录和检测是否安装新版本的。如果安装新版本会把热更路径重置的。

#20

删除热更路径文件，是最好在js引擎启动之前处理的。这样才保证不会出现其他资源加载之后被删掉导致的闪退问题。