Jetpack Webkit vs 原生 android.webkit：同一功能为什么差这么多

一个具体例子：safe browsing

Safe Browsing 是 Chrome 生态的安全机制——WebView 可以在加载恶意网页前拦截。

原生 API：

// 这个方法只在 API 27+ (Android 8.1) 存在
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O_MR1) {
    webView.getSettings().setSafeBrowsingEnabled(true);
} else {
    // Android 8.0 及以下怎么办？原生 API 没有这个方法
}

Jetpack API：

// 一行搞定，Jetpack 自动检查设备 WebView 版本是否支持
if (WebViewFeature.isFeatureSupported(WebViewFeature.SAFE_BROWSING_ENABLE)) {
    WebSettingsCompat.setSafeBrowsingEnabled(webView.getSettings(), true);
}
// 不支持的设备静默跳过，不会 crash

区别：原生 API 需要你手动 Build.VERSION.SDK_INT 判断，还要为旧版本写 fallback 逻辑；Jetpack 用 WebViewFeature.isFeatureSupported() 直接检查设备上的 WebView APK 版本（更精确，因为 WebView APK 可以独立于 Android OS 升级）。

另一个例子：Force Dark

Force Dark 让 WebView 在深色模式下自动反转网页配色，原生 API 在不同 Android 版本上的表现：

原生 Force Dark 对 CSS @media (prefers-color-scheme: dark) 的处理在 Android 11 上有 bug——Jetpack 在 M120 左右修复了这个问题，而 Android 原生要到 12L 才对齐。

Jetpack 的额外价值：跨 WebView provider

Jetpack Webkit 不关心设备上到底用的是谁的 WebView——Google Android System WebView、Chrome 兼任的 WebView、小米 HyperOS 自研 WebView、华为 ArkWeb……只要目标 provider 实现了 Chromium 的 API，Jetpack 就能调。

这在国产 Android 设备上尤其重要——你无法预知用户设备的 WebView provider，用 Jetpack 统一处理就行。

什么时候 Jetpack 也帮不了你

如果设备上的 WebView APK 版本太旧（比如 Android 6.0 + WebView 110 以下），某些 API 根本不存在——Jetpack 会静默跳过（或用 fallback 实现），但功能就是做不到。这时只能引导用户更新 WebView：

WebViewProvider.getInstance().startActivityForResult(
    activity,
    activity.getApplicationContext().getPackageManager(),
    1002
);

一句话原则

• 新项目、需要跨版本兼容、需要复杂 WebView 功能 → Jetpack Webkit
• 老项目、只用基础 loadUrl + setWebViewClient、不在乎版本差异 → 原生 API 也能用（但迟早要迁移）

→ 下一页：Jetpack 与 WebView provider 的交互