Real-world problems with form switching white screen
The performance of HTML5 is much worse than that of native, such as white screen when cutting pages, scrolling is not smooth, drop-down refresh and pull-up page lag.
On low-end Android phones, many of the features and experiences common to native apps are hard to emulate with HTML5 technology.
Let's first look at the first question, how to avoid cutting page white screen.
Browser page when switching, due to its page loading mechanism, in the jump to the next page, the first to request networking, loading page code, building the DOM, rendering, and finally displayed.
A white screen of dozens of milliseconds or even a few seconds will appear before the final result is rendered. The native app is not the problem.
Although the use of the SPA single-page application model, that is, ajax+div switch can also avoid white screen, but all the pages written in a spa page, the page more than the mobile phone can not run up, and engineering big code that mess ... The man who has been in the pit is naturally aware.
4 ways to resolve form switching white screen
Standard HTML5 cannot be solved, we use the means of extension.
Html5+ is a set of enhanced HTML5 specifications that can invoke the hundreds of thousands of native API with JS.
To solve the problem of page white screen, we need to use the Plus.webview class to do the MPA multi-page application.
Plus.webview class is the native WebView object of the JS package, using JS can operate webview.
The principle of solving white screen is: treat each page as a webview, but use JS to control it just like control div.
Because WebView can be created implicitly, the background loading content, and when loading is complete with the JS event notification, we can after the new page loading completed and then moved to the screen by animation, so as to avoid white screen.
At the same time, WebView is independent of each other, there will be no different page JS and CSS conflicts under the spa.
There are several common practices for avoiding page white screen by manipulating WebView:
One is called preload, that is, the background pre-load the new page of HTML files and resources, when used to directly call up this has been created a good webview;
Another is called the current download, that is, click on the front page of the link to start the waiting circle, while the background began to load the full new page, loaded and then use the JS control display to the foreground.
There is also a kind of called separate loading, which will then be said in detail.
-1, pre-loaded
The so-called preload, that is, the background to pre-load the new page of HTML files and resources, when used to directly call out this has been created a good webview.
Hello MUI, CSDN, 36KR and other project source code, have used the pre-loaded ideas.
Take the news app as an example, start loading the list page first, then create a hidden webview in the background and load a content template Show page.
When you click on a news item on the list page, call WebView's form to control the animation and slide the show page into the screen.
But the show page is just a template with no data, and when the show page just slides into the screen, there is a "load" prompt on the show page.
Immediately after the show page starts executing the AJAX request, the network loads the data and displays it.
We can move the form while the item in the list page is clicked, and notify the new page to perform Ajax. WebView communicate messages to each other using the WebView Evaljs method.
This approach, the equivalent of the user is on the new show page to wait for networked data.
The sample code is as follows:
VarWebviewshow;Document.AddEventListener(' Plusready ', function(){ //extended JS object after Plusready can use Webviewshow =. Webview. Createfunction clicklist (id { //list click on the event after item Span class= "PLN" > Webviewshow. ( "slide-in-right" ,150 } /span>
In the MUI framework, this process is simplified encapsulated and controlled using the preload parameter. Reference: http://dcloudio.github.io/mui/javascript/#preload
Preload, because it is not displayed, does not increase the resource usage too much. (not more than 3 webview on the screen, WebView not more than 20 hidden in the background)
If the list goes to content, the different item clicks are just a page and can be fully preloaded.
But if the page is different and more, the background preload too much webview will be a bit slow. The slowness here is not to cause the phone to slow, but the preload is time-consuming.
Hello h5+ This example uses pre-loading techniques, and some Web pages are preloaded when they are started. When you click to these pages, the switch will be very fast.
The reason is not to preload all the pages, not enough memory, is not enough time.
When you preload these pages, the CPU consumption of the phone is higher, and if you swipe the list, you will find that the slide is not smooth.
To avoid this problem, the first page of Hello h5+ is deferred, and a few pages waiting to be preloaded are completed before calling Plus.navigator.closeSplashscreen () to close the boot cover picture.
If you pre-load too many pages, waiting for all the pre-loaded end before entering the home page, will cause the app to start very slow.
-2. Current download
The so-called current download, is the user click on the background to create WebView load new page full content, rendering and then display to the foreground
Sometimes we can not use preload, in order to avoid white screen, it is necessary to wait for the new WebView after the completion of the animation to move it in.
When you click on item on the list page, a wait box is first popped through plus.nativeUI.waiting ().
Create a webview in the background and load the show page.
The show page gets data in the background network.
The show page has two ways to notify the list page after the data is parsed and rendered.
One is the loaded callback of the webview that registers the show page on the list page, and the loaded event is automatically triggered after the new WebView loading is complete.
Another is in the show page of the appropriate JS location through the Evaljs method to notify the list page to close the waiting box, and perform a form switch shows the show page.
Of course, the show page can also not notify the list page, but instead of directly close the waiting box, and call the form switch animation to show itself.
The sample code is as follows:
functionClicklist(Id) { List click the event after item VarNwaiting=Plus.Nativeui.Showwaiting();Show native Wait boxWebviewshow=Plus.WebView.Create("Show.html");Create WebView in the background and open show.htmlWebviewshow.AddEventListener ( "loaded" , function< Span class= "pun" > () { //register onboarding completion events for new WebView Nwaiting.//new webview after loading is complete, close the wait box Webviewshow. ( "slide-in-right" ,150 //to display the new WebView form, showing the animation effect to the right of 150 milliseconds to move into the animation }, false); /span>
It is important to note that in order to reduce the wait for form switching, the WebView create method is generally not used after a click, because the creation process also has time consumption.
A good way to do this is to create a webview in advance and use the WebView Loadurl method to load the page.
If a white screen appears in the middle, it can be resolved by delaying the display of the new WebView.
At present, the official demo demo, the new WebView into the new WebView in the loaded callback, this time is equivalent to the new page domcontentloaded time, that is, Dom tree completed but the page may not be rendered complete.
At this point you can settimeout delay the display of the new WebView animation, or simply do not display the animation in the parent page, but in the lower page of onload or you think the page has been rendered time to manipulate the sub-page animated display.
-3, head and body separately loaded
Knowing both of these ways, we can play something more complicated.
The general form is composed of 2 parts, the top of the title bar (with the return button) and the middle of the content area, or called the body area.
We divide it into 2 webview, one is called Webviewhead, and the other is called Webviewbody. (The name is casual, convenient for reference below)
We can pre-load webviewhead on the homepage, loading a head.html page, the HTML above is the title Content +back button or other menu button, between the body area only one line of words "Loading ..."
Then pre-load a webviewbody, put it on the first.
When you click the Toggle form, the Webviewhead is moved directly into the window using the form animation, and the user will see a new interface showing the words loaded.
At the same time JS code operation Webviewbody Loadurl, to it load you need to load the page, waiting for this webview loaded trigger, then append it into Webviewbody.
In this way, you can do not preload, but also allows users to feel as much as possible the form of smooth switching.
Hello MUI for form switching, in this way. You can go to see its implementation code.
The use of this method is to note that: the background color of the body area of the head.html and the background color of the page loaded in the Webviewbody should be unified, so that webviewbody append to Webviewhead will not be abrupt.
Additionally, the head and body are loaded separately, and the body display is slightly delayed. If the body is static content, on iOS because of good performance, HTML page switch is faster, in fact, head and body merged into a page directly loaded join faster.
-4, Pre-
Preload avoids white screen, but sometimes the form animation is not as smooth as expected, some new forms are moved into the process, and the web is constantly getting data, redrawing the interface, causing the form to feel stuck in the process, and an advanced technique is animation.
From HBuilder6.1 onwards, the 5+ runtime provides a Plus.nativeObj.Bitmap object, while the WebView object provides a way to save the WebView display area to the bitmap object. In addition, WebView's animation method supports bitmap, which provides developers with a means of tuning performance.
We can pre-load a webview, and then put this webview down, and then in the animation parameters in the form to pass in to save the bitmap object, so that when the form moves, the move is not webview, but moving the picture, which can make the form animation much smoother.
Of course, this program is not omnipotent, it has pros and cons, and thus has its own application scenario.
After the figure is fixed, the form animation process, the diagram will not change, if the webview itself in the change or outside through the Evaljs in control of its changes, the animation process can not be reversed,
Comparison and application scenarios of several forms switching modes
We understand the principle of webview, in fact, can be flexible according to their own needs to apply WebView.
But let's summarize the 3 scenarios that were mentioned before, and of course we'll mention the spa scenario.
1. If the app is similar to a list of news or documents, each list item is clicked to open the same page. You should use the Preload method to preload directly, and then update the data on the show page with the AJAX request server.
2. If it is similar to nine Gongge navigation, or each list item goes to a different page, if the number of pages is less than 10, you can pre-load these 10 webview at startup.
If there are too many pages to preload, it is recommended to split the navigation into level two navigation.
For example, a nine with tab or segment, or a level two navigation list, is preloaded when you expand level two navigation.
If the business scenario is appropriate, you can also do a smart preload to determine the user's free time and the next page that might be clicked to preload. Of course, a master can handle such complex code.
3. If the page cannot be preloaded due to various conditions, at least the preload can be part of the pre-loaded, the remaining as follows:
3.1 A simple page where the local page is not networked.
For example, many software settings interface, its internal level two page jump, the content is very simple, also do not involve the problem of regional rolling card, the spa is better. Actually the spa is not useless, it is suitable for use in this scenario is better. Of course, although the experience is good, but an app will be a MPA, a spa, the general developers may be dizzy. Advanced developers who seek the ultimate experience can get the best user experience with a mix of MPA and spa, with the long reach of the family.
And for ordinary developers, in fact, the unified use of head and body separate multi-webview way its effect can also be commercially available.
In the Hello Mui, there is a setting template below, which is a sample of a spa. On iOS, the effect of this sample can be completely native, and the gradient on the top title bar is cool.
3.2 If the local page does not involve networking but a drop-down refresh or an extra-long complex graphic list, then the head and body are loaded separately in a better way.
Because the spa's complex div scrolls and the dropdown refreshes in the low-end Android phone very card.
For example, some list pages, local cache content, from Websql and other local databases to load content, the way to update the data by a drop-down refresh, the design of such a page itself should be double webview.
3.3 If it is a Web page to get content, use head and body separately to load the more appropriate
If you cut a page, wait for the new page to load, the new page load and wait for the network to load the data, 2 consecutive waiting boxes will be offensive to users.
Anyway is to wait for networking, simply and wait webview load together wait.
First move the preloaded webviewhead into the screen, and then wait for the webviewbody to load the HTML and the Internet to get the data, and then load the Webviewbody to the main webview.
form function Encapsulation for the MUI framework
The MUI framework simplifies encapsulation of some common form models in order to simplify the work of form management.
However, for complex form switching, it is still necessary for the developer to understand the form switching principle mentioned above.
The Init method of MUI, which encapsulates the preload and subpage through parameters, allows for convenient preload webview, and for the dual Webivew interface of head and body separation, subpage can also be conveniently controlled by webviewbody parameters.
MUI's Openwindow method, encapsulates the display waiting, loads new pages, processes animations, closes waiting, and so on.
The back style control of the MUI, which automatically encapsulates the hiding and closing of the form.
These methods refer specifically to the JS API for MUI.
Hello h5+ and hello mui for form switching comparison
Both Hello h5+ and hello mui are simple local static pages, but the number of pages is so large that it is not possible to preload them all.
So a lot of actual apps can be preloaded to achieve a better form transition than the 2 sample apps.
The transition strategy for Hello h5+ is:
1. Preload some common ones, such as the first 2 WebView of the main list, and the webview of the form toggle and pull-down refreshes.
2. Other forms use the "Download Now" mode, that is, click on the item immediately after the waiting, and then load the webview in the background, loading is completed and moved into the screen.
The transition strategy for Hello MUI is:
The overall use of head and body separately loaded mode.
Look at 2 examples from an intuitive experience, and the Hello h5+ works better on iOS. On Android, it's not the same.
However, the design of static samples and the actual business scenarios, because the actual business of a large number of networked content, so the head and body separately loaded more practical.
The MUI encapsulates a template design that is loaded separately from the head and body, while the Hello h5+ is just an API demo that does not encapsulate, so the 2 example transitions differently.
MUI for form switching, here's a separate article describing http://ask.dcloud.net.cn/article/106
White screen after starting the homepage
There is no pre-loaded concept on the home page.
Start the picture of the cover to turn off the trigger condition, which is turned off by default on the first page of the WebView loaded event.
If the main page content or after the network, frame loading after the screen redraw, that is, after the first page of HTML domcontentloaded can not immediately render the interface, the start of the cover picture disappears, the page has not been rendered good.
You need to manually control the cover picture to disappear at this time.
First found in the project Manifest.json Plus, SplashScreen, AutoClose node, set to False, that is, manually control the disappearance of the cover picture.
Then in the home page suitable location, generally in the network and constructs the new DOM, calls JS closes the cover picture, Plus.navigator.closeSplashscreen ();
This will prevent the first page from white screen.
About when the Android phone returns, the page will be blurred after the clear processing method
To conserve system resources, when WebView is not visible, our engine will recycle its rendering resources by default.
If the page is complex and slow to render, it may cause the problem to be blurred before it is returned with too late rendering.
At this point, or optimize the page wording, speed up rendering. Or use the APIs we provide to make webview not remove rendering resources as they are not visible.
Specific API address see Plus.webview in the Webviewstyle object of the render parameter, render set to always do not remove the rendering, solve the problem of ambiguity. Http://www.html5plus.org/doc/zh_cn/webview.html#plus.webview.WebviewStyle
In addition, starting from HBuilder5.8, the new Android introduced the Pop-in animation, the animation effect has been specially processed, on return will not be empty.
Questions about splash screens, choppy scrolling, and no video images caused by improper Android hardware acceleration configuration
5+runtime The default is to turn on Android hardware acceleration, but some Android non-Google official ROM hardware acceleration has bugs. In particular, some of the Android5.0 early ROM.
A separate article on this aspect of the treatment program, refer to HTTP://ASK.DCLOUD.NET.CN/ARTICLE/55
About pop-in squeeze animation and slide-in-right right moving picture trade-offs
Plus.webview offers a lot of toggle animations, up and down panning, fading, zooming, squeezing ... But the more commonly used animations are the right shift slide-in-right and the squeeze pop-in.
Generally on iOS, it is highly recommended to use pop-in, which is closer to the native experience.
On Android, actually also pop-in effect is better, but in order to achieve better effect, also need developer code Note Some writing, if write bad, effect is not as good as Slide-in-right
Here is pop-in animation use note: http://ask.dcloud.net.cn/article/225
Postscript
Regardless of which method you use, it is important to note that the HTML page of the mobile app must be sufficiently high-performing.
The page size is small, loading, and rendering faster.
On the internet there are many schemes to improve the performance of HTML, JS, CSS, no longer listed here.
But be careful not to use frames, if not necessary.
The popularity of web frameworks on PCs, and later when PC browser performance is high enough, developers in the early days of the internet are not as reliant on frameworks as they are today.
Mobile phones, especially the low-end Android performance is also very poor, if you write a PC Web-page thinking, the ultimate user experience will inevitably be very poor.
First of all, the AMD framework does not want to, including Angularjs, JS dynamic resolution tag replacement rendering is very slow.
Second, jquery, Zepto also try not to use. document.getElementById (""), Document.queryselectorall (""), $ (""), these three performance down, especially when traversing the DOM on low-end Android, When you have worked hard to reduce white screen and user wait time, you will be very angry with these JS frames dragging your hind legs.
And Hbuilder provides a lot of code blocks to quickly complete the code, such as tapping DG can be document.getElementById (""), than Knocking $ ("#") is much faster.
Of course, individual pages in order to use some of the existing jquery plug-in to reference the framework, will not have a large impact on the overall app, which requires the developers themselves according to the performance of the pursuit of the ultimate degree to grasp the
Improve HTML5 's performance experience one of the series avoid cutting pages white screen