WebView白屏卡顿主因是初始化、资源加载、JS上下文切换及渲染阻塞；应预热复用实例、拦截缓存静态资源、启用硬件加速，并配合History API避免整页刷新。
WebView 加载 HTML5 页面时白屏卡顿的常见原因
HTML5 页面在 WebView 中跳转卡顿，多数不是 HTML 本身慢，而是 WebView 的初始化、资源预加载、JS 执行上下文切换或渲染线程阻塞导致。尤其在 Android 的 WebView（非 Chrome Custom Tabs）中，首次跳转常伴随明显白屏；iOS 的 WKWebView 虽快，但 JS 注入时机不当也会卡住导航。
- Android
WebView默认不复用渲染进程，每次loadUrl()都可能触发新页面的完整生命周期（含 JS 引擎重启） -
shouldOverrideUrlLoading()中同步执行耗时逻辑（如本地路由判断、鉴权）会阻塞跳转 - HTML 页面未启用
viewport缩放控制或含大量内联样式/脚本，导致首帧渲染延迟 - 跳转前未主动调用
webView.onPause()/webView.onResume()（Android），造成渲染线程挂起
用 shouldInterceptRequest 提前拦截并缓存静态资源
跳转卡顿常源于重复请求 CSS/JS/字体等静态资源。原生层可通过 shouldInterceptRequest()（Android）或 decidePolicyForNavigationAction:（iOS）提前捕获请求，返回内存或本地缓存的响应，避免网络 IO 延迟。
- Android：重写
WebViewClient.shouldInterceptRequest()，对.js、.css、.woff2等后缀返回WebResourceResponse，内容从AssetManager或 LRU 缓存读取 - iOS：在
WKNavigationDelegate的webView:decidePolicyForNavigationAction:decisionHandler:中，对静态资源 URL 构造本地file://路径，或用WKURLSchemeHandler拦截并异步返回数据 - 注意：不要拦截 HTML 主文档请求（
text/html），否则会破坏路由逻辑；只拦截子资源
跳转前预热 WebView 实例并复用
频繁新建 WebView 是卡顿元凶之一。应避免“一个页面一个 WebView”的做法，改用池化或单例预热策略。
- Android：App 启动时初始化一个全局
WebView实例（调用WebView.setDataDirectorySuffix()隔离缓存），跳转时复用该实例 +loadUrl()，而非 new 新对象 - iOS：复用
WKWebView实例时，确保未调用removeFromSuperview，跳转前执行webView.evaluateJavaScript("location.href='...';")比loadRequest:更轻量（绕过部分导航策略校验） - 关键点：预热时需至少触发一次
onPageStarted()，让 JS 引擎和渲染器完成初始化；可加载一个空about:blank页面完成
HTML 层配合：用 History API + 动态加载替代整页刷新
原生跳转卡顿，往往是因为 H5 侧还在用 window.location.href = 'xxx.html' 触发整页 reload。应改用前端路由 + pushState()，由原生层监听 popstate 事件做轻量响应。
