标签：有趣 update 文字 复杂 ready 手机 article 准备 其他
webview加载时有5个事件。触发顺序为loading、titleUpdate、rendering、rendered、loaded。
webview开始载入页面时触发loading，
载入过程中如果<title>节点已经解析并赋予新值，触发titleUpdate，
页面开始渲染，触发rendering，
页面渲染完毕，触发rendered，
页面载入完毕触发loaded。
loaded常用于判断页面是否载入完毕，载入完毕才显示新页面。
但有时页面内容很长时，全部载入完毕比较慢，导致显示新窗体比较慢。为了让新窗体打开快点，我们可以在titleUpdate时就显示新窗体。
因为网页本身有分步渲染的机制，所以一般只要滚动前的第一屏页面渲染完毕就不会让用户看到白屏。
在2014年，手机普遍的渲染能力较慢，所以为避免白屏，官方的框架和示例默认都是loaded时show页面。但到了2016年，手机的性能有更高的提升，在大多数手机上titleupdate时show新页面也不会触发白屏，并且比loaded更快，为了提升切屏速度，官方mui统一调整成了在titleupdate时show新页面。
如果是从服务器在线载入页面，或者本地的页面非常复杂导致渲染很慢，此时titleUpdate时仍然可能白屏，此时需使用rendering或rendered事件可避免白屏。
为什么rendered和loaded是2个事件呢？
其实在纯本地页面时这2个事件几乎没区别。但有时页面里会引入一些优先级较低的外部网络js，比如统计js，一旦网络响应慢，或者干脆是无效引用，虽然页面渲染完了，但loaded会触发的很慢，直到这些网络js也加载好或超时才触发。
有人问plus ready和webview的loaded、以及HTML里的DOMContentLoaded 这3个事件的顺序。
plus ready在HBuilder早期是webview的loaded事件发生时才触发。
但随着技术的进步，目前策略已经变化。
在iOS上，plus ready已经名存实亡，只是为了向下兼容，因为在webview最开始，plus就是生效的。目前iOS上plus ready事件的触发为保持向下兼容也是在webview的loaded时，但该事件触发之前其实plus已经可以使用了。
在安卓上，plus ready默认也是在webview的loaded时，但可通过如下方法，5+ API提前生效可用：http://ask.dcloud.net.cn/article/921。如果开发者使用了该文的方法配置了提前生效，虽然plus ready的执行时间没变，但在titleUpdate后就可以使用plus的api了。
注意：plus提前生效后，在plus ready里操作dom就变的危险了，因为plus ready快于DOMContentLoaded，造成dom还没有准备好。此时操作dom，还是得在DOMContentLoaded之后。同时plus提前生效会让页面本身的js执行时间推后几十至几百毫秒，这点使用时要注意。
注意：以上的事件在实际代码监听时，需要写在不同的webview里。
由于新开的webview里的plus ready时间晚于该webview的loading、titleUpdate，所以在新webview里用plus api监听这2个事件是监听不到初次打开的。
只能在老的webview里对新webview的loading和titleUpdate进行监听。
注意：如果页面是网络页面，并且发生服务器跳转，有可能触发多次titleupdate。
注意：在个别国产手机上，如果网页的title节点内容为空，不会触发titleupdate事件。
一般webview载入要多久，开发者可以自己使用计时器计时，计算从开始载入到loaded的时间差。
但首页的载入速度开发者无法编程获得，5+runtime提供了首页的webview的载入时间，plus.runtime.launchLoadedTime。
这个time最大的用途是判断手机性能。
首页正常是本地页面，同样的首页在不同手机上loadedtime值是不同的，根据这个值，就知道了这台手机载入网页的速度到底多快。
这个速度与本地io性能有关，也与计算渲染能力有关。
根据这个值，我们可以做很多优化。
比如在一些高性能手机上，载入新窗体很快，导致出现雪花闪一下又立即消失的情况，此时就没必要让雪花出现了，直接切屏就好了。而低性能手机即loadedtime值较低的则老老实实转雪花。
首页的配置几乎都是在manifest做，用好manifest才能优化好app的启动速度。
1.首页的顶部title，在manifest里配置laucherwebview的navigationbar，描述title的背景色、文字等样式，因为是原生绘制，要比webview快不少。
2.如果底部有tab，建议使用双首页。双首页是一个很有趣的机制，在manifest里配置，DCloud的引擎会同时打开2个webview，而不是先等一个webview的plus生效后通过js再创建另一个webview。在manifest里配置secondwebview，由laucherwebview加载tab页面，secondwebview加载第一个tab的内容页。
tab那个webview里面建议加载一个很素的HTML，不引外部css和js，也不依赖js渲染，简单的js注册下点击切换事件，也不要提前让plus生效。（我们说webview渲染比原生慢很多，其实锅主要是js背，如果页面渲染是很简单的HTML，webview和原生的渲染速度差距会大幅减少。）
3.然后manifest里配置splash关闭时间为titleUpdate，可以非常早的关闭splash。
在即将发布的HBuilder8.2中，将支持subnview，这个技术可以在屏幕上引入更多原生渲染的内容，让页面渲染更快。
在提供些其他影响app启动的设置：
如果设置了runmode为解压模式，安装apk后第一次启动时需要先把js等资源解压到sdcard，这里有个耗时。第二次启动就好了。
提升HTML5的性能体验系列之五 webview启动速度优化及事件顺序解析
标签：有趣 update 文字 复杂 ready 手机 article 准备 其他
原文地址：http://www.cnblogs.com/zcy123-com/p/6809461.html
