ios webview崩溃

Creator 3.x
#1

creator3.8构建的web H5做游戏大厅 使用webview去加载别的H5游戏，很大概率出现页面重载，看起来是内存过高导致强制刷新
如果有旋转或重置设计分辨率view.setDesignResolutionSize那么必定崩溃
各位大佬有什么解决方案么

#2

第一,内存过高,必崩.
第二,尝试优化资源,以前我有一款,都是散图,蹦了.改成图集,没崩.(其实就是内存过高导致的)
先关注一下内存问题吧.

#3

大厅部分我们能自己控制 但是web有部分是接入的别人的 不能控制

#4

让AI搞了一版出来 大致重点就是子页面的渲染尺寸异常偏大导致webgl崩溃
重点就是：

问题根因

  • 崩溃不是第三方 H5 单独打不开，也不是大厅资源没释放导致的。
  • 真正问题是父 Cocos H5 页面里再打开一个 WebGL H5 游戏时，子 iframe 拿到的渲染尺寸异常偏大。
  • 子页面尺寸再叠加 window.devicePixelRatio 后，实际 WebGL 后台渲染面被放大很多。
  • 移动端浏览器承受不了，触发：
    • WebGL context lost
    • CONTEXT_LOST_WEBGL
    • Out of memory
    • Page crashed
    • 页面强制刷新

排除项

  • 已释放大厅远程图片、远程 Spine、动态合图、未使用资源。
  • 释放后父工程资源占用已经明显下降。
  • 所以主要矛盾不是资源缓存残留，而是子 WebGL 初始化时渲染面过大。

最终处理

  • H5 浏览器环境不再使用 Cocos 的 cc.WebView 。
  • 改为 GameWeb 自己创建 DOM iframe。
  • iframe 尺寸不直接使用异常的父页面视口。
  • 根据手机本身尺寸和 window.devicePixelRatio 限制 iframe 实际大小，避免子游戏 WebGL 后台 buffer 过大。

核心结论

  • 这次 WebGL 崩溃的关键是： 子 H5 游戏在 iframe 中初始化 WebGL 时拿到了过大的渲染尺寸，导致移动端 GPU/内存超限。
  • 改成自建 iframe 后，可以绕开 Cocos cc.WebView 的尺寸链路，并主动控制子页面 WebGL 初始化尺寸。