Android: 3D Web Page Goes White After Lock Screen, Works Again After Restarting Browser—Is the Context Being Reclaimed by the System?

Conclusion first: On Android, after locking the screen or switching to the background and then reopening a web 3D page, a white screen appears; restarting the browser makes it normal again. In most cases, this is not because the model has too many faces, but because the WebGL context was reclaimed by the system and not restored. On mobile, context loss can be triggered when switching to the background, locking the screen, receiving a call, or when video memory is tight; if the page only writes the start-rendering logic and does not listen for webglcontextlost and webglcontextrestored, it is easy for the screen to go white when it comes back. Based on common 2026 delivery experience, the troubleshooting order is: first check whether the console has context loss warnings, then check whether textures and geometry are actually released, and then return to reducing faces and compressing images.

First distinguish three types of white screen; the fix direction is different

The white screen the client mentions verbally corresponds to at least three kinds of failures in 2026 delivery. Investigating them as one issue often wastes two or three days. The first is total context loss: the image does not even have a background color. The second is that the context still exists, but the render loop has stopped, for example requestAnimationFrame was stopped when the page was hidden and not resumed. The third is that the context has returned, but resources were not rebuilt: the model outline is there, while textures are black or geometry chunks are missing. The repair locations are event listening, loop scheduling, and resource rebuilding respectively. Define the type before acting; that is easier than directly reducing the model.

• All white or all black, page text still present: suspect context loss or initialization failure first.
• UI normal, 3D area frozen: suspect the render loop was not resumed or was throttled first.
• Model outline present, colors black or blotchy: suspect textures and render targets were not re-uploaded first.

Why Android contexts are easily reclaimed

The WebGL context is managed by the browser and the GPU process; the web page cannot fully control it. To save power or reclaim memory, the system may reduce frequency when the page is invisible, or even terminate the GPU process; when the page returns to the foreground, the context it gets is invalid. Background policies vary greatly across Android models. The same code may be fine after switching away for a dozen seconds on model A, but go white after two minutes on model B. This is a system behavior difference, and it is not necessarily a frontend coding error.

• When switching to the background or locking the screen for a relatively long time, commonly from tens of seconds to several minutes, it varies by system and model.
• Incoming calls, split screen, or system pop-ups taking over the foreground can also trigger reclamation.
• When the same page has multiple WebGL canvases, exceeding the number the device can handle makes failure more likely.
• When opened in an embedded WebView inside an app, the page may be reclaimed as a whole, and returning is equivalent to reloading.

Reset approach: listen—clean up—rebuild

Splitting the problem into three layers is because the responsible parties are different: listening belongs to the frontend event layer, cleanup belongs to the resource management layer, and rebuilding belongs to the rendering pipeline layer. Doing only one of these layers often results in a half-recovered state such as 'it comes back but goes black for a moment' or 'it comes back but textures are lost', which makes acceptance even more troublesome.

1. Listen: register webglcontextlost and call preventDefault in the callback, and also register webglcontextrestored; then use visibilitychange to determine page hiding and restoration, and actively pause the render loop when hidden.
2. Clean up: when the page is hidden or the context is lost, pause the render loop and timers, and release GPU-side resources such as textures, geometry, and render targets. Cleanup must be idempotent; repeated calls must not throw errors.
3. Rebuild: on restoration, re-upload textures, recompile shaders, rebuild render targets and camera aspect ratio, and then resume the render loop; during rebuilding, provide a placeholder or loading state, and do not leave users staring at a white screen.

A qualified baseline can be made fairly specific: after switching to the background for more than 30 seconds and returning, the image can recover by itself, and the black-screen or placeholder duration is controlled around 1 second (experience range); only when switching foreground/background 20 times in a row without crashing, losing textures, or showing half-black models does it pass.

Resource budget and comparison of three routes

Context loss is a runtime problem, but the resource budget determines how long rebuilding takes and whether rebuilding fails. A common situation is: what occupies high video memory is not the model face count, but the number of textures and render targets. In 2026 delivery, a single texture is commonly controlled at 1K to 2K; the total number of textures and total video memory usage are more critical than a single texture size; display models are commonly controlled within hundreds of thousands of triangles (experience range), and anything beyond that should first be merged and reduced.

• Pure frontend WebGL (such as Three.js / Babylon.js): package size is controllable, loading is relatively fast, and modification is flexible; context and resource management must be written by yourself, and stability depends on frontend discipline. The experience range for recovery retrofitting is commonly 1 to 2 working days.
• Engine-exported WebGL package: visuals and lighting are often better, but package size is commonly larger and memory usage is also higher, making context loss more likely on low-end Android devices. Recovery plus regression testing commonly takes 3 to 5 working days.
• Cloud pixel streaming or cloud rendering: locally it consumes almost no GPU resources, and the upper limit of image quality is relatively high; but it is sensitive to network stability and latency, and concurrency cost is calculated separately by experience range. It suits demos and remote reviews; be cautious with weak networks or high-concurrency landing pages.

There is no universal answer among the three routes. When users frequently switch foreground/background and model coverage is broad, local WebGL plus recovery logic is often more stable; for a one-time demo, cloud rendering can bypass local context issues, but you have to accept network and concurrency costs.

One rework at the delivery site

A common constraint is: the client budget and schedule are both tight, the assets include only one set of glTF models plus two or three real photos, and the page must be rotatable and color-changeable on mobile. The first version directly used relatively high-precision textures and many material variants. On the launch demo day, the client switched out to answer a call on their Android phone and came back to a white screen; on site, the only option was to restart the browser. The later fix was to add context listening and rebuilding back, merge textures and compress them by one level, and converge material variants from about ten to three or four types; only then did retesting pass. The cost was an extra round of retrofitting and regression testing, with an experience range of 1 to 3 working days; the loss of trust during the demo could not be recovered either.

Applicable and non-applicable boundaries

For scenarios that need to stay online long term, where users frequently switch foreground/background, and which must open on low- and mid-range Android devices, it is worth making context recovery a required delivery item, even if it costs one or two extra days. Conversely, for pages used only for a one-time report, screen projection demo, or running only on specified devices, there is no need to invest too much in recovery logic and resource rebuilding; making first-screen loading and visual quality stable is more cost-effective.

• Suitable for investment: marketing landing pages, mini-program 3D product displays, long-running online configurators, and pages users need to enter and exit repeatedly.
• No need to force it: one-time large-screen demos, internal review pages that run only on your own devices, and non-interactive looping displays.
• Boundary sentence: whether to do context recovery depends not on how large the model is, but on whether users will switch away and come back.

Put these items into the acceptance checklist

• Switch to the background for more than 30 seconds and return to the foreground; the image recovers by itself, with no long white screen.
• Switch foreground/background 20 times in a row: no crash, no lost textures, no half-black models.
• Open on the agreed model list; first-screen visible time and runtime frame rate fall within the agreed ranges.
• Resource release is verifiable: after hiding, video memory usage drops noticeably, rather than only rising and never falling.
• Deliverables include source code or a maintainable package, a resource list, and a description of known limitations.

FAQ

How long does this kind of white-screen fix usually take?

If only context listening and render loop recovery are added, the experience range is 1 to 2 working days; if texture merging, material convergence, and model regression are involved, it commonly takes 3 to 5 working days.

If we switch to cloud rendering, do we no longer need to care?

Not necessarily. Cloud rendering can bypass local context reclamation, but it introduces network latency and concurrency costs; for pages with a high proportion of weak-network users and high concurrency, local WebGL plus recovery logic is often more stable.

Is it normal that Android devices and iPhone perform very differently?

It is common. Android background policies and GPU reclamation are more fragmented, and the same code varies greatly across models; for acceptance, test against the agreed model list rather than just one sample device.

Should we cut the model face count in half first?

Not necessarily. White screens are mostly related to context loss and resources not being rebuilt. Check webglcontextlost and release logic first, and then decide whether to reduce faces according to the video memory budget.

What files should be delivered?

Commonly, the compressed glTF/GLB or engine export package, texture source files, a resource list, and a description of known limitations; whether to provide source projects depends on the contract, and it is best to confirm in advance.

If the project is already online, it is advisable to first use an Android device to do a self-test of 'lock the screen or switch to the background for 30 seconds and then return', and record whether the console has context loss warnings, then decide whether to add recovery logic or compress the resource budget. The applicable boundary is: prioritize handling when users repeatedly enter and exit the page and model coverage is broad; for one-time demo pages, put effort into first-screen and visual quality. In web 3D project delivery, Xiyue Company usually writes this item into the mobile acceptance checklist and checks it together.