WebView缓存机制详解与实战优化策略
设计师子墨优化前：卡得不行
上个月我们上线了一个内嵌在 App 里的 WebView 页面，结果用户反馈“点开就转圈，半天打不开”。我本地测的时候也确实慢得离谱——首次加载要 5 秒多，弱网下直接超时。更糟的是，每次退出再进来，又得重新拉资源，连图片都得重新下载。这体验谁受得了？
其实页面本身不复杂，就是个商品详情页，静态资源也就 1MB 左右。但 WebView 默认的缓存策略太保守了，基本等于没缓存。每次打开都走网络，连 CSS、JS 都不存，难怪卡。
找到瓶颈了！
我先用 Chrome DevTools 的 Network 面板抓了下包，发现每次进入页面，所有资源（包括那些从来没变过的 vendor.js、common.css）都返回 200，而不是 304。说明服务器没配 ETag 或 Last-Modified，或者 WebView 根本没发 If-None-Match 这类头。
接着在 Android Studio 里开了 WebView 的调试模式，用 chrome://inspect 看请求头，果然——WebView 默认不会启用强缓存，除非你明确告诉它怎么做。iOS 的 WKWebView 也好不到哪去，缓存策略默认是 .useProtocolCachePolicy，对 HTTP 缓存头依赖太强，而我们的后端又没好好配。
折腾了半天发现，问题不在代码逻辑，而在缓存策略压根没生效。
试了几种方案，最后这个效果最好
一开始我想靠服务端加 Cache-Control: max-age=3600 解决，但后端说线上环境不敢随便改，怕影响其他端。那只能前端自己搞了。
Android 的 WebView 其实提供了 setAppCacheEnabled 和 setCacheMode，但文档写得含糊，而且 AppCache 已经被废弃了。后来查资料发现，真正有效的做法是配合合理的 HTTP 缓存头 + 启用 WebView 的缓存机制。
在 Android 端，我做了两件事：
- 开启 WebView 的缓存目录
- 设置缓存模式为
LOAD_DEFAULT（即优先使用缓存，没有再走网络）
关键代码如下：
WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
// 启用 DOM storage
settings.setDomStorageEnabled(true);
// 设置缓存路径（必须）
String cacheDir = getCacheDir().getAbsolutePath();
settings.setAppCachePath(cacheDir);
settings.setAppCacheEnabled(true);
// 核心：设置缓存模式
settings.setCacheMode(WebSettings.LOAD_DEFAULT);注意：setAppCacheEnabled 虽然名字带“AppCache”，但实际在 Android 5.0+ 之后，它底层用的是 HTTP 缓存，不是那个废弃的 Application Cache。这里我踩过坑，以为不能用，结果试了发现有效。
iOS 那边更简单。WKWebView 默认会尊重 HTTP 缓存头，但前提是你要允许它缓存。关键是配置 WKWebViewConfiguration 时别禁用缓存。我们之前为了“保证最新”错误地设置了 URLCache.shared = URLCache(memoryCapacity: 0, diskCapacity: 0)，直接把缓存干掉了。改回来就行：
let config = WKWebViewConfiguration()
// 别动 URLCache！让它用默认的
let webView = WKWebView(frame: .zero, configuration: config)但光这样还不够——如果后端不返回 Cache-Control，WebView 依然不会缓存。所以我和后端协商，给静态资源加了长期缓存头。比如：
Cache-Control: public, max-age=31536000
ETag: "abc123"同时，我们在构建时给文件加了 hash，比如 main.a1b2c3.js，这样内容变了文件名就变，不怕缓存不更新。
前端代码里，我们还加了个兜底：如果页面加载失败，尝试从缓存重试。虽然不完美，但能提升弱网下的可用性：
window.addEventListener('error', (e) => {
if (e.target.tagName === 'SCRIPT' || e.target.tagName === 'LINK') {
// 如果是资源加载失败，且当前是 online，可以提示重试
// 但如果是 offline，就尽量用缓存
if (!navigator.onLine) {
console.log('离线状态，依赖缓存');
}
}
});核心代码就这几行，但效果立竿见影
最核心的其实是两处：一是 Android WebView 的缓存配置，二是后端给静态资源加 Cache-Control。很多人只改前端，忘了后端配合，结果缓存还是不生效。
另外提醒一点：别在 WebView 里用 location.reload() 强刷，这会绕过缓存。我们之前有个“刷新”按钮直接调 reload()，导致用户点一下就全量重载，体验极差。后来改成重新 loadUrl() 原始地址，让缓存机制正常工作。
还有个小技巧：在开发阶段，可以用 WebSettings.setCacheMode(WebSettings.LOAD_NO_CACHE) 关闭缓存，方便调试。但上线前一定记得改回来！我就有一次上线忘了改，用户全在裸奔……
性能数据对比
改完后，我用同一台测试机（Android 12，4G 网络）跑了 10 次加载，取平均值：
- 优化前：首次加载 5.2s，二次加载 4.8s（基本没缓存）
- 优化后：首次加载 2.1s，二次加载 0.8s（CSS/JS 全命中磁盘缓存）
iOS 侧也类似，二次加载从 4.5s 降到 0.7s 左右。用户反馈“秒开”虽然夸张，但确实流畅多了。
当然，首次加载还是没法太快，毕竟要下载 HTML 和首屏数据。但我们把静态资源缓存住后，后续交互（比如切换 tab、返回详情页）几乎无感。
唯一的小问题是：如果用户清了 App 缓存，WebView 的缓存也会被清掉。不过这是系统行为，我们控制不了，也算合理。
以上是我的优化经验，有更好的方案欢迎交流
这次优化其实没用什么高深技术，就是把 WebView 的缓存机制用对了。很多团队一遇到 WebView 慢，就想着上预加载、离线包，但其实先搞定基础缓存，能解决 80% 的问题。
当然，这套方案依赖后端配合加缓存头。如果你们后端完全不动，也可以考虑在 WebView 里拦截请求，自己实现一套资源缓存（比如用 shouldInterceptRequest），但那样复杂度高不少，我试过，维护成本大，不推荐除非万不得已。
以上是我踩坑后的总结，希望对你有帮助。有更优的实现方式欢迎评论区交流，比如你们怎么处理动态内容的缓存？或者 iOS 上有没有更好的缓存控制手段？
暂无评论