引擎版本:cocos creator 1.6.1 release
平台:ios native
系统版本:10.3.3 (14G60)
设备机型:iPhone 6s
频率:偶现
frameworks\cocos2d-x\cocos\platform\ios\CCDevice-ios.mm的488行
CGContextBeginTransparencyLayerWithRect(context, textRect, NULL);
能够引起这个宕机的,我估计是这个textRect过大或者其它参数非法问题造成的.
这个是第三方上报的,xcode里看到的crash也是这个位置,没有控制台log,我也不知道是哪个消息,目前只发生在一个设备上.
已经有了宕机位置,有了调用栈,应该看这些信息是可以解决的,而且定位到了这一行:
CGContextBeginTransparencyLayerWithRect(context, textRect, NULL);.
我们需要重现,所以需要你在 websocket 回调中的逻辑代码。
从调用栈看是 websocket 回调中对 label 做了操作触发的,跟参数校验什么的没关系,有可能是错误的时机访问了 CoreGraphics API
这个websocket收到消息是一个this.node.emit(msg_type + ‘_’ + msg_id, { msg: msgBuff.buffer });,没有LOG也没有js调用栈,定位不到是哪个消息发生的这个宕机,目前只有从代码本身去查,都用的事件机制驱动的,而且这个不是必现的,目前只有一个设备上出现这个问题,有出现过两次
你的 websocket onmessage 回调函数有很多处实现吗?onmessage 回调函数跟 node.emit 没关系,我不理解你说的意思
尝试复现一下吧。不然靠猜也不是个办法。
算了,我自己改吧.不是websocket的问题,websocket只是接收消息处理,服务发来的每个逻辑都经过这里的
如果这个问题能重现,早就解决了,1.6都测试这么久了,我都不会发这个贴.
碰到这种问题,我的解决方案都是:加入近乎变态的参数合法性检测.比如这里,考虑了返回的size<=0的情况,但没有考虑size过大的情况,我猜过大一样会宕机的:
CGSize realDimensions;
if (overflow == 2) {
realDimensions = _calculateShrinkedSizeForString(&stringWithAttributes, font, dimensions, enableWrap, shrinkFontSize);
} else {
realDimensions = _calculateStringSize(stringWithAttributes, font, &dimensions, enableWrap, overflow);
}
CC_BREAK_IF(realDimensions.width <= 0 || realDimensions.height <= 0);
if (dimensions.width <= 0) {
dimensions.width = realDimensions.width;
}
if (dimensions.height <= 0) {
dimensions.height = realDimensions.height;
}
那理论上只要触发了你游戏中最大的字号,最长的文字,就会出现崩溃才是。不应该是概率出现。
目前只能从代码这里去分析,游戏是最多字的时候只有用户协议,其实都试过了,不会宕机,现在只能分析代码质量去解决或者避免这个问题再发生.
// compute start point
CGFloat yPadding = _calculateTextDrawStartHeight(align, realDimensions, dimensions);
CGFloat xPadding = FontUtils::_calculateTextDrawStartWidth(align, realDimensions, dimensions);
NSInteger POTWide = dimensions.width;
NSInteger POTHigh = dimensions.height;
CGRect textRect = CGRectMake(xPadding, yPadding,
realDimensions.width,
realDimensions.height);
xPadding和yPadding计算如果结果有问题,这个textRect也可能会非法的.
