All men are mortal

Hybrid development actually refers to his Hybrid App

Hybrid App refers to an App between Web-APP and native App, which has both “advantages of good user interaction experience of native App” and “advantages of cross-platform development of Web App”.

HybridApp is the embedding of web pages in your app

Rise reason

The rise and popularity of Hybrid App is actually an accident in the mobile Internet industry. After the upsurge of mobile Internet blew, many companies entered one after another. But it soon became clear that there were too few developers for mobile apps, leading to a mad scramble for talent. Under the market mechanism, the treatment of mobile application development talent is skyrocketing, and finally many enterprises cannot afford to support a professional mobile application development team with cross-platform development ability. The emergence of HTML5 makes the dawn of Web App. The cross-platform and cheap advantages of HTML5 in developing mobile applications make many companies who want to enter the field of mobile Internet start to move. However, the current Web App based on HTML5 is in a fog. Before the three core problems of user entrance habit, distribution channel and application experience are solved, It is difficult for Web App to break out. Just because of this coincidence, Hybrid App technology based on low-cost cross-platform development advantages of HTML5 and features of Native App entered the fray and quickly attracted the attention of the public. It greatly reduces the development cost of mobile applications, can be released through the existing App store mode, and can form an independent entrance on the user desktop, etc., making Hybrid App a good choice to solve the dilemma of mobile application development, and also become the spokesperson of Web apps at the present stage. Like an assassin, Hybrid apps accidentally took a place in the field of mobile App development at a time when Native apps and Web apps were fighting each other. (Baidu)

Strengths and Weaknesses

A picture illustrates the problem:

The development course

After the rise of mixed development, the community became restless. So there was a bunch of wheels that helped us quickly develop a Hybrid App

Cordova

This is one of the first wheels in the community that we call Cordova. Cordova provides three main capabilities:

  • The ability of front-end code to communicate with native code;
  • Native plug-in mechanism;
  • Cross-platform packaging capability.

Cordova is a mobile application development framework on which you can build apps using web code.

Phonegap Build

Phonegap Build is an online packaging tool, you write projects in Cordova to Phonegap Build, Phonegap Build will be online packaged as an App.

Phonegap

On October 4, 2011, computer Software company Adobe announced the acquisition of Nitobi Software, the startup that created PhoneGap and PhoneGap Build, the HTML5 mobile application frameworks. Phonegap is now the successor to Phonegap Build and Cordova. As a result, Phonegap has become very popular in the hybrid development space. As a result, we don’t need the online packaging capability to use Cordova, which is also called using Phonegap. That’s what we call it today.

The solution only provides a WebView for the front end and otherwise does not interfere with the presentation layer at all. Of course, the disadvantages are obvious, because the front end is still in the early stages of development, many animation experiences are far from native. And because there is only one WebView, there is no transition animation at all, which makes the app difficult to use.

Derivative application development platform

To solve the problems of Cordova, some manufacturers provide a solution and friendly documentation, but in essence, they make the following improvements:

  • Manage the project as a cloud platform, and the whole development cycle can be realized on the platform except writing code;
  • Rich built-in native capabilities, available out of the box;
  • Build a local plug-in ecosystem;
  • Multi-webview mechanics, solving fluency problems with native transitions, is a killer feature.

In this way, the multi-WebView mechanism directly solves the problem of special animation, and the experience can be upgraded to a higher level. Some well-known examples are Ionic. However, due to the inherent limitations of Web pages, it is difficult for hybrid applications to reach the level of refinement of native UI. The loading speed of the interface is also affected by the speed of the phone and the size of the page. If the front-end development is not careful enough, it is easy to give users a “web feel”, which greatly reduces the user experience of the App.

JSBridge (WebView UI) solution

In the development of the mobile Internet is crazy, the rise of it training institutions, ios, android engineer was quickly develop, a thriving market, you can imagine the ios in 13 years time so much fire, as a result, the market is not a lack of native development, enterprises have begun to pay attention to the user experience of app, lead to weaknesses exposed before mixed development platform, As a result, JSBridge scheme was gradually adopted

JSBridge: The name sounds like a bridge between JS and Native, but JSBridge is actually a way of communication between JS and Native. To put it simply, JSBridge is to define the communication between Native and JS. Native only calls JS through a fixed bridge object, and JS only calls Native through a fixed bridge object.

In fact, JSBridge is to remove the one-stop services encapsulated by various mixed development platforms, and only retain the communication part between Web and Native, so as to embed Web in the Webview of APP to solve the problems that cannot be solved by the Native end, such as: Native cannot parse rich text, an app has an activity that needs to be launched, and if native is used to do it, it still needs to be issued. However, the hot update ability of Web happens to be able to solve the pain point of native APP, so JSBridge has become an indispensable part of software development. Although the pain point problem has been solved, React Native was born out of nowhere, but it still couldn’t solve the problem that an app needed multi-terminal collaboration and multi-terminal communication, which made development more difficult

React Native

React Native (RN for short) is a cross-platform mobile application development framework that Facebook opened source in April 2015. It is a derivative of Facebook’s early open source JS framework React on the Native mobile application platform. It supports iOS and Android platforms.

The difference between RN and normal hybrid development is that React Native takes a different approach to hybrid mobile application development. React Native does not generate Native UI components, but is based on React. React Native is a JavaScript library used to build web-based interactive interfaces, so it has richer UI experience and can well invoke UI use of the underlying framework to achieve the same experience as Native

Weex

Weex On April 21, 2016, Alibaba announced at Qcon that Weex, a cross-platform mobile development tool, was not tested. In fact, Weex is similar to RN, but it has some advantages compared to RN:

  • Js can write business, cross-platform, hot update
  • Weex uses the Vue framework and is close to our technology stack
  • Weex is lighter than RN and can be subcontracted, with better performance of one instance per page
  • Weex addresses some of RN’s existing problems and builds on them
  • Good scalability, easy to expand new components and modules

Flutter

As soon as RN was launched, it became very popular, and Google, also an Internet giant, was not to be left behind, so its first version was released on December 5, 2018. After its launch, it quickly became popular, and now React Native has been overshadowed by the following reasons:

RN Bridges not only system services, but also the system UI into JaveScript, so that the written UI will eventually be rendered as a native control.

Mainstream hybrid development solutions

JSBridge (WebView UI) scheme (to be analyzed in this issue, the mainstream scheme of app in the market)

JSBridge’s solution is the current mainstream solution. For example, some big factory apps also adopt the current solution, such as Taobao, Toutiao, wechat and Ele. me

React Native UI solutions (Weex, Fullter)

This solution is essentially a solution that uses JsBridge to parse JS or Dart into a tree of native nodes and render using native, thus providing a native experience

Small program solution

The solution of small program was first proposed by wechat, and other big factories followed suit. In fact, it is also realized by using JSBridge

JSBridge in-depth analysis

We mentioned earlier that the essence of a Hybrid App is to use a WebView as a container to host a Web page, so what is a WebView?

webview

Webview is a control based on webKit engine that can parse DOM elements and display HTML pages. It has the same principle as browser display pages, so it can be treated as a browser. (Chrome and Safari are also based on WebKit.)

In short, WebView is basically a browser that can parse HTML, CSS, and JS, and even worse in android, which used Chrome directly after version 4.4

The basic principle of

I’ve already said that in the course of history. I’ll repeat it again

JSBridge: The name sounds like a bridge between JS and Native, but JSBridge is actually a way of communication between JS and Native. To put it simply, JSBridge is to define the communication between Native and JS. Native only calls JS through a fixed bridge object, and JS only calls Native through a fixed bridge object.

How to use it?

Due to android and ios code is not familiar, borrowed flower Buddha, copied over, thanks to the shoulders of giants

The Android end

Native tone JS

// mWebView = new WebView(this); mWebView.loadUrl("Javascript: method name (' parameter, need to be converted to string ')"); // Run runOnUiThread(new) in the UI threadRunnable() {  
        @Override  
        public void run() {  
            mWebView.loadUrl("Javascript: method name (' parameter, need to be converted to string ')"); Toast. MakeText (Activity. This,"Call method...", Toast.LENGTH_SHORT).show(); }}); 4.4 after the invocation style mWebView. EvaluateJavascript ("Javascript: method name (' parameter, need to be converted to string ')", new ValueCallback() {@override public void onReceiveValue(String value) {// the value is returned by the corresponding JS method}});Copy the code

JS the Native

// Javascript calls Native need to set @javascriptInterface annotation to WebView. There is a loophole here, which will be explained later. To make JS Native, you need to set the following properties on the WebView. WebSettings webSettings = mWebView.getSettings(); / / Android container allows the JS script webSettings. SetJavaScriptEnabled (true); / / Android container set though, even objects (my understanding is equivalent to under the window hangs a namespace, name, casually wrong place please bigwig) mWebView. AddJavascriptInterface (getJSBridge (),"JSBridge"); // Add namespace method private ObjectgetJSBridge(){  
    Object insertObj = new Object(){  
        @JavascriptInterface
        public String foo() {return "foo";  
        }  

        @JavascriptInterface
        public String foo2(final String param){  
            return "foo2:"+ param; }};returninsertObj; } // HTML uses // to call method one window.jsbridge.foo (); / / return:'foo'// Call method 2 window.jsbridge.foo2 ('test'); / / return:'foo2:test'
Copy the code

The iOS side

Native tone JS

//Swift
webview.stringByEvaluatingJavaScriptFromString("Method name (parameter)")
//OC
[webView stringByEvaluatingJavaScriptFromString:@"Method name (parameter);"];
Copy the code

JS the Native

// Introduce official library files in ios#import <JavaScriptCore/JavaScriptCore.h>//Native register API function (OC) -(void)webViewDidFinishLoad:(UIWebView *)webView{[self hideProgress]; [selfsetJSInterface];
}

-(void)setJSInterface{

    JSContext *context =[_wv valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]; // Register the API method context[@ named foo"foo"] = ^() {// Get parameters NSArray *args = [JSContext currentArguments]; NSString *title = [NSString stringWithFormat:@"% @",[args objectAtIndex:0]]; // Do some logic of your own // return a value'foo:'+title
        return [NSString stringWithFormat:@"foo:%@", title]; }; } // Call window.top.foo directly in js ('test');
Copy the code

Of course, there is also a SCHEME for intercepting URLS if you simply call Native JS

Url scheme is a link similar to URL, which is designed to facilitate apps to call each other directly. To be specific, if it is the url scheme of the system, open the system application; otherwise, check whether there is any app registered with this scheme and open the corresponding app. The main difference is that protocol and host are generally customized.

For example: tiantianxiangshang: / / hoahaoxuexi/url? Qwer, protocol is Tiantianxiangshang, and host is Hoahaoxuexi.Copy the code

The Web end sends scheme request in a certain way, and Native captures the corresponding URL triggering event in a certain way, and then gets the current triggering URL. According to the defined protocol, it analyzes which method is currently triggered.

Community wheels

The communication process above is complicated and tedious, and the two ends are not unified, so we have endless community wheels, such as

JsBridge solves ios communication wheel WebViewJavascriptBridge solves android communication wheel JsBridge also has a three-end easy-to-use wheel DSBridge is actually integrated the advantages of the first two, written in a set

After studying its code, they actually added some encapsulation ideas on the basis of the basic communication at both ends, such as: added callback ah, support asynchronous ah, and so on, yes, on the basis of the original become more flexible and easy to use!

Attached is a flowchart to wrap up these wheel ideas:

conclusion

In the mixed development scheme, there is not a perfect solution so far (certainly not perfect, otherwise the original engineers will be laid off), each scheme has its own shortcomings and disadvantages, and IN the unit of technology selection I generally follow the following points just for your reference:

  • 1. If it is an existing original project and the project flow is huge, it needs small reconstruction. It is more problematic to adopt JsBridge
  • 2. If it is a new project and a small project, and the company has cost support (usually a large company), the radical scheme Flutter or RN can be adopted to try it
  • 3. If a new project is aimed at a grand idea at the beginning, I usually adopt a safe way and add JsBridge in the original way

Basic mixed development knowledge point I feel need to learn also so much, in need of in-depth research involving the source level of things, also please move to Github and each official document, finally remind, this article belongs to personal study notes to share, if there are mistakes, please big guy pointed out!

The last

What is a Flutter? JSBridge in-depth analysis