三端【iOS、Android、web】行为表现不一致
有哪些在针对不同平台开发时
有什么需要额外注意的吗
1赞
“决定性” 一般要使用定点数数学库来实现， 符点数物理就是会存在多端不一致的问题。
依赖物理引擎吗？ 要的话改用rapier.js物理引擎吧， 算是h5最可靠的物理引擎了
神经病啊 
哈哈哈 那个也需要额外注意一下
其实也不光是物理引擎，就是方方面面
同一套代码，构建到不同的平台
代码的行为，时序，等等
不同的平台，得到的最终表现不一致
定位问题时也没有头绪
是本身引擎就是存在这些问题
需要针对不同平台不同实现
还是说构建、出包的过程中
某些行为会导致这种不一致性
如果是动画有表现上的差异(快慢) 我觉得是正常的， 像王者也会有相同的问题
关键在于数据的决定性的事件上
技能发动时机， 命中结算时机是依赖服务端逻辑帧第几帧到几帧之间的处理
像这种数据处理肯定是基于定点数进行运算
不是引擎存在这问题， 是本身浮点数都有这问题， 你用unity没有定点数库试试， 一様出现不同平台结果对不上。
如果你不同平台不同设备只想依赖自身update去处理决定性，那我想没有一款游戏引擎可以满足你，因为这是你从技术方案上已经有问题
没太明白
你的意思是，所有的这些都是基于浮点数机制的不同导致的差异吗
或者我说一说我实际遇到的一些问题
包括但不限于
1.组件的生命周期
2.资源的加载
3.渲染顺序
4.异步调用(promise,async,await)
等等这些，在我历来开发的项目中
或多或少会出现以上之中的一个
但也不是每个项目都会遇到
给我的感觉就像是，不容平台中，程序中运行时的时序，并不统一，也没有参考性
如果是因为不同平台中浮点数的处理机制的问题
有没有可供参考的处理方案
或在游戏设计过程中，该如何尽可能的避免或绕开，其造成的影响
- 组件生命周期 ， 资源加载跟平台与设备的I/O能力有关， 不同平台底层处理不一様， 但这在游戏项目开发中完全不是问题，这种I/O产生异步不同情况完全可以依赖项目在技术设计方案上去避开（如资源提前加载， 所有人都进场景后上报服务端， 服务端下发正式开始游戏)
- 你举列渲染顺序如何影响游戏？
- 浮点数问题是计算机基础知识，你可以自己上网查或GPT一下
- 至于不同平台有一点不同， 就是cc打包native后部分代码是由c++层托管执行，采用opengl渲染，所以某些在web平台正常运行在native不能运行
给我的感觉就像是，不容平台中，程序中运行时的时序，并不统一，也没有参考性
如果是因为不同平台中浮点数的处理机制的问题
每个平台底层不一様， 但这不重要， 关键是你应用层的表现是否一様， 用户之间同步是否致就可以
以上你要避开， 自己去看书， 做研究， webgl与opengl差别， android平台/ios平台app开发书籍
十分感谢，您的回答 
rapier.js无法在原生ios使用，会提示[WARN]: JS: WebAssembly is not supported!
养成查询h5 api 支持的版本
WebAssembly, 至少要ios 11 才能支持。 报错写WebAssembly no support ， 就是説你的浏览器不支持， window作用域下没有WebAssembly这东西。
我的是ios 16，但我不是用ios的浏览器打开游戏的，我是打包成ios原生的app和安卓原生的app，安卓原生的app在游戏里用v8引擎是能正常运行 rapier，但ios原生的引用的javascriptcore则不支持WebAssembly。我试过部署到web上在 ios的浏览器safri里打开是能正常运行rapier的。我想问一下你有试过直接把rapier打包成ios的原生app吗？
我负责的都是基于自家app的webview进行游戏， 但就算ios webview 也是使用了javascriptcore， 只要是ios 11以上都是能跑webassembly，因为jscore是在v11开始支持webassembly 1.0, 如果你是使用cocos 提供的打包原生后无法使用webassembly， 那你就要问问官方是否要采用另一种方式去实例webassembly, 如果确认自身的jscore能支持webassembly， 但运行时不行可以考虑像桥接一様在原生层注入Webassembly 方法到 window作用域下
CocosCreator 在iOS App上也是用的V8引擎驱动JS，V8引擎自带的WASM和TurboFan深度绑定关系，而TurboFan直接关联jit
但因为iOS审核限制限制了不能开启jit，所以TurboFan、v8的WASM都不能启用，也就是webassembly is undefined，这个其实有解决办法，静候佳音
iOS上面也是可以运行WASM，但只能在解释器模式下，苹果钦定的JavaScriptCore引擎，最新版本是带了一个WASM解释器
解释器模式运行，性能远低于JIT模式WASM
原来是这样，我想问一下，你说的有解决办法，是指什么办法，能简单说一下吗，我想去尝试一下。我目前想试的一个方法是看看能不能把rapier转成asm.js，就像cocos creator现在打包ios原生app如果box2d选用了wasm但实际打出来的是asm.js。这样起码rapier在能原生 ios用。但好像没找到有这样的案例
你的方法是指自行升级V8到12.X，然后改成非JIT模式？
是的，微软给v8贡献了一个解释器模式的WASM，可在非jit模式下运行，v8版本好像得12.x以上才有
是要加什么参数才能启用解释器模式的WASM？我看了引擎源码，它默认已经加了一个非jit的参数 flags.append(" --jitless");
然后我看原来cocos的开发者也编译了一个v8的12.6.228.49的版本出来
https://github.com/forkrp/test-v8/releases/tag/12.6.228.49-2
详细信息参考，我还没试过
[DrumBrake: a Wasm Interpreter for V8 - Google Docs]
(https://docs.google.com/document/d/1OIJ4Sv2XfTlI5NmTS1QI8v8wPL0LUT5s1W2D9OlJmMc/preview?tab=t.0#heading=h.2hff7nffvheq)
该文档中说明了在iOS的非JIT模式下开启WASM的性能对比