Improve HTML5 Performance Experience series five WebView start-up speed optimization and event sequence resolution

WebView loaded with 5 events. The triggering sequence is loading, titleupdate, rendering, rendered, loaded.
WebView triggers loading when the page starts loading
If the <title> node has been parsed and given a new value during onboarding, Trigger Titleupdate,
The page starts rendering, triggering rendering,
Page rendering completed, triggering rendered,
Page loading completes triggering loaded.

Loaded is often used to determine whether the page is loaded, and the new page is displayed when loading is complete.
However, sometimes the page content is very long, all loading is slow, resulting in a slow display of the new form. In order for the new form to open quickly, we can display the new form when titleupdate.
Because the Web page itself has the mechanism of step rendering, so as long as the first screen before scrolling finished rendering will not let users see white screen.
In the 2014, mobile phones generally have slower rendering capabilities, so to avoid white screens, the official framework and examples are the loaded show page by default. But by the year 2016, the performance of the mobile phone has improved, on most phones titleupdate when the show new page will not trigger white screen, and faster than loaded, in order to improve the screen speed, the official MUI Unified into the Titleupdate show a new page.
If the page is loaded from the server online, or if the local page is very complex rendering is slow, at this point the titleupdate may still be white screen, the need to use rendering or rendered event to avoid white screen.

Why are rendered and loaded 2 events?
In fact, there are almost no differences between the 2 events on a purely local page. But sometimes the page will introduce some of the lower priority external network JS, such as statistics JS, once the network response is slow, or simply invalid reference, although the page rendering is finished, but the loaded will trigger very slow, until these network JS also loaded or timed out before triggering.

Someone asked for the order of the 3 events in the loaded of the plus ready and webview, as well as the domcontentloaded in the HTML.
Plus ready is triggered when the loaded event occurs in the early hbuilder of WebView.
But with the progress of technology, the current strategy has changed.
On iOS, plus ready is already in the first place, just for backwards compatibility, because at the beginning of WebView, plus is in effect. The current trigger for the plus ready event on iOS is still compatible with the WebView loaded, but the plus is already available before the event is triggered.
On Android, plus ready defaults to webview loaded, but the 5+ API is available in advance as follows: http://ask.dcloud.net.cn/article/921. If the developer uses this article to configure the method to take effect in advance, although the execution time of the plus ready is not changed, the plus API can be used after titleupdate.
Note: After the plus comes into effect, it's dangerous to manipulate the DOM in the plus ready, because Plus is faster than domcontentloaded, causing the DOM to be unprepared. The DOM is now operational, or after domcontentloaded. Plus the early entry into effect will make the page itself's JS execution time dozens of to hundreds of milliseconds, this use should pay attention to.

Note: The above events need to be written in different webview when the actual code is listening.
Because the new webview in the plus ready time is later than the WebView loading, titleupdate, so in the new WebView with the plus API to listen to these 2 events is not the first open to listen.
The new WebView loading and titleupdate can only be monitored in the old webview.

Note: If the page is a Web page and a server jump occurs, it is possible to trigger multiple titleupdate.

Note: On individual domestic phones, the Titleupdate event is not triggered if the content of the page's title node is empty.

Provides a way to judge WebView loading time.

General WebView How long it takes to load, developers can use their own timer to calculate the time difference from the start load to the loaded.
But the loading speed of the home page developers can not be programmed to obtain, 5+runtime provides the first page of the WebView loading time, plus.runtime.launchLoadedTime.
The biggest use of time is to judge the performance of the phone.
Home Normal is a local page, the same home on different phones loadedtime value is different, according to this value, you know how fast this mobile phone loading page.
This speed is related to native IO performance and also to computational rendering power.
Based on this value, we can do a lot of optimizations.
For example, on some high-performance mobile phones, loading a new form quickly, resulting in a snowflake flash and immediately disappear, there is no need to make snowflakes appear, directly cut the screen is good. Low-performance phones, which are loadedtime low, turn snowflakes honestly.

App Start-Up tips

The configuration of the home page is almost all done in manifest, with good manifest to optimize the app startup speed.
1. The top of the first page title, in the manifest configuration Laucherwebview Navigationbar, describes the title of the background color, text and other styles, because it is the original drawing, much faster than WebView.
2. If there is a tab at the bottom, we recommend using double home. Double home is a very interesting mechanism, in manifest configuration, Dcloud engine will open 2 webview at the same time, instead of waiting for a webview plus to take effect, then create another webview by JS. In manifest configuration Secondwebview, the tab page is loaded by Laucherwebview, and the content page of the first tab is loaded Secondwebview.
tab that webview inside suggested loading a very vegetarian HTML, do not draw external CSS and JS, also do not rely on JS rendering, simple JS register Click to switch events, do not let plus in advance. (We say webview rendering is much slower than native, in fact, the pot is mainly JS back, if the page rendering is very simple html,webview and native rendering speed gap will be greatly reduced.) ）
3. Then manifest configuration splash Shutdown Time is titleupdate, can close splash very early.
In the upcoming HBuilder8.2, Subnview will be supported, a technology that can introduce more native rendering content on the screen, making the page render faster.

To provide some other settings that affect app startup:
If the RunMode is set to decompression mode, the first boot after installing the APK need to first extract JS and other resources to SDcard, here is a time-consuming. The second start is good.

Improve HTML5 Performance Experience series five WebView start-up speed optimization and event sequence resolution