今天跟大家唠唠我捣鼓webview这玩意儿的一些经历。一开始接触它，纯粹是因为项目里有些页面变得太快，老是让用户更新App版本，人家嫌烦，我们自己也觉得效率低。所以就想着，干脆嵌个网页得了，改起来也方便。
初次尝试与糟心体验
理想很丰满，现实是骨感的。刚把webview套进去，加载第一个页面的时候，那速度，简直了！屏幕白花花一片，等个好几秒甚至更久才出来，用户体验差到不行。尤其是在一些性能不咋地的安卓机上，滑动都卡顿，感觉就像在看幻灯片，我自己都用得难受。
摸索优化之路
遇到问题总得解决嘛我就开始琢磨，这玩意儿肯定有啥门道能让它快一点。于是我一头扎进去，开始各种尝试。
第一步：打开缓存开关
我最先想到的就是缓存。你想，同一个页面，每次都从网上重新拉一遍数据，那得多慢。我就去找相关的设置，果然让我找到了。把WebView的缓存策略给它一开，你别说，第二次打开同一个页面的时候，速度明显就上来了。因为它会把第一次加载的内容存本地，后面再访问就直接从本地读，快多了。
第二步：硬件加速搞起来
虽然缓存有点效果，但遇到那些动态内容多、或者CSS动画复杂的页面，还是有点力不从心，滑动起来还是会觉得涩涩的。后来我又了解到，可以让手机的GPU也来帮忙渲染网页内容，也就是所谓的“硬件加速”。默认情况下，这玩意儿可能没开，或者依赖系统。我就手动给它启用了。这么一搞，那些之前卡顿的动画和滑动，确实流畅了不少，感觉就像换了个新手机似的。
第三步：预加载，减少等待的尴尬
最让人头疼的还是第一次打开webview那个白屏时间。我就想，能不能在用户还没点到那个页面之前，就悄悄把webview给准备答案是肯定的！我试了下“预加载”技术。就是在App启动的时候，或者在用户即将进入某个包含webview的模块时，我先在后台偷偷摸摸地初始化一个webview实例，甚至让它先加载一个空白页（比如about:blank）。这样，等用户真的点进来需要显示网页的时候，这个webview已经是“热”的了，能大大减少那个冷启动的白屏时间。虽然是耍了点小聪明，但用户体验提升是实实在在的。
第四步：懒加载，减轻首屏压力
有些网页，特别是那种新闻详情页或者商品列表页，图片贼多。如果一上来就尝试把所有图片都加载完，那用户得等到猴年马月去。后来我就用了“延迟加载”或者叫“懒加载”的法子。简单说，就是页面刚显示的时候，只加载当前屏幕能看到的图片和内容，屏幕外面那些暂时还看不到的图片，先不加载。等用户往下滑，滑到快要看到那些图片的时候，再开始加载它们。这样一来，首屏内容能很快出来，用户就不会觉得等了半天啥也看不到。
第五步：跟后端兄弟们通个气
我还发现，有时候网页加载慢，不完全是客户端的事儿。如果网页本身就很大，图片没压缩，那客户端再怎么优化也费劲。我也会跟做前端和后端的兄弟们沟通，让他们那边也配合一下。比如，图片尽量用一些体积小点但效果还不错的格式，像是WebP；服务器那边也开个Gzip压缩啥的，把网页内容压缩一下再传过来，这样数据量小了，下载自然就快了。
一些其他的思考
我还考虑过一些更深入的东西，比如搞个WebView的“缓存池”。就是预先创建几个WebView实例放着，谁要用就从池子里拿一个，用完了再还回去。这样可以避免频繁创建和销毁WebView带来的性能开销。不过这个实现起来稍微复杂点，得看具体场景。
还有就是，如果有些资源是相对固定的，是不是可以考虑打包到App里，或者在App第一次启动时下载到本地，然后通过拦截WebView的请求，把这些网络请求直接导向本地资源。这样就能省掉很多网络交互的时间。
总结一下
搞webview优化就是个细致活儿，也是个不断折腾和学习的过程。从一开始被它的慢速和卡顿搞得焦头烂额，到后面一点点去尝试各种方法，像是启用缓存、开启硬件加速、玩预加载和懒加载、再到和服务端配合。虽然这些招数不一定能让webview的体验完美媲美原生，但至少能让它在大部分情况下跑得顺畅些，不至于让用户用得想摔手机。
这里面坑肯定还有不少，不同的业务场景、不同的网页内容，可能遇到的问题和适用的优化方案也不一样。关键还是得多动手实践，多总结经验。今天就先分享这么多，希望能对同样在捣鼓webview的朋友们有点启发。
