这本本来是我做小游戏的时候做的逻辑。
服务器端和客户端使用同样的js加密库会相对方便的多。
这崩溃说明运行个存JS的代码崩溃啦，这个问题比较严重。
求官方修复6！
求官方修复7！
出 1.10.2 了, 你试了吗?
依然崩溃啊
我没用过这个，不过我用的其他的 md5 base64 eextea等，没出现过崩溃···
你就不能换个？
大兄弟，你那个问题解决了嘛，使用cryptojs库闪退的问题，我也遇到了，花了我好几天的时间，我一直以为是cocos creator的版本太高弄出来的，没有想到用回1.9.3也是这样，后来我看到你的帖子就试着去掉加密，果然不出问题了
，有没有解决方案啊
可以用 2.x 搞一个 demo 看能复现这个问题不, 如果可以的话官方应该会重视起来.
喜讯, 我可能找到了解决方案, 正如官方的另一个帖子中的回复:
https://forum.cocos.com/t/fatal-signal-4-sigill-at-0x0000098c-code-0-thread-2475-thread-103-android/64713/2
我把这几个都勾上后就再没有崩溃了, 原来是点两下就崩溃, 我再观察几天看看.
额，这个勾上的话会导致包体积很大的，没必要，我找到了一个解决方案就是不要用crypto库，使用网上其他js实现的的aes加解密就好了，这个纯粹跟库有关系，不用就好了哈！反正我的现在是没有问题了~~
这个也可, 太牛逼了, 你用的那个库? 求指教.
我之前说的那个方案果然还是有坑, 在 Processor : ARMv7 Processor rev 0 (v7l) Android 机器上还是会崩溃!
日志:
02-23 15:33:49.716 18595-18657/com.xxx.xxx D/WebSocket.cpp: Safely done, msg(4)! 02-23 15:33:49.716 18595-18657/com.xxx.xxx D/WebSocket.cpp: msg(4) append: 0 + 128 = 128 02-23 15:33:49.716 18595-18657/com.xxx.xxx D/WebSocket.cpp: msg(4) was totally sent! 02-23 15:33:49.716 18595-18657/com.xxx.xxx D/WebSocket.cpp: ----------------------------------------------------------- 02-23 15:33:49.931 18595-18657/com.xxx.xxx D/WebSocket.cpp: Receiving data:index:3, len=448 02-23 15:33:49.941 18595-18623/com.xxx.xxx D/WebSocket.cpp: Notify data len 448 to Cocos thread. 02-23 15:33:49.946 18595-18623/com.xxx.xxx A/libc: Fatal signal 7 (SIGBUS) at 0x00000000 (code=128), thread 18623 (Thread-1596) 02-23 15:33:49.946 18595-18623/com.xxx.xxx A/libc: Unable to open connection to debuggerd: Connection refused`
@1156566038 我尝试换了一个 aes 的加密库 forge , 还是会崩溃, 能否告知你用的那个库呢 ?
@1998or2000 楼主解决这个问题了吗?
虽然也有其他方法绕过这个问题, 但始终如鲠在喉, 也希望官方人员能关注下这个问题.
升级版本到 v2.0.9，没有这个bug啦
1.0.2 我在收到 socket 消息时延时一帧分发处理也没有问题了.
private _onMessage(event: ISocketEvent) {
if (this.checkDelegate() && this.mDelegate.ondata) {
setTimeout(() => {
this.mDelegate.ondata(event.data, this);
}, 0);
}
}
应该是 WebSocket 的坑, 没有在 OpenGL 线程上分发什么嘚问题.
我之前遇到的不是，就是内存中解密就会不崩溃