🧐 首次启动白屏的成因
在用户首次打开一个 WebView 页面时，主要经历以下几个阶段：
- WebView 实例创建：创建 WebView 对象本身需要一定开销。
- WebView 内核初始化：系统首次创建 WebView 时，会加载 WebView 的底层库（如
libwebviewchromium.so），这个过程可能耗时几十到几百毫秒。 - 页面请求与加载：发起网络请求，下载 HTML、CSS、JS 等资源。
- 解析与渲染：浏览器内核解析 HTML、构建 DOM 树、渲染树，最终绘制到屏幕上。
- 数据填充：如果页面需要异步请求数据，还有额外的等待时间。
其中，内核初始化 + 网络请求通常是白屏的最主要因素。优化就是针对这些阶段“抢时间”。
🚀 首次启动白屏优化策略
1. 预创建 WebView 实例（核心手段）
在用户真正进入 WebView 页面之前，提前创建好 WebView 对象，甚至提前完成内核加载。常见做法：
- 在 Application 中预创建：在应用启动时，在后台线程（或主线程空闲时）创建一个 WebView 并加载空白页。
- 在进入页面之前的某个时机预创建：例如在列表页滑动时，利用空闲时间预创建。
代码示例（在 Application 中预加载）：
class MyApp : Application() {
override fun onCreate() {
super.onCreate()
// 使用 IdleHandler 在主线程空闲时预创建
Looper.myQueue().addIdleHandler {
preloadWebView()
false
}
}
private fun preloadWebView() {
WebView(this).apply {
settings.javaScriptEnabled = true // 按目标页面的配置来
loadUrl("about:blank") // 加载空白页，实际会触发内核初始化
}
}
}
注意：WebView 的创建必须在主线程，但内核初始化过程会自动使用多线程，不会阻塞主线程太久。我们只是提前触发这个初始化过程，让它在用户到达页面之前完成。
2. 使用启动画面 / 占位布局
在 WebView 尚未渲染出内容前，先显示一个静态的占位布局（比如应用的品牌色、Logo、骨架屏），这能从视觉上消除“白屏”，让用户感知到页面已经打开。
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<WebView
android:id="@+id/webview"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:visibility="gone" />
<ProgressBar
android:id="@+id/progressBar"
style="?android:attr/progressBarStyleHorizontal"
android:layout_width="match_parent"
android:layout_height="2dp"
android:layout_gravity="top" />
<ImageView
android:id="@+id/placeholder"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:src="@drawable/splash_logo"
android:scaleType="center" />
</FrameLayout>
在 WebView 加载开始（onPageStarted）时，隐藏占位图，显示 WebView 和进度条；在 onPageFinished 时隐藏进度条。这种方式简单有效，让用户感觉不到明显的空白。
3. 资源本地化（拦截关键资源）
将页面依赖的核心 JS/CSS 文件（如 Vue、React 框架文件）打包到 assets 目录，通过 shouldInterceptRequest 拦截网络请求，直接从本地返回。这能完全消除这些资源的网络下载时间，对首次加载提速非常明显。
webView.webViewClient = object : WebViewClient() {
override fun shouldInterceptRequest(
view: WebView?,
request: WebResourceRequest?
): WebResourceResponse? {
val url = request?.url.toString()
return when {
url.contains("framework.min.js") -> {
// 从 assets 读取
val inputStream = assets.open("js/framework.min.js")
WebResourceResponse("application/javascript", "UTF-8", inputStream)
}
else -> super.shouldInterceptRequest(view, request)
}
}
}
注意：本地资源需要与线上版本保持一致，否则可能导致页面异常。
4. 数据并行请求 + 预注入
在 WebView 加载页面的同时，Native 使用 OkHttp 等工具提前请求页面所需的数据接口。待页面核心 JS 加载完成后，通过 evaluateJavascript 将数据直接注入到页面的全局变量中，让前端可以直接使用，省去前端再发 Ajax 请求的时间。
// 在 WebView 加载前，启动一个协程请求数据
lifecycleScope.launch(Dispatchers.IO) {
val data = apiService.getPageData() // 假设这是页面需要的 JSON
withContext(Dispatchers.Main) {
webView.evaluateJavascript("window.__PRELOADED_DATA__ = ${data};", null)
}
}
webView.loadUrl("https://your-page-url")
前端需要在页面加载完成后检查 window.__PRELOADED_DATA__，如果有则直接使用，不再发起请求。
5. 优化服务端响应
与后端协作，确保：
- 首屏直出：服务端直接返回完整的首屏 HTML（包含数据和样式），而不是一个空的
<div id="app">。 - 开启 Gzip/Brotli 压缩，减小资源体积。
- 合理设置缓存头，虽然首次无法直接使用缓存，但可以避免后续不必要的协商。
6. 使用预先加载的 HTML 模板
对于某些页面（如活动页），可以预先将页面的 HTML 模板打包到 assets 中，WebView 先加载本地模板，同时请求最新数据，然后通过 JavaScript 更新内容。这样用户能瞬间看到页面框架，等待时间只有数据请求的耗时。
webView.loadUrl("file:///android_asset/template.html")
// 然后在页面加载完成后注入数据更新内容
7. 启用硬件加速
确保 WebView 所在的 Activity 开启了硬件加速，这会提升渲染效率，减少白屏时间。
<activity
android:name=".WebViewActivity"
android:hardwareAccelerated="true" />
📊 效果衡量与监控
实施优化后，需要用数据说话。可以通过以下方式监控白屏时长：
- Navigation Timing API：在
onPageFinished时注入 JS，获取performance.timing的domLoading到domComplete的时间差，近似作为白屏时间。 - 自定义打点：在 Native 侧记录开始加载的时间点和 WebView 首次绘制（
onPageStarted/ 第一次内容绘制）的时间。
✅ 总结：首次启动白屏优化的核心要点
| 优化手段 | 解决的问题 | 推荐指数 |
|---|---|---|
| 预创建 WebView 实例 | 内核初始化耗时 | ⭐⭐⭐⭐⭐ |
| 占位布局 | 视觉上的空白 | ⭐⭐⭐⭐⭐ |
| 资源本地化 | 核心资源网络下载 | ⭐⭐⭐⭐ |
| 数据并行请求 + 注入 | 数据接口等待时间 | ⭐⭐⭐⭐ |
| 首屏直出 | HTML 解析与渲染时间 | ⭐⭐⭐⭐（需后端配合） |
| 启用硬件加速 | 渲染效率 | ⭐⭐⭐ |
