Go to its h5, I still use js to write native cross-platform apps

Smartphones are becoming more and more powerful and have gradually replaced the role of computers. Baidu, Tencent, and Alibaba’s mobile DAUs are gradually catching up or even surpassing computer users. There are more and more companies shouting "mobile first", App developers emerge as the times require, and the team is getting bigger and bigger. Some people take this opportunity to embark on the road of entrepreneurship.

1. The tragedy of APP development

Mobile development is not as glamorous as one might imagine.

Every native application development project is a huge pit. Either wait for your competitors to beat you through mobile internet technology, or jump into the pit to recruit people to develop mobile applications. Writing an app is really a chore. Making an app usually requires three sets of people, one for android and one for ios; if there is a website, another web developer needs to be configured, and the development cost will be doubled. The most terrifying thing is that it needs to face a lot of underlying technical traps such as black screen, flashback, and screen adaptation. In addition, the frequency of technical personnel loss and replacement is high, the maintenance cycle of the business system is long, and the compatibility problems after the upgrade of the operating system platform (such as the forced adjustment of the UI layout structure of IOS7 and the forced upgrade of the 64-bit kernel of IOS8). Technological traps are everywhere, and it's not affordable for the cost of each small project.

Many companies are new start-ups, and few can afford the three-man crew. Usually one person does the work of three people. If a R&D expert can do both android and ios, he can become a hot cake in no time, and he will get a lot of wages.

Personnel issues often do not require research and development, but in the development process, there will be practical problems such as high development and maintenance costs, difficulty, and difficulty in adapting many operating system versions. That's even more of a headache!

 

2. The solution to H5

HTML5 standard finally passed! Many people see its "sunny" tomorrow on the mobile side. A set of html5 code can adapt to android, ios, wechat, web and other multi-terminal platforms. Many people are clamoring that the future of mobile cross-platform development is the world of H5! Many "bricks" also said that HTML5 will subvert the native App world.

       Based on this, a number of cross-platform H5 cross-platform development platforms/tools have been born: PhoneGap, Appcan, HBuilder, APICloud...

However, are things really as good as imagined?

 

Before, my brother believed the words of the "brick family" and got on the H5 thief ship. As a result, the days of bitterness and pitfalls came...

       Based on the experience of blood and tears, the H5 application still has the following problems:

 

1. H5 has a natural “sexual dysfunction” disorder

The term "sexual function" was coined by the CEO of HBuilder. That is: the performance is not as good as the native, the tool is not as good as the native, and the function is not as good as the native. HBuilder and a host of cross-platform developers claim to have solved these problems.

H5 has been developed for so many years, and on old machines, even on high-end machines with versions below android 4.2, the lag is very obvious. Although the hardware performance of the thousand yuan machine has soared in the past year, the thousand yuan machine can also buy 8 cores. But if you try to write an H5 app, without professional performance optimization, the pages will still freeze if you open too many pages.

There are many optimization points in the application of H5. If you have not experienced several pit trips, it is difficult to come up with an application with good performance.

Don't listen to the hype of many cross-platform development tool vendors. A slightly more complicated APP is stuck, and it cannot be solved in the short term.

 

2. There are risks of source code leakage, hacker code injection, etc.

For the app written by H5, you only need to change the suffix of the installation package to zip, and after decompressing, you can directly see the source code, there is no secret at all. Think about it, how do you feel about an app that you spent months rushing to work on, the source code can be taken away at will, and then repackaged into a new app after a little modification?

What's even more terrifying is that the Alipay key and WeChat encryption key you applied are all directly exposed to the cracker...

Some cross-platform developers claim to provide obfuscated encryption, but in reality it's useless at all. No matter how you encrypt, the browser must decrypt the page before it can display it properly. On Android 4.4 and later versions, you can directly extract any content of the original page in the browser opened by the app with the Chrome browser when you connect to the computer, you can even set breakpoints for debugging, and use the browser console to inject code at will.

 

3. The controls are scarce, and it is difficult to integrate the third-party SDK

H5 app, if you have art foundation, it is very convenient to use HTML to describe the interface. But if you want to call some functions of the system, you need to see if your cross-platform tools support it. Once it has not been provided, it is bitter B.

Although many developers claim that their own tools are easy to encapsulate control extensions. But if it takes a long time, if I can develop natively, I will use your tool to dry hair. Brother, write natively.    

I have encountered this problem before. To write an APP, a third-party SDK is required, and the current development tools do not provide such controls, which makes the project impossible. After that, I went to the developer BBS every day to ask my grandfather to tell my grandmother for mercy and help you provide it. For a month in a row, people didn't give you any favors at all, and the project finally ended reluctantly.

 

         Since the cross-platform development of H5 is not reliable, what should we do?

 

 3. Native cross-platform solutions

(1), React Native solution

The emergence of React Native is a pleasant surprise. It not only has the user experience of Native, but also retains the development efficiency of React. This concept seems to cater to the pain points of common films in the industry. The number of github stars exceeded 10,000 in less than a week of open source, and it is currently 27,000+.

The principle of React Native is to use React abstract views in JavaScript to operate as native UI components of the system, instead of DOM elements for rendering. It is different from webkit or any known browsers. It uses a self-encapsulated rendering engine to generate native UI under different platforms. At the same time, JS and Native communicate with each other through Bridge to achieve corresponding functions.

This technology unifies the independent interface description file with the native UI. I personally think it is the most advanced and most representative of the future development trend among the known middleware products.

 

React Native looks beautiful, but the reality is "skinny".

At present, there are still some problems in the use of React Native:

1. The interface layout is difficult

React native has nothing to do with HTML5. Although the language it uses is still javascript, it uses a custom react way to declare the interface, no HTML and css! For the majority of developers, you have learned HTML and CSS in vain, and re-learn the grammar of facebook.

At the same time, the layout method of react is very different from the previous traditional concept, and there is no visualization tool. If you want to lay out a complex interface, it is very laborious.

2. The installation package is too large

React native is its own rendering engine, not webkit or any browser we are familiar with. Equivalent to facebook's custom browser. The size of the engine package is not small, hello world is 7M. If a medium-function APP is implemented, a package of more than ten megabytes cannot run.

 

3. Development tools

React native does not have a supporting ide, and it is very troublesome to develop and debug. Without a native development foundation, it may not even be possible to set up a development environment.

Packaging is also inconvenient, and it is impossible to debug or package ios applications without a mac computer.

 

4. Not in line with national conditions

Like developing an app in China, it is normal to embed some third-party development kits. For example, third-party libraries such as WeChat and Weibo should be embedded for login, Huanxin should be embedded in chat, Umeng should be embedded in statistics, and Alipay should be embedded in payment...

How are these third-party libraries integrated into the React Native project? If you're praying that someday facebook will help you integrate and release some control packs, then you wait.

 

(2) Solution of DeviceOne

DeviceOne is an emerging mobile cross-development platform. It was officially released in May 2015 (their website SEO is very bad, and there is little publicity, so few people know about it).

DeviceOne adopts a solution similar to React Native. It has provided a large number of rich UI components and API components, all of which are genuine pure native implementations, and the running applications are also pure native UI renderings. You don't feel stuck when you open more than a dozen pages.

All UI components and functional components under the platform have been abstracted into cross-platform components that can be freely extended. Even Webkit itself is only degenerated into an ordinary UI component in the model. App developers can freely choose js scripts and lua scripts. to write business logic. You only need to download javascript to complete the pure native app development, and the product made is so smooth...

Developers can choose a list of controls to be packaged, and the package is very small, usually within 3-5M. And because it is a native app, the code is all encrypted, and hackers can't simply decompress the code to steal the code.

At the same time, DeviceOne realizes the separation of interface and business logic. The UI can be generated by dragging and dropping directly through the IDE, which is a cool word!

WYSIWYG interface

DeviceOne has provided more than 80 controls, which can not only DIY a very dazzling interface, but also add many third-party SDKs to the ground, which is very convenient to use. Media, audio and video effects that are difficult to accomplish with H5 can be easily achieved with DO.

In addition, DeviceOne does not exclude H5. You can completely load the previously implemented html code with the WebView control, realizing the reuse and transition of historical assets.

Officially provides three demo app source code:

More demo source code can be found in the forum.

After I downloaded and read the code, I got started in about two days. After actually using it to develop an APP, there are not too many pits in the development process, and the process is still very good.

 

         Just use JS to write native APP, wow, it's so cool.

         When I have time, I will write a series of articles to introduce it and the whole process of using it to develop an APP to help people who have cross-platform APP development like me to develop it more conveniently.

         Let's use JS to write native APP together!

 

 

Reprinted from OSChina, original address: http://my.oschina.net/qinerg/blog/624956?p=7#comments

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327091201&siteId=291194637