Hybrid App Technology Analysis

With the rapid development of Web technology and mobile devices, Hybrid technology has become one of the most mainstream and most common solutions. A good Hybrid architecture solution enables the App to have the ultimate experience and performance, as well as the flexible development model of Web technology, cross-platform capabilities, and hot update mechanism.

Existing hybrid solution

Hybrid App, commonly known as hybrid application, is a mixture of Native technology and Web technology Mobile applications under development. There are three popular hybrid solutions, mainly 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, complete the two-way communication between H5 and Native through JSBridge, thus giving H5 a certain degree of native capabilities.
2. Solutions based on Native UI, such as React-Native, Weex. On the basis of giving H5 native API capabilities, the virtual node tree (Virtual DOM) parsed by js is further passed to Native through JSBridge and native rendering is used.
3. In addition, there is a relatively popular small program solution recently. It also uses a more customized JSBridge, and uses a dual WebView dual-thread mode to isolate the JS logic and UI rendering, forming a special development model, strengthening Improved the mixing degree of H5 and Native, improved page performance and development experience.

The above three schemes are actually based on the communication layer completed by JSBridge. The second and third schemes can actually be regarded as the basis of scheme one and continue to pass different New technologies have further improved the degree of mixing in applications. Therefore, JSBridge is also the most critical part of the entire hybrid application.

Hybrid technology principle

The essence of Hybrid App is that in native App, WebView is used as a container to directly host Web pages. Therefore, the core point is the two-way communication layer between Native and H5. In fact, it can be understood that we need a set of cross-language communication solutions to complete Native (Java/Objective-c/…) and JavaScript. Communications. This solution is what we call JSBridge, and the key to its realization is the WebView as a container. All principles are based on the WebView mechanism.

(1) JavaScript notification Native

Based on the mechanism of WebView and open API, there are three common solutions to realize this function :

• The principle of API injection is that Native gets the JavaScript environment context and directly mounts objects or methods on it so that js can be directly called. Android and IOS have corresponding mounting methods respectively.
• The prompt/console/alert interception in WebView usually uses prompt, because this method is used in the front end with low frequency, and there is less conflict;
• WebView URL Scheme jump interception ;

The principles of the second and third mechanisms are similar. They all achieve communication by intercepting the bubbling transmission of WebView information. Next, we will mainly start from the principle-customized protocol- Interception Protocol-Parameter Transfer-Callback Mechanism Five aspects are elaborated on the third scheme-URL interception scheme.

1. Implementation principle

For network requests issued in WebView, the client can monitor and Capture

2. Protocol customization

We need to develop a set of URL Scheme rules, usually our request It will start with the corresponding protocol, such as the common https://xxx.com or file://1.jpg , Represents a different meaning. Here we can customize the protocol type request to:

xxcommand://xxxx?param1=1&param2=2

Here are a few points to note:

(1) xxcommand:// is just a rule, which can be formulated according to the business to make it meaningful

Different protocol headers represent different meanings, so that each protocol can be clearly understood The scope of application.

(2) Do not use location.href to send here, because there is a problem with its own mechanism that multiple concurrent requests at the same time will be merged into one, causing the agreement to be ignored, and the concurrent agreement is actually very common Function.

(3) Generally considering security, it is necessary to set a domain name whitelist or restriction in the client.

3. Interception of protocol

The client can intercept the request sent by WebView through API:< /p>

• On IOS: shouldStartLoadWithRequest
• Android: shouldOverrideUrlLoading

When the request URL header is resolved to the specified protocol, it will not initiate the corresponding Instead, it parses the parameters and calls related functions or methods to complete the mapping of protocol functions.

4. Protocol callback

Because the nature of the protocol is actually sending a request, this is an asynchronous process , So we need to deal with the corresponding callback mechanism. The method we use here is the JS event system. Here we will use the two basic APIs of window.addEventListener and window.dispatchEvent;

• 1. When sending an agreement, register a custom event with the unique identifier of the agreement, and bind the callback to the corresponding event.
• 2. After the client completes the corresponding function, it calls Bridge’s dispatch API and directly carries data to trigger the custom event of the protocol.

5. Parameter passing method

Because WebView has limitation on URL length, Therefore, the conventional way of passing through the search parameter has a problem. When the parameter to be passed is too long, it may be truncated, such as when base64 is passed or a large amount of data is passed.

So we need to formulate new parameter passing rules, we use the method of function call. The principle here is mainly based on:

Native can directly call the JS method and directly obtain the return value of the function.

We only need to mark each protocol with a unique identifier, and store the parameters in the parameter pool, and then the client can obtain the corresponding parameters from the parameter pool through the unique identifier.

(2) Native notification Javascript

Since Native can be counted as the host of H5, it has greater authority. It is also mentioned that Native can directly execute Js code through WebView API. Such authority also makes communication in this direction very convenient.

• IOS: stringByEvaluatingJavaScriptFromString

//  Swift

webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")

• Android: loadUrl (4.4-)

// call the JSBridge.trigger method in js

// The drawback of this method is that the return value of the function cannot be obtained;< /span>

webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")

Based on the above principles, we have understood the most basic principles of JSBridge and can implement Native <= > H5’s two-way communication mechanism is now available.

(3) JSBridge access

Next, let’s take care of the resources needed on the code. To implement this scheme, as can be seen from the above figure, it can actually be divided into two parts:

• JS part (bridge): Inject the bridge implementation code in the JS environment, including the protocol Assemble/send/parameter pool/callback pool and other basic functions.
• Native part (SDK): The function mapping code of bridge in the client realizes functions such as URL interception and analysis/environmental information injection/general function mapping.

What we do here is to encapsulate the two parts together into a Native SDK, which is introduced by the client. When the client initializes a WebView to open the page, if the page address is in the whitelist, it will directly inject the corresponding bridge.js into the HTML head. This approach has the following advantages:

• The codes of both parties are maintained uniformly to avoid version splitting. When there is an update, as long as the SDK is updated by the client, there will be no version compatibility issues;
• App access is very convenient. You only need to access the latest version of the SDK according to the document, and you can run it directly The whole set of Hybrid solution is easy to implement quickly in multiple apps;
• H5 end does not need to pay attention, which is conducive to opening the bridge to third-party pages.

One thing to note here is that the call of the protocol must be executed after the successful injection of bridge.js. Since the injection behavior of the client is an additional asynchronous behavior, it is difficult to capture the exact timing of completion from the H5 side. Therefore, it is necessary to use the client to monitor the page after the completion, and notify the H5 side based on the above event callback mechanism, and the page can be passed window.addEventListener('bridgeReady', e => {}) to initialize.

(4) How to connect H5 in App

There are usually two ways to connect H5 to App. One way:

(1) Online H5, this is the most common way. We only need to deploy the H5 code to the server, just give the corresponding URL address to the client, open the URL with WebView, and then embed it. The advantages of this method are:

• Strong independence, with very independent development/debugging/update/online capabilities;
• The resources are placed on the server, which will not affect at all The size of the client’s package;
• The access cost is very low, and it has a complete hot update mechanism.

Relatively, this method also has corresponding disadvantages:

• It is completely network dependent, and the page cannot be opened when offline;
• The loading speed of the first screen depends on the network. When the network is slow, the loading of the first screen is slower;

Usually, this method is more suitable for some relatively lightweight pages On, for example, some help pages, tips pages, guides, etc. pages. The features of these pages are that they are not very functional, do not require complex functional protocols, and do not need to be used offline. In some third-party page access, this method is also used, for example, our page calls WeChat JS-SDK.

(2) Built-in package H5, which is a localized embedding method. We need to package the code and deliver it to the client, and the client directly decompresses it to local storage. Usually we use it on some relatively large and important modules. Its advantages are:

• Because of its localization, the first screen loading speed is fast, and the user experience is closer to the original;
• It can run offline without relying on the network;

But at the same time, its disadvantages are also very obvious:

• The development process/update mechanism is complicated and requires the cooperation of the client and even the server;
• App package size will be increased accordingly;

These two access methods have their own advantages and disadvantages, and should be selected according to different scenarios.

// Swift

webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')")

// Call the JSBridge.trigger method in js

// The drawback of this method is that the return value of the function cannot be obtained;< /span>

webView.loadUrl("javascript:JSBridge.trigger('NativeCall')")