Status and background:
The current applications are basically It is native, although it has a hybrid component, but the proportion is very low, and it is mainly used for event pages.
This is understandable a few years ago, the performance of mobile devices is not that strong yet. With the rapid development of hardware, although there is still a gap between current mobile devices and PCs, they are already sufficient to support complex H5 content.
Assumption:
Main ideas
- APP is mainly implemented in H5, not limited to active pages
- Not used The more popular SPA (single page application) method
- Each interface corresponds to an H5 page, which is equivalent to the functions of Activity/ViewController+layout
- Each interface (including the native one) has a unique URL, which is redirected through the URL
- The template is rendered in the App, front and back ends The separation will be in the APP instead of the server, and the APP is more dynamic
- Preset resources to make the loading process faster
The APP will be divided into the following three levels:
- Container: natively provide functions that H5 does not support or poorly supported (such as video and audio playback), manage page switching, and Server data interaction, page rendering, preset resources, caching strategy, etc. The container should be modular and pluggable during construction
- H5 frame: a lightweight H5 frame, plus some support for APP general functions (such as animation effects, gesture interaction, General UI components, etc.)
- H5 business layer: all business logic is implemented on different pages
The first two levels can form a framework for the benefit of mankind. In the same field, the third level can also abstract shared components or libraries
Advantages:
Compared to native applications,
- APP is more dynamic, which can reduce APP upgrades. Only if the container changes, users need to upgrade. Page changes, no need to upgrade
- Cross-platform, iOS and Android share a set of pages (there may be PCs, Widows Phone in the future)
- Reduce technical requirements, and the front end can be used quickly
Relative to SPA
- Each page is more independent of each other, Avoid all js code to be executed in one context, you can avoid heavy UI frameworks, single page problems will not interfere with other pages, and you don’t need an overly complex dom structure
- It does not conflict with the native APP gameplay and can complement each other. For example, some pages of an APP can be native and some are H5 (of course, try to use H5 as much as possible).
problem
debugging is purer Native applications are more difficult. But if you simply debug H5 on the simulator, remote debugging with Safari and Chrome is more flexible than native application debugging. The experience is still far behind the native APP, which is mainly manifested in the operation response time, animation effects and other aspects. But in most cases, compared with the native APP, the gap is no longer felt. Security also needs to be studied. When too many pages coexist, memory consumption is large