How big is the gap between the H5 implementation of APP and the native method, and how many pits? JS is king!

Although the development of pure H5 APP is much smoother than that of pure native development, there are still many problems in the final effect and performance compared with native ones, mainly in the following aspects:

1.

Animation There are many kinds of animations, such as side effects. The sliding in and out of the sidebar menu, the responsive animation of elements, the transition between page switching, etc., many implementation methods under H5 cannot achieve pure native performance. Generally, there are several different options: css3 animation, javascript animation, native animation.

CSS3 animation is very performance-intensive. If a certain element uses CSS3 animation, it may not be seen, but using CSS3 animation in a large area or in cutscenes will make the app experience very poor on low-end mobile phones. The best option is to call the underlying animation through the framework, but in any case, it is equivalent to wrapping a layer on the original code, and the performance will inevitably be affected.

For example, on the loading of a new page, if the underlying animation is called, there are two issues to consider, one is the rendering of the resource page itself, and the other is the acquisition of remote data. Even if these animations can respond quickly, a large number of CSS pages will cause rendering stuttering, and there may be a white screen/machine stuttering phenomenon when sliding in. To solve these performance problems, preloading or simulating animations must be used. Even so, there are still many problems with slide-in and slide-out animations on low-end Android machines. If the way to obtain server-side data processing is not appropriate, the phenomenon of stuck white screen will be more serious. See the following data acquisition method for details.

2. Acquiring server-side data The

first thing to accept is that the data acquisition here is done asynchronously on the resource page, because only in this way can these resource pages be preloaded or rendered. However, the data obtained asynchronously may involve DOM operation when filling the page. As we all know, DOM operation consumes a lot of performance. If the page is small, it is fine. If the page is slightly larger, the data is a little more complicated, and frequent DOM operations will lead to obvious flashing white. .

And the most important point is that if the data update speed is too slow after the page is loaded, it will also make the page template wait for a long time, which is not friendly to the user experience. .

If this problem is not solved, it is difficult for H5APP to handle large-scale data pages, and it is even more difficult to switch frequently among them, so some people will definitely think of using MVVM, relatively speaking, they obtain data and update them The method of data is more agile and scientific, but in the process of writing, you must pay attention to many problems unique to H5. These problems are discussed in the page switching below.

3. Page switching There are several good implementation methods

above , such as preloading and simulation animation, and even batch preloading, batch screenshot simulation animation, etc. Although it seems very friendly and solves many problems, in fact, if the page Enough is enough to raise another problem: the lifetime of the page.

Just imagine, if the guide page or the main page caches the resources of 5 sub-pages, when jumping to the corresponding sub-page, the lower-level page resources of these sub-pages will be cached. Repeating this will definitely occupy a lot of memory and degrade the experience of the APP. So how do you know which pages are needed, how many pages are cached at most, and when to end the life cycle of which pages? In many H5APP frameworks, there is no perfect answer to these questions, so in apps with more pages and more content, performance may be degraded due to these resource allocation problems.

At this time, let's look at the data loading problem of MVVM. In fact, no matter which MVVM framework, anyone who has written it knows that the most important problem in managing this new type of front-end code is the memory problem. You must ensure that the code is written elegantly enough. For any memory leak problem, it is also necessary to consider whether their controller/page resources are released at the end of the page life cycle, whether this has any impact on the whole world, and reasonable allocation of resources in multiple requests, even reuse Cached resources passed from these parent pages, etc. Smaller apps may not have these problems, and if you want to develop large apps with pure H5, it is likely to waste a lot of your time - and the results will not satisfy you.

The number of pits in HTML5 can be divided into 3 major points and 7 small points. The 3 major points are described in detail above. Let's talk about the 7 small points.

1. Excessive reliance on the network

2. Weak rendering performance

3. Too many pages

4. Too many labels and a lot of code

5. Cannot call the functions of mobile hardware devices

6. Does not support offline mode

7. Not timely message push

Although H5 APP has many shortcomings, I have to admit that existence must have its role. Just like the popular hybrid development model in the past few years, combining native and H5 is also a good solution, such as Taobao, JD.com and other e-commerce apps.

The advantage of HTML5 lies in its typesetting, and the cost of typesetting the Native interface with the same effect is too high. Big,

JavaScript is not popular with developers due to its complex Document Object Model (DOM), poor implementation and debugging tools, inconsistent browser implementations. With the development of technology, JavaScript has become more and more powerful and perfect. For example, Ajax technology can create more attractive web applications, Angular JS provides the architecture of web applications to support the entire development process, and Node.js expands the application scope of JavaScript On the server side, imag.js extends JavaScript to the mobile side, and various frameworks emerge in an endless stream to make JavaScript development easier. Especially in recent years, the development of node.js, imag.js and react.js has raised JavaScript to unprecedented heights.

We can also take a look at the WeChat page developed with imag.js (supports Android and iOS)
Click the link