本篇文章是基于 腾讯X5内核 WebView 实践的总结篇，较上篇文章更为完整，具体。
onPageFinished() 回调时机
通过 WebView 的回调函数，分析 onPageFinished() 回调时机
加载某个网址的Android端回调监测如下：
shouldOverrideUrlLoading time: 1519274808392
onPageStarted: time: 1519274808561 // 169ms
onPageFinished time: 1519274809735 // 1174ms
onReadableCallback: false
shouldOverrideUrlLoading time: 1519274811067 --url :native://document/ready
onReadableCallback: true
onPageFinished time: 1519274817879 // 9318ms
onReadableCallback: true
据上数据分析：
第一次onPageFinished()回调触发是在 1174ms (较onPageStarted()方法)
第二次onPageFinished()回调触发是在 9318ms
通过 chrome://inspect监测的资源加载时序
Network 面板突出显示两种事件：DOMContentLoaded 和 load
解析页面的初始标记时会触发 DOMContentLoaded。 此事件将在Network 面板上的两个地方显示：
- Overview 窗格中的蓝色竖线表示事件。
- 在 Summary 窗格中，您可以看到事件的确切时间。
页面完全加载时将触发 load。此事件显示在三个地方：
- Overview 窗格中的红色竖线表示事件。
- Requests Table 中的红色竖线也表示事件。
- 在 Summary 窗格中，您可以看到事件的确切时间。
分析上图：
-
DOMContentLoaded和load事件触发时机与Android端的回调触发时机不一致。 - 第一次
onPageFinished()方法的调用和document类型文件加载完成时间相近，且经过多次测试是在该文件加载完成后调用。 - 第二次
onPageFinished()方法回调时间和load时间相近。
初步总结：
- 第一次
onPageFinished()方法是在document类型文件加载完成后调用的。 - 第二次
onPageFinished()方法是在load完成时回调。 - 通过仔细查看
shouldOverrideUrlLoading和onPageStarted方法时间差以及 图中 Overview 栏，会发现加载网页不是第一时间去请求数据的。所以onPageStarted()方法较触发是有一定的延迟时间。
ready 替换 onPageFinished 实现
据上分析的结果我们会发现，onPageFinished()方法会调用多次，所以，如果我们将业务逻辑放到该方法中执行，如果不做控制，势必会出现一些问题。当然，由于网页类型的多样性，即使做了控制，依然会在特定的页面出现问题。
那么我们如何摆脱对onPageFinished()的依赖呢？
网页的加载状况，前端肯定会有生命周期的感知，那么我们为什么不依赖前端的通知来触发Native逻辑呢？
通过上述的思考，Native的事件触发完全交给前端去主动调取，而不是通过不靠谱的WebView回调。在前端的$.ready()方法中去通知移动端开始执行业务逻辑。
并且这种方式在时序性能方面有很大提升，比第二次onPageFinished()触发时机早很多（在较为复杂的页面相差更大）
单页应用
上面我们通过 ready() 的主动通知，实现了 onPageFinished() 方法中业务逻辑的优化。
但是，在单页应用的网页中，$.ready() 只在主页面渲染完成时触发一次，在子页面并不会触发，而且，WebView 的 shouldOverrideUrlLoading() 及 onPageStarted() 方法都不会回调。在一些单应用网页会触发 onPageFinished() 方法，它去请求了新的资源，所以我们感知到了回调。而个别网页并没有去请求新的资源，直接对资源进行了替换，这种情况，我们就感知不到 onPageFinished() 的回调。
当然，如果开发自己的页面就不存在这些多情况的处理，可以协商解决方案。
本文的主要实现是基于第三方网页做的功能扩展，所以需要考虑这些兼容性问题。
给出不成熟的参考方案：
- 前端
url变化监听，通知移动端页面变化。 - 在
onPageFinished()方法中再去做一个保底操作，损失一部分性能换取用户的响应速度。
Js 注入时机以及时序控制
网络上的普遍做法是在 onPageFinished() 中注入 Js 脚本。
这种做法存在一些问题：
可能会注入多次。
onPageFinished()第二次调用时机很迟，在复杂的页面性能损失很大。
如果注入太多，会影响页面的体验。
由于项目注入的脚本行数达到 1W+，所以我们需要对时序做一些优化。保证调用时我们已经完成了注入。
这里我们主要注入生成一个 script 标签。
webView.loadUrl("javascript:(function() {" +
"var scriptElement = document.getElementById('readability-script');" +
"var parent = document.getElementsByTagName('body').item(0);" +
"if(parent && !scriptElement) {" +
"var script = document.createElement('script');" +
"script.type = 'text/javascript';" +
"script.id = 'readability-script';" +
// Tell the browser to BASE64-decode the string into your script !!!
"script.innerHTML = window.atob('" + mAssetsScript + "');" +
"parent.appendChild(script);}" +
"})()");
通过控制标签的唯一性来防止注入多次； 在页面初始化前完成本地 js 脚本的文件读取；不断尝试注入直到可以注入为止。
在 onProgressChanged() 回调中，不断的尝试读取节点注入脚本。
通过最开始对 onPageFinished() 的分析。是否可以尝试在第一次回调时开始注入脚本。但是，不能保证每个网页都会回调两次onPageFinished()。
通常情况下，CSS不会阻塞HTML的解析，但如果CSS后面有JS，则会阻塞JS的执行直到CSS加载完成（即便JS是内联的脚本），从而间接阻塞HTML的解析。
资源加载回调
在研究WebView加载时序时发现了这个资源加载的回调onLoadResource()。这里简单介绍下，针对这个回调，可以做的事情很多。
在加载页面资源时会调用，每一个资源（比如图片）的加载都会调用一次。
webView.setWebViewClient(new WebViewClient(){
@Override
public boolean onLoadResource(WebView view, String url) {
}
});
可以实现预加载及手动缓存的功能。优化用户体验并且减少多次访问造成的流量浪费。
调试
可以参考这篇文章
打造最舒适的 WebView 调试环境
