What is the difference between pure HTML5 APP and native APP?

[[151272]]

I have written some pure H5 apps. Although they are fast and comfortable to develop, they still have many problems compared to native apps. They are mainly concentrated in the following aspects:

1. Animation

There are many kinds of animations, such as the sliding in and out of the sidebar menu, the responsive animation of elements, the transition between page switches, etc. Many implementation methods under H5 cannot achieve pure native performance. Generally, there are several different options for these:

• CSS3 Animation

• JavaScript animation

• Native Animation

CSS3 animation consumes a lot of performance. If a certain element uses CSS3 animation, it may not be visible, but using CSS3 animation in a large area or in transitions will make the app experience very bad on low-end mobile phones. The best choice is generally to call the underlying animation through the framework, but no matter what, it is equivalent to wrapping a layer on the original code, and the performance is inevitably affected.

For example, when loading a new page, if you call the underlying animation, 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 jams, and there may be white screens/machine jams when sliding in. In order to solve these performance issues, preloading or simulation animations must be used. Even so, the slide-in and slide-out animations still have many problems on low-end Android machines. If the method of obtaining server-side data processing is not appropriate, the jamming and white screen phenomenon will be more serious. See the data acquisition method below for details.

2. Get server data

The first thing to accept is that data acquisition here is done asynchronously on the resource page, because only in this way can these resource pages be preloaded or rendered. However, when the asynchronously acquired data is filled into the page, DOM operations may be involved. As we all know, DOM operations consume a lot of performance. If the page is small, it is not a big deal. If the page is slightly complex, frequent DOM operations will cause obvious white flicker.

And the most important point is that if the data is updated too slowly after the page is loaded, the page template will have to wait for a long time, which is not user-friendly. You can't wait for refresh like a browser every time you open it, right?

If this problem is not solved, it will be difficult for H5APP to handle pages with large amounts of data, and it will be even more difficult to switch between them frequently. Then someone will definitely think of using MVVM. In fact, I have also written some H5APPs based on MVVM. Relatively speaking, their way of obtaining and updating data is more agile and scientific, but in the process of writing, we must pay attention to many problems unique to H5. These problems are discussed in the page switching below.

3. Page switching

Above we have seen several good implementation methods, such as preloading and simulation animation, and even batch preloading, batch screenshot simulation animation, etc. Although it seems friendly and solves many problems, in fact, if there are enough pages, it will cause another problem - the life cycle of the page.

Imagine that if the boot page or main page caches the resources of 5 sub-pages, and when jumping to the corresponding sub-page, the subordinate page resources of these sub-pages will be cached again. This will definitely occupy a lot of memory and reduce the APP experience. So how do you know which pages are needed, how many pages can be cached at most, and when to end the life cycle of which pages? Many H5APP frameworks I have used do not have a perfect answer to these questions. Therefore, in APPs with more pages and more content, the performance may be reduced due to these resource allocation issues.

Now let's look back at the data loading problem of MVVM. In fact, no matter which MVVM framework, people who have written it know that the most important issue in managing this new type of front-end code is memory. You must ensure that the code is written elegantly without any memory leaks, and also consider whether their controller/page resources are released at the end of the page life cycle, whether this has any impact on the global situation, and reasonably allocate resources when multiple requests are made, and even reuse cache resources passed from these parent pages, etc. Smaller apps may not have these problems. If you want to use pure H5 to develop large apps, it is likely to waste a lot of your time - and the results will not satisfy you.

4. Differences between Android and iOS

Many people say that pure H5 APP can be compiled into two different APPs, Android/iOS, by writing it once, which greatly reduces the cost. In fact, this view itself is questionable. If you have written such APPs, you will understand what I am talking about. They are not only troublesome, but also have many bugs, and are particularly cumbersome to debug.

To give a simple example, there are obvious differences between Android and iOS in the way of returning to the previous page, such as how to handle the top bar of iOS in full screen, how to handle the layout of the page when the smart bar appears on Android machines, how to distinguish different scenarios when calling the underlying hardware, etc. You need to write judgments for one model and system after another, and then debug them under Android and iOS respectively. In the end, you find that it is useless. You are exhausted but have learned nothing, only a bunch of experience that you don’t know when it will become outdated.

There are many people developing H5 hybrid apps now, but pure H5 is still young, and many problems have not been solved well. These are the issues I consider most when developing these apps. Of course, you don’t have to worry. With the implementation of ES6, hardware development is getting faster and faster, and pure H5 apps may not have no place. Finally, let me talk about an advantage of H5 that few people notice. When everyone talks about H5 apps, they are all about rapid development, low cost, multi-platform, etc., but I think it is different from many APP development methods - mixed text and image layout.

It is these complex and changeable CSS styles that consume performance, but they bring diversity to typesetting. The ability to process every word width, line height and style at the pixel level is the excellence of H5.