How much do you know about the HhybridApp development model?

Hhybrid App, as the name suggests, is a combination of native App and Web App. Its shell is a native app, but inside it is a web page. It can be understood that a browser is hidden in the hybrid app, and what the user sees is actually the web page rendered by the hidden browser.

With the rapid development of Web technology and mobile devices, Hybrid technology has become the most mainstream and common solution. A good set of Hybrid architecture solutions allows the App to not only have the ultimate experience and performance, but also have a flexible development model, cross-platform capabilities, and a hot update mechanism.


First of all, let's take a look at some of the common APP development technology architectures currently on the market.

Native App development mode

Native App, native APP, using native (i.e. Android or iOS) developed APP. There is no doubt that the performance of the application is good. You can use all the hardware and software APIs of the system, such as GPS, camera, microphone, accelerometer, notification push, etc., to give full play to the potential of the system.

But there are also some disadvantages:

1. Different development teams need to be established. Large companies generally have two development teams for iOS and Android. If there is a third platform (such as Windows Phone or Huawei Hongmeng OS), it may be necessary to form a third team, and the cost will be higher.

2. Native apps use the language of the underlying operating system, which is a heavily compiled language. The development and debugging costs are relatively high and the time period is long.

3. The original app must be downloaded and installed before it can be used. As long as the version is upgraded, it must be downloaded and installed again. Users are often unwilling to update the version, and manufacturers are forced to support the old version long ago for a long time.

4. Unable to cross-platform: Both Android and iOS need to develop versions of their respective platforms - the development cost is high, and it needs to be reviewed by the app store, which often leads to inconsistent releases at both ends

I believe the above questions resonate with mobile developers

Web App Development Patterns

I believe that the rise of HTML5 technology has injected new vitality into Web App.

Web App generally refers to a web-based application that runs on a browser and does not need to be downloaded and installed . Basically, it can be said to be a touch-screen version of a web application. These types of apps are basically a web page or series of web pages designed to work on mobile screens.

There are generally two types of web sites :

MPA(Multi-page Application)

SPA(Single-page Application)

A general Web App refers to a website developed in the form of an SPA.

advantage:

Low development and maintenance costs, cross-platform, easy debugging;

The code developed by the front-end personnel can be applied to all major browsers (in special cases, the code can be compatible), there is no new learning cost, and it can be directly debugged in the browser.

The fastest update;

Since web app resources are directly deployed on the server side, you only need to replace the server-side files, and the user access has been updated (of course, some caching problems need to be solved).

shortcoming:

Low performance and poor user experience;

Since it is directly accessed through a browser, the native API cannot be used, and the operation experience is not good.

Relying on the network, the page access speed is slow and consumes traffic;

Web App must rely on the network every time it visits, and loads resources from the server. When the network speed is slow, the access speed is very unsatisfactory, especially on the mobile side, which has relatively high requirements for website performance optimization.

The function is limited, and a large number of functions cannot be realized;

Only some special APIs of HTML5 can be used, and native APIs cannot be called, so many functions cannot be realized.

Temporary entrance, low user retention rate;

This is both its advantages and disadvantages. The advantage is that it does not need to be installed. It is definitely difficult to find it after it is used up, or it is difficult to reserve an entry for a certain web app, making it difficult for users to use it again.

Hybrid App Development Model

Hhybrid App, as the name suggests, is a combination of native App and Web App. Its shell is a native app, but inside it is a web page. It can be understood that a browser is hidden in the hybrid app, and what the user sees is actually the web page rendered by the hidden browser.

The native shell of a hybrid app is called a "container", and the hidden browser inside usually uses the web page rendering control (ie WebView control) provided by the system, or it can also have a built-in browser kernel. Structurally, the hybrid app is divided into three layers from top to bottom: HTML5 web page layer, web page engine layer (essentially an isolated browser instance), and container layer.

Hybrid apps have the advantages of both native apps and web apps while avoiding some of their disadvantages. Specifically, it can be summarized in three points.

(1) Cross-platform

Web technology is cross-platform. Developers only need to write a page once to support multiple platforms. In other words, a hybrid app only needs one team, and the development cost is lower.

(2) Flexibility

Hybrid Apps are flexible and easily integrate multiple functions. On the one hand, the hybrid App can easily load external H5 pages to realize the plug-in structure of the App; on the other hand, the Web pages can easily call external Web services.

(3) Easy to develop

The debugging and construction of Web pages is far simpler and time-saving than native controls. It is also easy to update the page, as long as the new version is released on the server and the update in the container is triggered. In addition, web developers are also relatively easy to recruit, and traditional front-end programmers can undertake development tasks.

There are mainly three types of hybrid schemes that are more popular now, mainly because of the differences in the UI rendering mechanism:

  1. Based on the basic solution of WebView UI , most mainstream apps on the market have adopted it, such as WeChat JS-SDK and Cordova, and complete the two-way communication between H5 and Native through JSBridge, thus endowing H5 with a certain degree of native capabilities.
  2. Solutions based on Native UI , such as React-Native, Weex. On the basis of endowing H5 with native API capabilities, the virtual node tree (Virtual DOM) parsed by JS is further passed to Native through JSBridge and used for native rendering.

Here is a special emphasis on the third solution - based on the applet solution, which also uses a more customized JSBridge and uses a dual WebView dual thread mode to isolate JS logic and UI rendering, forming a special development mode and strengthening H5 The degree of mixing with Native improves page performance and development experience.

On the basis of JS-SDK, the applet further opens and expands the native capabilities to be called by the front end of the web. On the other hand, the UI layer and logic layer of the page rendering (Webview Render) use two independent threads. As shown below:

 

When the applet is running, it is essentially a virtual machine that handles web page rendering and data logic interaction. This virtual machine provides a wealth of native capabilities for the applet to call (API, components, AI capabilities, etc.), which greatly expands web applications. The ability boundary, especially in the provision of components such as scroll view (scrool-view), navigation (navigator), picture preview (cover-image), enables front-end developers to use existing web front-end technologies to develop Apps that are close to the native experience.

Technology Selection

The selection of any technical solution should actually be based on usage scenarios and existing conditions. Based on several considerations of the company's existing situation, we further optimized the first option, which is more suitable for our needs.

  1. Business functions can be quickly iterated, developed flexibly, and support online hot update mechanisms.
  2. In terms of the company's business, there is no very complicated UI rendering requirement, and the company already has a complete front-end framework and is very mature, so we do not strongly need a solution like RN.
  3. The core capability of the product is the need to invoke system permissions. Therefore, the pure H5 technology can do very limited things and cannot meet the needs. It needs to be strengthened by Hybrid technology, such as the "Native+ applet" technical framework

So when you get such a "small program runtime engine", how do you transform your app?

In the past, when the business department wanted to release some new functions, users had to take the initiative to update the app, and any change or upgrade of a partial function required going to the application market to operate again, which was very costly. Since not all users update, the IT team needs to spend a lot of effort to maintain multiple different versions. This method causes a huge waste of resources and inconvenience to the user experience.

If you use a small program, this problem will be easily solved. First of all, applets can be updated independently. As a carrier, App does not need to be updated frequently for a long period of time. Secondly, each applet can release its own version independently according to the specific needs of the business, and the updates and upgrades between different applets are independent of each other and do not interfere with each other. Finally, due to the sandbox mechanism of the small program, it is guaranteed that no matter which small program has bugs, crashes, etc., the application itself will not be dragged down. Even if there are serious problems, it is only necessary to take it offline.


At present, there are also general solutions for small programs on the market. Today I will introduce it to you- FinClip . Its biggest feature is that it can run applets in any App.

You only need to import its SDK in your App to load and run external applets. In addition to the SDK, it also provides a background management system to uniformly manage the listing and removal of applets, as well as collect and analyze applet data.

 

Moreover, FinClip fully follows the development standards and specifications of WeChat Mini Programs. That is to say, the existing WeChat applets can be directly put into your App without changing a single line of code, and the running effect remains unchanged, without additional secondary development and transformation, which greatly saves labor costs.

Not only that, but FinClip also supports a variety of terminals other than mobile phones, including Linux, Windows, MacOS, Kirin and other operating systems. This means that small programs can be used on PCs, in-vehicle devices, and smart TVs, realizing the "one-time development, running everywhere" of small programs, and reaching many traffic platforms at the same time, not just limited to the WeChat ecosystem.

 

FinClip also provides an IDE development tool for small programs. The interface is similar to the development tools for WeChat small programs. It comes with debugging and real-device preview, which is easy to use. In this IDE, you can carry out secondary development on existing projects, extend functions and interfaces, or write a small program from scratch.

The development of everything is cyclical. Obviously, this wave of dividends from mini programs has arrived, and today's innovation may be tomorrow's standard configuration. The top priority is to get on the boat as soon as possible to get the "boat ticket".

Guess you like

Origin blog.csdn.net/pingpinganan0828/article/details/131802031