What's the difference between h5 app and native app?

1 H5 is very poor. H5 can be used in general forums, consultation and other places that change frequently, which is also very restrictive, and many effects cannot be achieved. WebView of GUI framework is generally like this. If an APP is made by H5 (unlikely, it will probably be rejected), it will be very stuck.

2. With iOS SDK, it is troublesome to realize hot update. For the forum, it is easy to consult this module and modify it, which is a headache, so H5 is very suitable. Especially when the APP spans Android and iOS, this module will be very useful if it is directly used with H5.

The gap between H5 web App development and pure native App mainly focuses on the following aspects:

1, animation

There are many kinds of animations, such as sliding in and out of the sidebar menu, responding animation of elements, cutting between page switches and so on. Many implementation methods under H5 cannot achieve pure native performance. There are generally several different options: css3 animation, javascript animation and native animation.

Css3 animation consumes a lot of performance. If you use an element in css3 animation, it may not be obvious, but using css3 animation in a large area or in the wild will make the low-end mobile phone experience of app very poor. The best choice is generally 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, loading a new page and calling the underlying animation need to consider two issues, one is the rendering of its own resource page, 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 a white screen/machine card may appear when sliding in. In order to solve these performance problems, it is necessary to use preloaded or simulated animation. Even so, slide-in and slide-out animation still has many problems on low-end Android machines. If the data processing method of the server is not suitable, the phenomenon of "blank screen" will be more serious. See the following data acquisition methods for details.

2. Get server data

The first thing to accept is that the data acquisition here is done asynchronously on resource pages, because only in this way can these resource pages be preloaded or rendered. However, data obtained asynchronously may involve DOM operations when filling pages. As we all know, DOM operations consume a lot of performance. If the page is small and fine, the page is slightly larger and the data is slightly more complicated. Frequent DOM operations can cause obvious flicker. And most importantly, 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 unfriendly to the user experience. You can't wait to refresh like a browser every time you open it, can you?

If this problem is not solved, it is difficult for H5 to develop pages with large-scale data, and it is even more difficult to switch frequently among them. Then someone will definitely think of using MVVM. In fact, I have also written some H5app development based on MVVM. Relatively speaking, the way they obtain and update data is more flexible and scientific, but in the process of writing, we should pay attention to many unique problems of H5. These issues will be discussed in the following page switching.

3. Page switching

Above, we have seen several good implementation methods, such as preloading and animation simulation, and even batch preloading and batch screenshot animation simulation. Although many problems seem to be solved amicably, in fact, if there are enough pages, another problem will arise-the life cycle of pages.

Imagine that if the wizard page or home page caches the resources of five sub-pages, the resources of the lower pages of these sub-pages will also be cached when jumping to the response sub-page. This repetition will definitely take up a lot of memory and reduce the experience of the APP. So how do you know which pages you need, how many pages to cache at most, and when to end the life cycle of which pages? There are no perfect answers to these questions in many frameworks of H5APP I have used, so when developing apps with many pages and contents, the performance may be degraded due to these resource allocation problems.

At this time, let's look back 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 front-end code is memory. You should not only ensure that the code is written elegantly enough without any memory leakage, but also consider whether their controller/page resources are released at the end of the page life cycle, whether this has any impact on the overall situation, allocate resources reasonably when multiple requests are made, and even reuse the cache resources of these parent pages. Smaller applications may not have these problems. If you want to develop a large-scale app with pure H5, you will probably waste a lot of time-and the result will not satisfy you.

4. The difference between 4.Android and iOS

Many people say that two different apps, Android/iOS, can be compiled only by developing H5app once, which greatly reduces the cost. In fact, this view itself has problems. If you have written this kind of APP, you can understand what I am talking about. They are neither convenient nor have many bugs, especially when debugging. For 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, how to distinguish different scenes when calling the underlying hardware, and so on. You need to write a model and system judgment, and then debug it under Android and iOS respectively. In the end, you find it useless. You are tired to death but you have learned nothing. Only a bunch of people don't know when it will be out of date.

There are many people developing H5 hybrid apps now, but pure H5 is very young, and many problems have not been well solved. These are the issues that I consider most when making these apps. Finally, let's talk about an advantage of H5 that few people pay attention to. When people talk about H5APP, they all mean fast development, low cost, multi-platform and so on, but I think it has a difference compared with many APP development methods-mixed typesetting of graphics and text. It is these complex and changeable CSS styles that consume the performance, but bring the diversity of typesetting, and the pixel-level processing of the width, height and style of each word can be meticulous, which is the outstanding point of H5.