安卓机锁屏后再打开网页3D白屏，重开浏览器又正常，是不是上下文被系统收走了？

结论先说：安卓机锁屏或切后台后再打开网页3D白屏，重开浏览器又正常，多数不是模型面数太高，而是 WebGL 上下文被系统回收后没有做恢复。移动端在切后台、锁屏、来电、显存吃紧时都可能触发回收；页面只写了开始渲染，没监听 webglcontextlost 与 webglcontextrestored，回来就容易白屏。按 2026 年常见交付经验，排查顺序是：先看控制台有没有上下文丢失告警，再查贴图和几何有没有真正释放，再回到减面与压图。

先分清三种白屏，处理方向不一样

甲方口头说的白屏，在 2026 年交付里至少对应三种故障。混在一起查，常会白耗两三天。第一种是上下文整体丢失，画面连背景色都没有；第二种是上下文还在，但渲染循环停了，比如页面隐藏时停了 requestAnimationFrame 却没恢复；第三种是上下文回来了，资源没重建，模型轮廓在、贴图发黑或几何缺块。修复位置分别在事件监听、循环调度、资源重建，先定性再动手，比直接减模型省事。

• 全白或全黑、页面文字还在：优先怀疑上下文丢失或初始化失败。
• UI 正常、3D 区域静止：优先怀疑渲染循环没恢复或被节流。
• 模型轮廓在、颜色发黑发花：优先怀疑贴图和渲染目标没有重新上传。

安卓上上下文为什么容易被回收

WebGL 上下文由浏览器和 GPU 进程托管，网页不能完全掌控。系统为省电或回收内存，会在页面不可见时降频，甚至结束 GPU 进程；页面回到前台时拿到的是失效上下文。安卓机型后台策略差异大，同一份代码在 A 机型切十几秒没事，在 B 机型切两分钟就白，属于系统行为差异，不一定是前端写错。

• 切后台或锁屏时间偏长，常见几十秒到数分钟不等，因系统和机型而异。
• 来电、分屏、系统弹窗抢占前台，也可能触发回收。
• 同一页面存在多个 WebGL 画布时，超过设备可承受数量更容易失败。
• 在 App 内嵌 WebView 打开时，页面可能被整体回收，回来相当于重新加载。

复位做法：监听—清理—重建

把问题拆成三层，是因为责任主体不同：监听属于前端事件层，清理属于资源管理层，重建属于渲染管线层。只做其中一层，常出现「回来了但黑一下」「回来了但贴图丢了」的半恢复状态，验收反而更麻烦。

1. 监听：注册 webglcontextlost 并在回调里阻止默认行为，同时注册 webglcontextrestored；再用 visibilitychange 判断页面隐藏与恢复，隐藏时主动暂停渲染循环。
2. 清理：页面隐藏或上下文丢失时，暂停渲染循环与定时器，释放纹理、几何、渲染目标等 GPU 侧资源。清理要幂等，重复调用不能报错。
3. 重建：恢复时重新上传贴图、重编译着色器、重建渲染目标和相机比例，再恢复渲染循环；重建期间给占位或加载态，别让用户一直盯着白屏。

合格口径可以定得具体些：切后台 30 秒以上再回来，画面能自行恢复，黑屏或占位时长控制在 1 秒上下（经验区间）；连续切前后台 20 次不崩、不丢贴图、不出现半黑模型，才算过。

资源预算与三条路线对比

上下文丢失是运行时问题，但资源预算决定重建要多久、会不会重建失败。常见情况是：显存占用高的不是模型面数，而是贴图张数与渲染目标数量。2026 年交付中，贴图单张常见控制在 1K 到 2K，总张数和总显存占用比单张尺寸更关键；展示类模型常见控制在数十万三角面以内（经验区间），超出先做合并与减面。

• 纯前端 WebGL（Three.js / Babylon.js 一类）：包体可控，加载较快，修改灵活；上下文与资源管理要自己写，稳定性取决于前端规范程度。恢复改造经验区间常见 1 到 2 个工作日。
• 引擎导出 WebGL 包：画面和灯光表现较好，但包体常见偏大，内存占用也高，低端安卓机更容易触发上下文丢失。恢复加回归常见 3 到 5 个工作日。
• 云端像素流或云渲染：本地几乎不吃 GPU 资源，画面质量上限较高；但对网络稳定性和延迟敏感，并发成本按体验区间单独核算。适合演示和远程评审，弱网或高并发引流页要谨慎。

三条路线没有通用答案。用户会频繁切前后台、机型覆盖面广时，本地 WebGL 加恢复逻辑往往更稳；只做一次性演示，云渲染可以绕开本地上下文问题，但要接受网络与并发成本。

交付现场那一次返工

有个常见约束是：客户预算和档期都紧，素材只给一套 glTF 模型加两三张实拍图，页面又要求手机端打开就能转、能换色。首版直接上了较高精度贴图和较多材质变体。上线演示当天，甲方用自己的安卓机切出去接电话，回来就是白屏，现场只能重启浏览器。后来补的做法是加回上下文监听与重建、把贴图合并压一档、材质变体从十来个收敛到三到四种，重测才过。代价是多出一轮改造与回归测试，经验区间在 1 到 3 个工作日，演示现场的信任损耗也换不回来。

适用与不适用边界

需要长期挂在线上、用户会频繁切前后台、且要在中低端安卓机上打开的场景，值得把上下文恢复当成交付必做项，哪怕多花一两天。反过来，只用于一次汇报、投屏演示、或只在指定设备上跑的页面，不必为恢复逻辑和资源重建投入太多，把首屏加载和画面效果做稳更划算。

• 适合投入：营销落地页、小程序 3D 商品展示、长期在线配置器、需要用户反复进出的页面。
• 不必强上：一次性大屏演示、只在自家设备上跑的内部评审页、非交互的循环展示。
• 边界句：判断要不要做上下文恢复，看的不是模型有多大，而是用户会不会切走再回来。

验收时把这几条写进清单

• 切后台 30 秒以上再回前台，画面自行恢复，无长时间白屏。
• 连续切换前后台 20 次，不崩、不丢贴图、不出现半黑模型。
• 在约定机型清单上打开，首屏可见时间与运行帧率落在约定区间内。
• 资源释放可验证：隐藏后显存占用明显回落，而不是只涨不降。
• 交付物包含源代码或可维护包、资源清单、已知限制说明。

常见问题

这类白屏修复一般要多久？

若只补上下文监听与渲染循环恢复，经验区间 1 到 2 个工作日；涉及贴图合并、材质收敛和机型回归，常见 3 到 5 个工作日。

是不是换成云渲染就不用管了？

不必然。云渲染能绕开本地上下文回收，但会引入网络延迟与并发成本；用户弱网比例高、并发大的页面，本地 WebGL 加恢复逻辑往往更稳。

安卓机和 iPhone 表现差很多，正常吗？

常见。安卓后台策略与 GPU 回收更分散，同一代码在不同机型上差异大；验收建议按约定机型清单测，而不是只看一台样机。

要不要先把模型面数砍一半？

不一定。白屏多与上下文丢失和资源未重建有关，先查 webglcontextlost 与释放逻辑，再按显存预算决定是否减面。

交付时要给哪些文件？

常见给压缩后的 glTF/GLB 或引擎导出包、贴图源文件、资源清单与已知限制说明；是否给源工程按合同约定，建议提前确认。

如果项目已经上线，建议先用一台安卓机做「锁屏或切后台 30 秒再回来」的自测，并记录控制台是否有上下文丢失告警，再决定是补恢复逻辑还是压资源预算。适用边界是：用户会反复进出页面、机型覆盖面广时优先处理；一次性演示页可把精力放在首屏与画面效果上。犀跃公司在网页 3D 类项目交付中，通常会把这条写进移动端验收清单一起核对。