ios websocket电量占用太高【已查明为IOS本身问题】

3.3 不是修复了吗?

应该不是同一个问题,我们会跟进处理一下

但我实际测试是

中间一段是主动关闭websocket。
关闭后cpu占用5-6%,打开websocket17-18%(打开后,没发送,接收啥消息,就只有心跳包)

直接3倍开销。

测试版本3.3.2

看了官方用的libwebsocket.h是2.4.2版本。
当前最新都到4.3版本了。
是不是c库有什么bug

因为android平台上兼容性问题我们没有做版本升级, 实际上有过尝试.

你测试是只测native库(完全无js调用)还是依然从js调用及接收回调?

我从JS调用和接收引擎的
这有什么不一样

安卓已经修复了,将在 3.5 发布 https://github.com/cocos/cocos-engine/pull/10384
iOS 仍在跟进中,目前单独测试 SocketRocket 和 libwebsocket,跑 FB 的官方 demo 都有这个问题。我们会持续跟进。

反正就不是你们问题呗

感谢 Unity 用户的关心。
我只是披露一下现在的进展,让大家知道这帖没沉。

1赞

嗯嗯 :rofl: :rofl: :rofl:

我们进行了一系列的调研,比较了我们调用第三方库SocketRocket和其自身的demo的耗电量,以及其他websocket的实现。确认我们在调用SocketRocket时没有额外的电量损耗。CPU计算也是正常的。
cocos2.4.8


SocketRocket official demo

此外我们还对比了Unity和Unreal在Websocket功能上的ios耗电量,发现实际上ios本身网络通讯就是巨额电量开销。这一点可以参考 苹果官方文档https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/EnergyandNetworking.html

image

以及对于电量的记录https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/SignsofEnergyLeaks.html

Unity:


Unreal:

具体的调研可以在engine仓库issue里阅读。

3赞

鉴于目前的电量损耗是难以避免的,

  1. 我们推荐开发者降低网络通讯的频率,联机游戏的逻辑同步通常不需要 30fps,可以降低至 10fps。尽可能合并发送数据,将多个数据合并到一个包里发送。
  2. 优化数据包,因为实测数据包大小与网络硬件模块所消耗的电量是正比上升的,也推荐使用压缩数据来降低电量损耗。

感谢引擎组严谨的对比,已知晓。

大佬们 @genxium @jetmouse @ase7en 请关注上面调研结果

1赞

已知,感谢官方

那是不是可以不用websocket 消耗可以降低?

这个求证的态度实在是很不错。但我还是没被说服,如下

  1. websocket应该不属于high-overhead(The wire level overhead of WebSocket (compared to raw TCP) is between 2 octets (unmasked payload of length < 126 octets) and 14 octets (masked payload of length > 64k) per message – 摘自 https://stackoverflow.com/a/13044585 也可以从其他途径求证但这个数字和我记得的差不多量级)。

  2. "iOS本身网络通讯就是巨额电量开销“: 不认同或者你们需要更多证据,我的看法是SocketRocket的实现有问题而不是iOS的问题。既然你们调研了这么多,应该也知道ws是基于tcp实现,而操作系统一般只实现到Transport Layer,那么如果是iOS实现tcp有缺陷导致用30fps接受小体积消息时能耗很高,你们也需要额外的实验来证明这点(我大概搜了一下"iOS tcp high energy consumption"和"iOS tcp high CPU usage"并没有找到类似的说法)。在没有更多证据的情况下即便SocketRocket是一个受欢迎的ws库,但iOS的网络协议栈更令我放心 。

后面给出的两个建议都没有问题,非常认同。

实时联机的游戏,通常收发频率不需要到 30 fps,逻辑层跑个 10 fps 足够了,30 fps 已经达到了常规视频文件的帧率了。
就算客户端不用开销,服务端也没必要用 30 帧去跑,服务端开销可都是钱。
因此你这样的结论也无法证明 iOS 的网络协议是为 30 fps 设计的。
反而上面的截图里面,苹果官方文档也说明了这一点。

我们已经经过了很长时间的调研,也对比了两个友商提供的网络接口以及 Facebook 的官方 Demo。暂时没有人力再去深入挖掘为什么会是如此了。
如果各位有兴趣,欢迎自行写一个不包含任何引擎的 tcp 纯 iOS demo 来帮忙求证,感谢帮助。

是也不是。ios的overhead并不会因为数据发送量的大小而上升或下降,这一点有验证过,但它客观存在。具体可以看上面写的链接。并且它在xcode的profiler里被认知为高消耗。

研究过SocketRocket的源码,以及调用的CFNetwork源码,我自信我写不出比他更好的代码。 :rofl:

1赞

如果你说的overhead是指cellular and Wi-Fi radios, are powered down by default to conserve battery,并且对应你贴图中占60%~70%的部分,我注意到了,并且不改变上面的看法。

1赞