前言
在App的开发过程中，随着业务的发展，越来越多的公司会选择内嵌 WebView，但是便利性的同时，WebView 的性能却有着很大的问题，备受争议。
作为移动开发者应该从哪些方面去优化webView就一个很值得研究的话题。
从网页加载说起
我们从App中打开一个网页，到网页全部加载和渲染和显示完展现出来所需要花费得时间要比native长不少，这中间经历的阶段大致如下：
- WebView初始化
- 建立连接
- 接受页面和样式
- 页面渲染和脚本下载解析
- 后端处理数据
- 前端接受数据
- 渲染数据
在这几个阶段中网页会经历从无反馈、白屏、正在加载，对用户的使用体验是很差的。
优化分析
要对webView进行性能优化 应该针对性的对以上几个阶段所消耗的时间进行优化。
WebView初始化
当在App中第一次打开一个网页，系统首先做的并不是直接建立连接，而是启 动浏览器内核。所以第一次webView的初始化要花费大量时间。
优化方法：
- 提前初始化webview
- 客户端代理数据请求
提前初始化webview可以分为：
- 提前初始化全局webView
当App刚启动时就初始化全局webView并隐藏，当用户访问了webView时，直接使用这个 webView加载对应网页。缺点是需要额外消耗内存。还有需要webView切换时需要清除页面痕迹，容易造成内存泄漏。
- 设置webView的缓冲池。
App启动后。在webView的缓冲池初始化多个webView。需要加载网页时可以去缓冲池中去取出新的webView。不需要时就可以直接销毁，同时初始化新的webView放进缓冲池中。缺点是相比而言需要更大的额外内存消耗。但是确保减少webView初始化消耗的时间和降低清除页面所造成的内存泄漏
- 客户端代理数据请求
在初始化的同时，通过 Native 来完成一些网络请求等过程，然后在回传给WebView，使得 WebView初始化不是完全的阻塞后续过程。
建立连接
在建立连接过程中主要消耗时间：
- DNS解析服务器地址
- 连接服务器
- 服务器处理数据
优化方法：
- 客户端采用统一的API域名。利用系统对DNS的缓存。减少每次请求的DNS解析时间。
- 服务器分段输出网页数据
页面渲染
通常情况下，CSS 不会阻塞 HTML 的解析，但如果 CSS 后面有 JS，则会阻 塞 JS 的执行直到 CSS 加载完成(即便 JS 是内联的脚本)，从而间接阻塞 HTML 的 解析。
优化方法：
1.CSS 的加载会在 HTML 解析到 CSS 的标签时开始，所以 CSS 的标签要尽 量靠前。
2.但是，CSS 链接下面不能有任何的 JS 标签(包括很简单的内联 JS)，否则会 阻塞 HTML 的解析。
3.如果必须要在头部增加内联脚本，一定要放在 CSS 标签之前。
WebView 性能优化总结
- WebView 初始化慢，可以在初始化同时先请求数据，让后端和网络不要闲着。
- 后端处理慢，可以让服务器分 trunk 输出，在后端计算的同时前端也加载网络
静态资源。 - 脚本执行慢，就让脚本在最后运行，不阻塞页面解析。
- 同时，合理的预加载、预缓存可以让加载速度的瓶颈更小。
- WebView 初始化慢，就随时初始化好一个 WebView 待用。
- DNS 和链接慢，想办法复用客户端使用的域名和链接。
脚本执行慢，可以把框架代码拆分出来，在请求页面之前就执行好。
网友评论