What is the gap between pure HTML5 apps and native apps ?, Html5app gap

What is the gap between pure HTML5 apps and native apps ?, Html5app gap
What is the gap between pure HTML5 apps and native apps?

I have written some pure H5 apps. Although it is indeed very comfortable to develop, there are still many problems with pure h5apps compared with native ones, mainly in the following aspects:

 

1. Animation

 

There are many types of animations, such as slide-in and out of Sidebar menus, element response animations, and passing between page switches. Many implementation methods under H5 cannot achieve pure native performance. Generally, there are several different options:

 

• 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 on-site mode will make the app low-end mobile phone experience very poor. The best choice is generally to call the underlying animation through the framework, but no matter how it is, it is equivalent to a layer of the original code, the performance is still inevitably affected.

 

For example, when loading a new page, if there are two issues to consider when calling the underlying animation, one is the rendering of its own resource page, and the other is remote data acquisition. Even if these animations can respond quickly, a large number of css pages will cause rendering lag, and white screen/machine freezing may occur during sliding. To solve these performance problems, you must use pre-loading or simulated animation. Even so, there are still many problems with slide-In and Out animations on low-end Android machines. If the method of obtaining server-side data processing is not suitable, choppy white screens will become more serious. For details, see the following data acquisition method.

 

2. Get server data

 

The first thing to accept is that the data obtained here is done asynchronously on the resource page, because only in this way can these resource pages be pre-loaded or rendered. However, the data obtained asynchronously may involve DOM operations when entering the page. As we all know, DOM operations consume a lot of performance. If the page is small, the page is slightly more complex, frequent DOM operations can lead to significant white flashes.

 

The most important thing is that, if the data update speed is too slow after the page is loaded, the page template will wait for a long time, which is unfriendly to the user experience, you can't always wait to refresh like a browser every time you open it, right.

 

If this problem is not solved, H5APP is difficult to handle pages with large data volumes, and frequent switching among them is even more difficult to handle. Some may think of MVVM, in fact, I have also written some h5apps Based on MVVM, which are relatively more agile and scientific in obtaining and updating data, but pay attention to many unique H5 problems during the writing process, these problems are described in the following page switch.

 

3. Page Switching

 

We have seen several good implementation methods, such as pre-loading and simulation animation, and even batch pre-loading and batch simulation animation. Although they seem friendly, they have solved many problems, but in fact, if there are enough pages, there will be another problem-the lifecycle of the page.

 

Imagine that if resources on five sub-pages are cached on the boot page or home page, the sub-page resources on these sub-pages will be cached when the sub-pages are redirected to the response, such repetition will certainly occupy a large amount of memory, reducing the APP experience. So how do we know what pages are needed, how many pages are cached at most, and when do we end the lifecycle of those pages? I have never answered these questions perfectly in the frameworks of many h5apps I have used, therefore, apps with more page content may suffer from performance reduction due to resource allocation issues.

 

At this time, let's look back at the MVVM data loading problem. In fact, no matter which MVVM framework you have written, everyone knows that the most important issue for managing this new front-end code is the memory issue, you must ensure that the Code is elegant enough without any memory leaks, and take into account whether their controllers/Page resources are released at the end of the page lifecycle, does this affect the global performance? resources should be allocated reasonably when multiple requests are made, or even cache resources transmitted from these parent pages should be reused. Small apps may not have these problems. If you want to use H5 only to develop large apps, it may waste a lot of time-and the results will not satisfy you.

 

4. Differences between Android and iOS

 

Many people say that a pure H5APP can compile two different Android/iOS apps at a time, greatly reducing the cost. In fact, this point of view is doubtful. If you have written such apps, you will be able to understand what I am talking about. They are both easy-to-use and have many bugs, which are especially cumbersome for debugging.

 

For example, there is a clear difference between Android and iOS in the processing method of returning to the previous page. How can I handle the bar on the top of iOS in full screen, how to handle the page layout when a smart bar appears on the Android machine, how to differentiate different scenarios when calling the underlying hardware, etc. You need to write one model after another and judge the system, then debug it in Android and iOS respectively. Finally, you find that this is useless, but you have not learned anything when you are tired. There is only a bunch of experiences that do not know when it will become obsolete.

 

There are a lot of developers who are doing H5 hybrid APP development, but H5 alone is very young and many problems are not well solved. These are the most important issues I have considered when developing these apps. Of course, you don't have to worry about it. With the implementation of ES6, hardware is growing faster and faster, and pure H5APP may not have a place. Finally, there is a H5 advantage that few people have noticed. When talking about H5APP, it is fast development, low cost, multi-platform, and so on, however, I think it is different from many APP development methods-text-and-Image Layout.

 

These complex and variable CSS styles consume performance, but they bring about the diversity of typographical settings. Being able to handle each word in a wide-row and style pixel-level manner is just the excellence of H5.