AndroidWebView性能分析与优化
⼀、简介
⼀提到App内的WebView加载⽹页，⼤家的第⼀印象就是：慢、耗流量、体验⽐原⽣差。但WebView加载⽹页也有其天⽣的优势：动态，跨平台，开发周期短。
那能如何解决WebView加载⽹页慢和体验差的问题呢？可以思考下⾯两个问题：
从打开浏览器到⽹页完全展⽰都发⽣了什么？
如何给WebView加载⽹页提速？
⼆、整体思维导图
网页app三、衡量标准
快慢是⼀个相对量，如何衡量WebView的快慢呢？
3.1 ⽤户体验的时间尺度
从⽤户⾓度来看，如下图是2018年份百度移动端的统计数据：
根据上⾯的统计折线图，得出如下表格：
可以发现：
⼩于1s，⽤户更容易接受，关闭率更低。
⽤户对移动端的容忍⽐PC端更低，要求更⾼。
3.2 加载时长标准
加载时长 = 加载结束 - 加载开始
加载开始很好界定，当⽤户点击feed流⾥⾯的item开始，就开始计时。
加载结束呢？WebView有个WebViewClient#onPageFinished回调⽅法，这个⽅法是在页⾯完全加载结束时候回调的，但是页⾯DOM渲染完页⾯就已经有内容，对于⽤户来说算是页⾯已经展⽰出来了。统计加载时长以DOM渲染完更好些。
3.3 统计标准
通过收集真正的⽤户使⽤数据，才能更好的根据⽤户的情况进⾏优化。那如何才能反应⽤户的真实情况呢？
通常有两种⽅式：
平均数，容易被较长的加载时间给拉⾼，不容易反应真实情况。
中位数，能很好的反应⼤多数⽤户的情况，但是中位数的要求较低，可以将其提⾼到80分位，或者90分位。
在们项⽬进⾏数据统计时候可以先采⽤80分位，检测下优化效果，后续再提⾼要求，使⽤更⾼分位如95分位等。
根据现⽹数据可知，当95分位的⽤户页⾯加载时长为1s以内时，80分位的⽤户页⾯加载时长为0.35s以内时，APP内⽹页的体验最佳。具体最佳时间可以根据真实的上报数据的统计结果进⾏调整。
四、问题分析
前端页展⽰⼀般分两种：
前后端分离，前端加载资源后，通过js请求展⽰的数据并在前端渲染展⽰。
页⾯直出，页⾯数据由服务器填充完成后，直接下发到前端，由前端直接展⽰。
现在较多的采⽤前后端分离的⽅式，下⾯都以这种⽅式为例讲解。
4.1 WebView渲染过程
WebView渲染⼤致需要如下⼏步：
解析 HTML ⽂件
加载 JavaScript 和 CSS ⽂件
解析并执⾏ JavaScript
构建 DOM 结构
加载图⽚等资源
页⾯加载完毕
4.2 WebView耗时统计⽅法
统计可从两⽅⾯⼊⼿，⼀是⽹页层统计，⼆是App层统计。
4.2.1 ⽹页层统计：WebView中⽹页耗时统计⽅法
WebView加载url到完全展⽰出各个部分耗时情况，可以根据中⽹页performance参数获取具体耗时统计参数信息，详细的页⾯加载过程见下图：
根据performance统计情况可以得出如下数据：
重定向耗时：redirectEnd - redirectStart
DNS查询耗时 ：domainLookupEnd - domainLookupStart
TCP链接耗时 ：connectEnd - connectStart
HTTP请求耗时 ：responseEnd - responseStart
解析dom树耗时 ： domComplete - domInteractive
⽩屏时间 ：responseStart - navigationStart
DOMready时间 ：domContentLoadedEventEnd - navigationStart
onload时间：loadEventEnd - navigationStart，也即是onload回调函数执⾏的时间。
4.2.2 App层统计：App层统计WebView耗时

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。