On the development of mobile-hybid

　　The following code address:Https://github.com/wytings/Hybrid

　　background: The development and development of the company's business needs to upgrade, we need to hybrid. There are many open-source hybrid framework for us to use directly, but after a period of trial and research, we finally chose to develop a relatively concise hybrid framework. Many people wonder why they build wheels. Because we feel that these "wheels" are not very suitable for us, after our assessment, we feel that the cost of rebuilding a "wheel" is lower.

　　 We should always be aware that we should not let our development be guided or confused by the new technology! We have to understand the fundamental purpose of our development of a product is why? Is it to use these technologies? No! We are in order to better achieve the needs of our products and user needs, so as to better serve our customers. Therefore, in addition to purely technical research, product development must be "on-demand". What kind of technology do we need to achieve is the most suitable one to use. The actual development process is difficult to have the best solution, more is only the most suitable for your solution.

So that's why we do it, and it's also the main purpose of "on mobile end hybid development" ...

I'm going to elaborate on the three main aspects of why, why, why use H5,whynot(Why not use other frameworks), how to do H5 and native interactions.

　　Add Note: here the H5 to describe may be relatively narrow, in fact, more accurate should be the web. But now the mobile side of the web on the H5, but also adapt to the wave of the tide. At the same time also want to spit groove, unexpectedly have H5 development engineer this position ... Is not later also will have JAVA8 development engineer, Android7.0 development engineer, Python3 development Engineer ...

　　First, why the app to use H5

　　The advantages of using H5 are very obvious, with the following points in general:

1. Increase development efficiency and agile iteration frequency. One set of code for multi-use, low maintenance costs.
2. You can bypass the auditing of the app market. This may not be as obvious as Android, but the cost of each submission to the App Store on iOS is pretty high.
3. Update the code remotely. Although native can be done in a certain way not to apply some local code updates, but compared to H5 is too far away.
4. Stronger component and multiplexing rates. Because a set of code is used in a multi-terminal, it avoids the need to develop a set of Android and iOS.

The advantage of using H5 is so obvious, and that's why H5 is being held up (frankly, I also think the future of H5 is brighter than native ... But why don't we all use H5? Here you have to hit the H5 as well as praise. Because it has some innate shortcomings that are not currently avoidable.

1. Fluency is not native good. This is why H5 can not replace the main reason for the app. This fluency not only refers to the operation, but also includes the page display, to know that the development of the web is basically the default in a relatively stable network conditions. This is not a mobile app to guarantee.
2. User interactivity is poor. Simply put, experience is better than native. And because of the difference in Mobile system operation, Android and iOS have different usage habits and actions. The web's so-called unified, consistent interactivity is hard to align with the system.

In the era of user experience, H5 's shortcomings make it irreplaceable for the development of native, and it is not suitable for the presentation of a first-level page. But it has to be admitted that its merits are very attractive. We want to preserve native better experience, and also want to use H5 flexibility, means we have to let H5 have a certain native ability, that is, H5 have the ability to invoke some native interface, and because of this, the hybrid framework is used. If it is a simple page display, it is not necessary to what hybrid framework. Since H5 is more of an accessible development tool for app development, H5 typically uses a module, or a type of page, and so on.

In addition, I think H5 than native to be brighter, because I believe that the future H5 environment will be much better than the present. So, not how to learn H5 students can take the time to learn more learning ~

　　Second, why not use other frameworks

　　We still choose to develop a set of their own framework, because we feel that the market is so-called mature products for us is not too complex is too bloated, we take Cordova, to use Cordova need to pour a lot of Cordova files, and to implement many so-called plugin to use, we tested to find that Cordova's performance was very unfriendly. You know, the communication performance of JavaScript and native is dozens of milliseconds, so this is the problem of the Cordova itself ... These are not the main, more important is the Cordova memory leak is very serious, especially iOS, open a Web page minutes 100M ...

And the others, each of them advertised themselves as powerful as the space carrier, but what we really need is a few bikes, which is the tricycle, which is also the introduction of other frameworks to bring some uncontrolled places. Hybrid brings the elasticity and cost of co-existence, to just right is very difficult, only as best as possible.

when you want to introduce a framework, do you think we really have that much need to update the code frequently? A set of code multi-use, seemingly cost-saving, but the actual operation of the process, really save it? Companies may be different, but the answer to our current status is less frequent, and to support the native functionality of the web, we don't see much cost savings. More often the situation is: this is still native to achieve more suitable ... So, we choose to achieve their own! That is, there is not much development cost, but also the flexibility to fully guarantee the use.

　　Iii. how H5 interacts with the app (Android as an example)

　　When we decide to do it ourselves, we need to know how JavaScript communicates with native. The interactive implementation of native and the Web is actually quite simple.

1. Native-Web: Is WebView injected JavaScript, directly executes the JS code, in the Android form such as: "Javascript:[js Code Execution" ";
2. Web - Native: is to use WebView to intercept the private protocol request for related operations and return, because the Web can execute a specific URL to trigger our Native filter conditions;

　　Because the interaction between native and the Web is done in a string, we can only contract certain string formats so that they contain the actions to be performed and the corresponding data;

　　It's simple for one-way requests, but how do you support callback operations?

first Point, We have determined that the interaction between native and the Web is the only form described above. So, the approximate idea is as follows:

1, theapp receives the Web request, executes the specified action, executes a so-called callback method;

2, the callback method actually executes a JavaScript injection, to notify the Web, the operation has been completed;

3, theWeb received this message, you can execute the corresponding method and then complete the so-called callback operation;

　　Similarly, the web receives app requests as well;

　　

According to the logic above, we can save the callback interface in a map<integer,callback> when the app sends a message to the Web. Then after the web executes, you can send a specific message to native to trigger a logical callback operation on the native in the map-saved callback interface!

Originally wanted to put the code up, but back to roll, has voluminous so many lines ... Go straight to the code ...

　　

On the development of mobile-hybid