本文转载于:http://blog.csdn.net/wade333777/article/details/51424087
一、为什么要做这么一个错误输出台?
事发起因:
策划A:今天晚上要出个热更包,明天10点热更一下,小改点东西,应该没什么大问题。
程序A:ok,马上。
【大约10分钟后】
程序A:我X,不行啊,报错了!
策划A:能查看一下错误日志吗?
程序A:这个游戏包是IOS很早就打出来的包,貌似并不能查看错误日志。
程序B:手动排查吧
【晚上12点后】
程序A:哎,终于找到原因了,原来是。。。
事发分析:
出现错误并不可怕,可怕的是对错误一无所知,不知道错误发生的起因。如果在错误发生时能够将错误及时展现出来,这样就能够最快的分析问题,解决问题。现在游戏测试的流程也是,测试测出游戏问题后,需要先拿着真机给程序看,然后程序模拟BUG的出现方式,出现后再修改,出不来,就只能等着下次碰巧出现。
事发总结:
现在需要一个错误输出台,当游戏出现BUG后,这个输出台能够及时的弹出,然后测试人员只需要截屏,然后发送给程序,就能够最快的获取到BUG信息,尽快的解决问题。
二、手动起来
因为cocos-js底层是通过spidermonkey提供对js的支持,所以就去查看一下spidermonkey,对于蜘蛛猴的介绍和使用,网上有很多资料,最近我也是在学习这块资料,
最终,我们在ScriptingCore.cpp
这个文件中找到了
JS_SetErrorReporter(_cx, ScriptingCore::reportError);
这么一行代码,网上查了下,确实是错误输出的地方,然后进到reportError这个方法中,
void ScriptingCore::reportError(JSContext *cx, const char *message, JSErrorReport *report)
{
//-----------------------------wade-----------------------------//
js_log("▄︻┻═┳一 龙︻▆▇◤ ︻Q▅▆▇◤ ︻1▅▆▇◤ ︻ф▅▅▆▇◤ o︻0▅▆▇◤ v︻▅▆▇◤");
char* __log = (char *)calloc(sizeof(char), MAX_LOG_LENGTH+1);
sprintf(__log,"file--->%s ||| line--->%u ||| info--->%s",
report->filename ? report->filename : "<no filename=\"filename\">",
(unsigned int) report->lineno,
message);
js_log(__log);
js_log("▄︻┻═┳一 ︻7▅▆▇◤ ︻╃▅▆▇◤ ━━━X▅▆▇◤ ︻AS▅▆▇◤ s︻b▅▆▇◤ ︻v▅▆▇◤");
//取消掉JS出错的异常(!这句如果不调用,那么,下面C++调用JS的时候会一直报之前的异常,引发递归问题)
JS_ClearPendingException(cx);
//c++调用js代码,在js中定义了gReportError这么个方法,出错的时候会调用,并传参__log
char* char_content = (char *)calloc(sizeof(char), MAX_LOG_LENGTH+1);
sprintf(char_content,"gReportError('%s')",__log);
ScriptingCore::getInstance()->evalString(char_content);
}
三、效果演示
四、后期改善
游戏中出错了,可以及时发现,但是只有在debug开关为true时才能呈现出来,而正式的上线包这个开关是false的,所以当玩家发现错误的时候还是不能及时发现,还是需要程序模拟线上环境,然后发现问题,才能解决问题。
我们就想这个开关能不能手动打开,所以就想到了输入框,当我们在输入框中输入一段特殊的口令时,这时dubug开关就打开,然后就可以查看错误了,我们想到了我们的激活码输入框,这样我们的错误输出台就算在线上正式环境上也可以显示出来啦!