1. 问题背景
本次验证聚焦以下场景:
- 后台线程异步调用
WebSettings.getDefaultUserAgent()
- 主线程在冷启动阶段首次调用
new WebView()
- 两者并发进入 WebView provider / Chromium 初始化链
目标不是验证'预热是否一定提速',而是确认:
- 是否存在共享初始化链竞争
- 主线程是否会因此被拖慢或阶段性阻塞
- 是否具备演化为 ANR 的风险
2. 关键修正结论
结合当前所有日志,更准确的结论应为:
getDefaultUserAgent() 与首次 new WebView() 并发时,二者并不是始终'卡死'在 WebViewFactory.getProvider() 这一行;更真实的表现是:它们会共享同一条 WebView provider / Chromium 初始化链,在不同阶段交错推进,并在部分关键节点出现阶段性等待、锁竞争或串行化,进而放大主线程耗时。
也就是说,问题本质更接近:
- 交错执行
- 阶段性阻塞
- 共享初始化链导致主线程长卡顿
而不是:
- 两个线程永久互锁
- 一直完全卡死在
WebViewFactory.getProvider()
3. 验证方式
统一实验模式:
EXPERIMENT_MODE = CONCURRENT
- 冷启动首次进入
MainActivity
- 在
new WebView() 前触发后台 WebSettings.getDefaultUserAgent()
- 通过 watchdog 在
100ms / 200ms / 500ms 采样:
- 主线程栈
- UA 线程栈
- 当前阻塞时长
- UA 线程状态
关键日志关键词:
WebWarmVerify
watchdog_trigger
thread_dump role=main
thread_dump role=ua
4. 测试设备与配置
4.1 模拟器配置
| 设备名 | 系统版本 | 镜像/ABI | 启动方式 | 资源配置 | 配置定位 |
|---|
Pixel_API25_7.1.1 | API 25 / Android 7.1.1 | Google Play x86 | Cold Boot | CPU 2 核 / RAM 2GB / Graphics Automatic | 问题复现配置 |
Pixel3a_API29_WebView | API 29 / Android 10 | Google Play x86_64 | Cold Boot | CPU 2 核 / RAM 2GB / Graphics Automatic | 问题复现配置 |
Medium Phone API 36 | API 36 / Android 16 | Google Play x86_64 | Cold Boot | CPU 2 核 / RAM 2GB / Graphics Automatic | 问题复现配置 |
说明:
- 上述资源配置用于放大问题、验证机制。
- 不完全等同真实量产机参数,尤其高版本模拟器更偏'保守压测配置'。
- 因此更适用于证明风险存在,而非代表所有真实设备的绝对耗时。
4.2 真机
| 设备 | 系统 | 说明 |
|---|
| Xiaomi 真机 | Android 16 | 用于补充真实设备行为验证 |
5. 总体观察
所有环境下都能看到以下共同现象:
- 后台
getDefaultUserAgent() 与主线程 new WebView() 明确重叠发生。
- 二者都会进入
WebViewFactory.getProvider() 及其后续 provider / Chromium 初始化路径。
- 主线程有时会短暂
BLOCKED at WebViewFactory.getProvider()。
- 更多时候,主线程会继续向后推进,进入:
getProviderClass()
loadNativeLibrary()
WebViewChromiumFactoryProvider
AwBrowserProcess
ContentMain
AwContents
- UA 线程也会在不同阶段交替处于:
这表明当前问题更像:
共享初始化链上的交错推进 + 局部阻塞
而不是单点永久死锁
6. 分设备结论
6.1 API 25 / Android 7.1.1 模拟器
典型现象:
- 主线程出现在:
WebViewFactory.getProvider
getProviderClass
WebViewLibraryLoader.loadNativeLibrary
WebViewChromiumFactoryProvider
AwBrowserProcess
- UA 线程出现在:
WebSettings.getDefaultUserAgent
WebViewFactory.getProvider
WebViewChromiumFactoryProvider.getStatics
结论:
- 老版本系统下已明确复现共享初始化链竞争
- 主线程阻塞与后续 Chromium 初始化交错存在
- 问题容易被放大,属于高风险启动卡顿场景
6.2 API 29 / Android 10 模拟器
典型现象:
- 多次抓到主线程:
BLOCKED at WebViewFactory.getProvider
WAITING in WebViewChromiumFactoryProvider.<init>
SharedPreferencesImpl.awaitLoadedLocked
- 同时 UA 线程位于:
getDefaultUserAgent
getProvider
WebViewChromiumFactoryProvider.getStatics
结论:
API 29 是证据最强的模拟器环境
- 已稳定证明:
- 存在 provider 入口竞争
- 存在 provider 初始化内部等待
- 存在 provider 之后的 Chromium 启动串行化
- 这台设备可作为核心证明样本
6.3 API 36 / Android 16 模拟器
典型现象:
- 主线程多次:
BLOCKED at WebViewFactory.getProvider
- 或进入
getProviderClass / loadNativeLibrary / ResourcesManager / AwBrowserProcess / AwContents
- UA 线程同时:
getDefaultUserAgent
getProvider
getProviderClass
loadNativeLibrary
ResourcesManager.registerResourcePaths
结论:
- 高版本系统同样存在该问题
- 说明问题不是老系统特有,也不是单版本偶发
- 高版本上依然会出现明显主线程长卡顿
6.4 Android 16 真机
真机日志体现出两个层次:
A. 常规样本
多次出现:
getDefaultUserAgent_ms ≈ 69ms ~ 73ms
newWebView_ms ≈ 85ms ~ 91ms
- 未触发 watchdog
- 但仍伴随:
onStart took 451ms ~ 487ms
Skipped 79+
Davey 741ms ~ 782ms
说明:
- 并发存在
- 但不是每次都严重到抓到竞争现场
- 真机上该问题具有波动性
B. 放大样本
例如首条真机样本:
getDefaultUserAgent_ms = 177ms
newWebView_ms = 193ms
- 触发 watchdog
- 主线程位于:
BrowserStartupControllerImpl
AwBrowserProcess
WebViewChromium.init
- UA 线程位于:
CountDownLatch.await
WebViewChromiumFactoryProvider$StaticsAdapter.getDefaultUserAgent
说明:
- 真机上也可以抓到共享启动链的交错等待
- 只是相比模拟器,真机更常表现为:
- 部分样本较轻
- 部分样本明显放大
- 更像'间歇性长尾风险'
结论:
- 真机证据支持:问题真实存在
- 但真机更强调'有风险、可放大、非每次都重现到同一强度'
7. 量化表现
结合三台模拟器和真机,当前观察到的范围如下:
| 指标 | 观察结果 |
|---|
getDefaultUserAgent_ms | 数十毫秒到 2 秒以上 |
newWebView_ms | 数十毫秒到 2 秒以上 |
dtSinceOnCreate | 从百毫秒到 3 秒以上 |
Skipped frames | 多次高数量掉帧 |
Davey | 从 700ms 到数秒 |
说明:
- 该问题不是'轻微波动'
- 在放大场景下已经能形成秒级主线程长卡顿
- 真机上虽然不一定每次都放大,但已经存在明确长尾风险
8. 统一技术结论
综合所有数据,当前最准确的结论是:
- 后台
WebSettings.getDefaultUserAgent() 与主线程首次 new WebView() 并发时,确实会共享同一条 WebView provider / Chromium 初始化链。
- 两者并不是始终卡死在
WebViewFactory.getProvider();更常见的表现是:
- 在
getProvider 入口存在阶段性阻塞
- 随后在 provider / classloader / native library / Chromium startup /
AwContents 等阶段交错推进
- 主线程会在这条链路中被显著拖慢,部分样本可出现明显阻塞。
- UA 线程同时处于同一链路的不同阶段,证明共享初始化链竞争真实存在。
- 该现象在
API 25、API 29、API 36 以及 Android 16 真机上均可观察到,因此不是单一版本、单一设备或单一 ROM 的问题。
9. ANR 风险结论
当前数据足以证明:
- 存在真实竞争
- 存在主线程阻塞或长卡顿
- 存在明显掉帧和长尾样本
- 具备演化为 ANR 的现实风险
但当前仍不能写成:
- '已经证明必然 ANR'
- '已经采到明确 ANR trace'
因为目前尚缺少:
ANR in com.kuen.beautifulchina
Input dispatching timed out
/data/anr/ 对应主线程 trace
因此建议最终表述为:
已证明 getDefaultUserAgent() 与首次 new WebView() 并发时,会引发共享 WebView provider / Chromium 初始化链上的交错执行与阶段性竞争,能够显著拖慢主线程;在弱环境、冷启动或系统负载较高时可形成秒级长卡顿,具备演化为 ANR 的高风险。
10. 风险定级建议
建议定级为:
- 机制风险:高
- 启动卡顿风险:高
- 长尾稳定性风险:高
- ANR 演化风险:高
11. 整改建议
建议避免以下场景重叠发生:
- 后台异步
getDefaultUserAgent()
- 冷启动关键路径中的首次
new WebView()
建议优化方向:
- 不要让
getDefaultUserAgent() 与首次 new WebView() 在冷启动阶段并发发生。
- 若必须预取 UA,应与首次 WebView 创建做时序隔离。
- 若业务必须在冷启动早期使用 WebView,应避免额外后台线程同时触发 WebView provider 初始化。
- 后续可补充:
- 真机稳定场景复测
- 弱机型验证
- ANR trace 采样
12. 总结
本次在 API 25、API 29、API 36 三台冷启动模拟设备,以及 Android 16 真机上进行了验证。结果表明:后台 WebSettings.getDefaultUserAgent() 与主线程首次 new WebView() 并发时,会共享同一条 WebView provider / Chromium 初始化链。二者并不是始终卡死在 WebViewFactory.getProvider(),而是在 provider、classloader、native library、Chromium startup、AwContents 等阶段交错推进,并在关键节点发生阶段性阻塞或串行化。实验中多次抓到主线程阻塞于 WebViewFactory.getProvider(),后台 UA 线程同时位于 getDefaultUserAgent -> getProvider / getProviderClass / loadNativeLibrary / WebViewChromiumFactoryProvider 等路径,说明该并发场景会真实拖慢主线程。该问题已在多版本环境中复现,伴随明显掉帧与长卡顿,属于高风险启动稳定性问题,并具备演化为 ANR 的现实风险。