本文主要是介绍APP中WebView性能优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
从程序上观察，WebView启动过程大概分为以下几个阶段：
1、WebView初始化
当App首次打开时，默认是并不初始化浏览器内核的；只有当创建WebView实例的时候，才会创建WebView的基础框架。所以与浏览器不同，App中打开WebView的第一步并不是建立连接，而是启动浏览器内核。优化方法：
1、全局WebView方法：
在客户端刚启动时，就初始化一个全局的WebView待用，并隐藏；
当用户访问了WebView时，直接使用这个WebView加载对应网页，并展示。
这种方法可以比较有效的减少WebView在App中的首次打开时间。当用户访问页面时，不需要初始化WebView的时间。当然这也带来了一些问题，包括：
额外的内存消耗。
页面间跳转需要清空上一个页面的痕迹，更容易内存泄露。2、客户端代理数据请求方法：
在客户端初始化WebView的同时，直接由native开始网络请求数据；
当页面初始化完成后，向native获取其代理请求的数据。此方法虽然不能减小WebView初始化时间，但数据请求和WebView初始化可以并行进行，总体的页面加载时间就缩短了；缩短总体的页面加载时间：
2、建立连接/服务器处理
在页面请求的数据返回之前，主要有以下过程耗费时间。
DNS
connection
服务器处理优化方法：
1、DNS采用和客户端API相同的域名DNS会在系统级别进行缓存，对于WebView的地址，如果使用的域名与native的API相同，则可以直接使用缓存的DNS而不用再发起请求图片。以美团为例，美团的客户端请求域名主要位于api.meituan.com，然而内嵌的WebView主要位于 i.meituan.com。当我们初次打开App时：
客户端首次打开都会请求api.meituan.com，其DNS将会被系统缓存。
然而当打开WebView的时候，由于请求了不同的域名，需要重新获取i.meituan.com的IP。
根据上面的统计，至少10%的用户打开WebView时耗费了60ms在DNS上面，如果WebView的域名与App的API域名统一，则可以让WebView的DNS时间全部达到1.3ms的量级。
静态资源同理，最好与客户端的资源域名保持一致。2、同步渲染采用chunk编码同步渲染时如果后端请求时间过长，可以考虑采用chunk编码，将数据放在最后，并优先将静态内容flush。对于传统的后端渲染页面，往往都是使用的【浏览器】--> 【Web API】 --> 【业务 API】的加载模式，其中后端时间就指的是Web API的处理时间了。在这里Web API一般有两个作用：
确定静态资源的版本。
根据用户的请求，去业务API获取数据。
而一般确定静态资源的版本往往是直接读取代码版本，基本无耗时；而主要的后端时间都花费在了业务API请求上面。那么怎么优化利用这段时间呢？在HTTP协议中，我们可以在header中设置 transfer-encoding:chunked使得页面可以分块输出。如果合理设计页面，让head部分都是确定的静态资源版本相关内容，而body部分是业务数据相关内容，那么我们可以在用户请求的时候，首先将Web API可以确定的部分先输出给浏览器，然后等API完全获取后，再将API数据传输给浏览器。如果采用普通方式输出页面，则页面会在服务器请求完所有API并处理完成后开始传输。浏览器要在后端所有API都加载完成后才能开始解析。
如果采用chunk-encoding: chunked，并优先将页面的静态部分输出；然后处理API请求，并最终返回页面，可以让后端的API请求和前端的资源加载同时进行。
两者的总共后端时间并没有区别，但是可以提升首字节速度，从而让前端加载资源和后端加载API不互相阻塞。3、页面框架渲染
页面在解析到足够多的节点，且所有CSS都加载完成后进行首屏渲染。在此之前，页面保持白屏；在页面完全下载并解析完成之前，页面处于不完整展示状态。进一步分析可以发现，页面的header部分有这样的代码：
.....
<link href="//ms0.meituan.net/css/eve.9d9eee71.css" rel="stylesheet" onload="MT.pageData.eveTime=Date.now()"/>
<script>
window.fk = function (callback) {
require(['util/native/risk.js'], function (risk) {risk.getFk(callback);
});
}
</script>
</head>
....通常情况下，上面代码的link部分和script部分如果单独出现，都不会阻塞页面的解析：
CSS不会阻止页面继续向下继续。
内联的JS很快执行完成，然后继续解析文档。然而，当这两部分同时出现的时候，问题就来了。
CSS加载阻塞了下面的一段内联JS的执行，而被阻塞的内联JS则阻塞了HTML的解析。通常情况下，CSS不会阻塞HTML的解析，但如果CSS后面有JS，则会阻塞JS的执行直到CSS加载完成（即便JS是内联的脚本），从而间接阻塞HTML的解析。优化一个小小的内联JS放错位置也会让性能下降很多。
CSS的加载会在HTML解析到CSS的标签时开始，所以CSS的标签要尽量靠前。
但是，CSS链接下面不能有任何的JS标签（包括很简单的内联JS），否则会阻塞HTML的解析。
如果必须要在头部增加内联脚本，一定要放在CSS标签之前。
4、JS加载
偏重的框架，例如React，仅仅初始化的时间就会达到50ms ~ 350ms，这在对性能敏感的业务中时比较不利的。
在App的启动周期内，统一域名下的代码会被缓存编辑和初始化结果，重复调用性能较好。所以，在移动浏览器上，JS的解析和执行时间并不是不可忽略的。在低端安卓机上，（框架的初始化+异步数据请求+业务代码执行）会远高于几KB网络请求时间；高性能的Web网站需要仔细斟酌前端渲染带来的性能问题。优化
高性能要求页面还是需要后端渲染。
React还是太重了，面向用户写系统需要谨慎考虑。
JS代码的编译和执行会有缓存，同App中网页尽量统一框架。这篇关于APP中WebView性能优化的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
