首页 > 代码库 > 提升HTML5的性能体验系列之五 webview启动速度优化及事件顺序解析

提升HTML5的性能体验系列之五 webview启动速度优化及事件顺序解析

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载入时间的方法。

一般webview载入要多久,开发者可以自己使用计时器计时,计算从开始载入到loaded的时间差。
但首页的载入速度开发者无法编程获得,5+runtime提供了首页的webview的载入时间,plus.runtime.launchLoadedTime。
这个time最大的用途是判断手机性能。
首页正常是本地页面,同样的首页在不同手机上loadedtime值是不同的,根据这个值,就知道了这台手机载入网页的速度到底多快。
这个速度与本地io性能有关,也与计算渲染能力有关。
根据这个值,我们可以做很多优化。
比如在一些高性能手机上,载入新窗体很快,导致出现雪花闪一下又立即消失的情况,此时就没必要让雪花出现了,直接切屏就好了。而低性能手机即loadedtime值较低的则老老实实转雪花。

App的启动加速技巧

首页的配置几乎都是在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启动速度优化及事件顺序解析