开屏广告背景需原生层预置静态图撑住启动瞬间，webview就绪后用预加载+css覆盖实现动态切换，禁用自动关闭、控制显隐时机、垫纯色背景、手动释放图片资源并强制硬件加速以避免白屏与卡顿。
开屏广告背景图如何动态加载并避免白屏
App端开屏广告背景不能直接用v-if或v-show切图，否则冷启动时会闪白——因为uni-app的Vue实例还没初始化，页面DOM已渲染但图片资源未就绪。必须在原生层（iOS/Android）完成首帧背景绘制，再交由Webview加载广告逻辑。
实际做法是：把背景图预置进原生包（iOS放LaunchImage或Assets.xcassets，Android放res/drawable-xxx），然后通过plus.navigator.setSplashscreen控制显隐时机；动态切换则靠后续Webview内用background-image覆盖原生背景，但需确保新图已预加载完成。
- 务必在
onLaunch里调用plus.navigator.setSplashscreen({ autoClose: false })禁用自动关闭，否则原生开屏一闪就没了 - Webview内用
new Image().src = url预加载下一张背景，onload触发后才应用CSS，避免背景突变或空白 - Android 12+对
splashscreen有强制限制，若targetSdkVersion ≥ 31，必须用androidx.core.splashscreen原生方案，uni-app默认不兼容，得自己改AndroidManifest.xml和MainActivity.java
如何用uni-app JS控制原生开屏的显示/隐藏节奏
uni-app提供的plus.navigator.setSplashscreen只支持一次设置，没法“中途切图”。所谓“动态切换”，其实是两阶段：第一阶段靠原生静态图撑住启动瞬间，第二阶段在Webview就绪后，用绝对定位的div盖在webview上模拟新背景，并控制其淡入淡出。
关键点在于时机同步：plus.navigator.closeSplashscreen()不能早于Webview内容渲染完成，否则会看到白底；也不能晚于广告倒计时结束，否则影响跳过逻辑。
- 监听
plus.webview.currentWebview().addEventListener('loaded', ...)比mounted更可靠，因为后者可能在DOM未挂载完就触发 - 倒计时从3秒开始时，建议预留200ms缓冲，比如
setTimeout(close, 3200)，防止低端机渲染延迟导致闪屏 - 关闭原生开屏前，先用
document.body.style.background = '#000'垫一层纯色，能极大缓解白屏感知
动态背景切换时如何避免内存暴涨和卡顿
频繁切换背景图（比如轮播5张高清图）容易触发Android低端机OOM或iOS WebKit内存回收，表现为卡顿、掉帧甚至崩溃。根本原因不是JS逻辑，而是img标签或background-image没及时释放。
必须手动管理图片资源生命周期：每次切换前，清除上一张图的src引用，并将对应DOM节点opacity设为0后remove()，而不是仅v-if隐藏。
- 用
URL.createObjectURL(blob)加载的图，切换后必须调用URL.revokeObjectURL(url)，否则内存永不释放 - Android WebView默认禁用
will-change: background-image硬件加速，要加transform: translateZ(0)强制开启 - 背景图尺寸严格控制在
1080×1920以内，WebP格式比PNG体积小40%以上，且解码更快
为什么uni-app的onShow在开屏阶段不可靠
onShow在App端实际触发时机是Webview完全就绪且前台可见后，但开屏广告需要在onLaunch阶段就开始调度——此时onShow根本没执行。很多开发者误以为在onShow里写广告逻辑就能覆盖整个开屏流程，结果广告延迟半秒才出现，或者被系统状态栏遮挡。
正确路径是：所有开屏控制逻辑必须收口到App.vue的onLaunch + onShow组合使用，且onLaunch里要立即初始化广告数据、预加载图片、设置定时器；onShow只负责补漏（比如用户切后台再切回前台时重新拉取广告）。
-
onLaunch里不能依赖this.$refs或uni.getSystemInfo回调，它们异步且可能晚于原生开屏关闭 - 广告跳过按钮的
z-index必须大于2147483647（iOS最大值），否则会被原生导航栏压住 - 真机调试时，
console.log会拖慢开屏速度，上线前务必删掉所有开屏阶段的日志
