Preface: Fortunately or unfortunately, I’ve been working on a lot of cross-platform development since early in my career, from Cordova to ReactNative, from SmartTV to Android, iOS, MacOS and Windows (and the dead Windows Phone, My lovely Lumia 720 will only become an old phone), although I can’t say that I have completely figured it out, I have accumulated some thoughts and ideas. Before I forget all about it, I’m going to write this article to document the history of cross-platform development in recent years, and summarize what I’ve learned. If I have some mistakes in my old memory or some updates in my usage, please don’t hesitate to correct them.

First of all, I would like to present to you an old song by Teresa Teng, “The past can only be remembered”.

The history of cross-platform development tool frameworks over the years of programming is here. Cordova, Xamarin, Titanium, NativeScript, React Native, Electron, Uni-app, Flutter

I did a detailed analysis of the context and comparison of advantages and disadvantages. I spent an overnight sorting it out. If you like it, please click a “like” to support it.

This article is the author of AWeiLoveAndroid original, without permission, strictly prohibited reprint. For more information about Flutter, please follow our public account. There are so many exciting things about Flutter, don’t miss it.

Cordova & Ionic(Underlying Angular)

When it comes to cross-platform, most people seem to think of this little robot first.

Cordova is an early cross-platform solution, a spin-off from the earlier PhoneGap. It was the hottest cross-platform solution around the time I started cross-platform development (around 2012). Why is that? It was easy to pick up, and at the time it was competing against Xamarin and Titanium, both of which had to be paid for (more on both later).

Here is the architecture of Cordova:

CordovaWebView Component CordovaWebView Component CordovaWebView Component CordovaWebView Component CordovaWebView Component It’s a modified WebView with some Cordova API that lets you interact with Native parts. Your App is basically a Mobile Web, with the added ability to interact with Native.

Advantages: 1. Easy to use: A front-end engineer (or Web engineer, not everyone had heard of front-end in those days) who knew how to do Mobile Web(and then stumbled across Cordova and clicked) could build a cross-platform App painlessly. Ionic is easy to get started with. Writing apps on the Web is mindless. It’s so fast, writing code is like a shuttle! Doesn’t that sound appealing?

2.Cordova’s cross-platform solutions, ionic in particular, already look like most native apps.

3.Cordova has a lot of plugins to connect to Native platforms (Android and iOS). You don’t have to deal with Native interaction.

4. Ionic allows users to write once, run everywhere on Android, iOS, websites and small programs with one set of code, with extremely low development and learning costs.

But things are never as good as they seem. Cordova’s straightforward architecture is a two-edged sword, and it has its drawbacks:

Cordova(Ionic) is either a WebView or a WebView, and the Web performance experience is poor. Although it develops quickly, it is still a Web and cannot become a Native, just like you can’t become Daniel Wu or Hu Ge no matter how much you dress up. At that time, the hardware conditions of Mobile devices were very limited and only 1GB RAM was available. The performance experience of Mobile Web was very different from Native. For example, Web UI on Android is quite different from Native UI, such as high latency, frame drop, black screen, etc. Under the same hardware conditions, there is no such obvious gap on iOS, due to the differences in the underlying rendering mechanism architecture between Android and iOS platforms.

Subsequent improvement plan:

Web engineers are also aware of the seriousness of this problem and can do some tricks in JS or CSS to improve the UI experience on Android. The best of these, of course, are inoics. PS: I bought my first Xiaomi phone at that time to experience what was “born for a fever”. It was really cool at that time (purely for nostalgia). It was also a time of rapid development of smart phones, of course, along with various Mobile Web frameworks, such as JQuery Mobile, Bootstrap, etc., as well as open source frameworks and tools launched by various manufacturers, of course, there are some names. Inoic although launched a little late, but also can be regarded as “the Yangtze River after the waves push the waves before”, also can be regarded as good. The latest ionic4 controls do a pretty good job, constantly improving for the smallest UX details. Ionic Team wants to build a tool to optimize the Web -based cross-platform development experience. But the performance side of Cordova (especially rendering efficiency) is unlikely to improve significantly on the Ionic Team’s side, given how the framework is designed. Maybe you can do tricks in the JS or CSS section to speed things up (and they do spend a lot of work on it), but overall performance depends on the WebView on the platform. Some people have proposed to replace Cordova WebView with Chromium. Although it will make the app bulky, it will also improve the performance to some extent. Of course the function is not to meet the requirements, can also be patched through the native plug-in.

Phonegap, Ionic, Angular, and Cordova

What are the differences between Phonegap, Ionic, Angular and Cordova?

Originally developed by Nitobi and now owned by Adobe, Phonegap is a framework for developing cross-platform mobile applications using Web apis such as HTML, Javascript, and CSS. In 2011, Adobe/Nitobi contributed the PhoneGap source code to the Apache Software Foundation (ASF) for hosting, and the community later named the open source code “Cordova.” PhoneGap is a spin-off of Apache Cordova. Think of Apache Cordova as the engine that runs on PhoneGap, just as the WebKit engine runs on Chrome and Safari.

Ionic is a full-stack hybrid application development framework, Ionic = Cordova + Angular + Ionic UI, Ionic is responsible for page implementation.

Angular is a JavaScript front-end framework.

Cordova provides a set of native device-specific apis that enable JavaScript access to native device functions, such as cameras and microphones. Cordova is also responsible for packaging implemented pages as native apps (Android as apK; IOS is ipA form).

To put it simply, the innermost pomelo flesh is Angular, the outer shell is Ionic, and the thick outer shell is Cordova.

At the time, Cordova enjoyed a great success, but the visual performance of the architecture and hardware environments was not as good as that of the native platform, which gave the impression that cross-platform = bad. When other cross-platform games came out, a lot of developers said, “I used Cordova and it was a terrible experience, I’d rather do it native than cross-platform.” So I said WebView.

Xamarin

Next comes “Xamarin,” the C# family of frameworks.

Xamarin is around the same time as Cordova. It was already a popular cross-platform framework before It was acquired by Microsoft. However, unlike the open source Cordova, Xamarin was paid for at the time, which is probably why it is not as popular as Cordova. Another reason Xamarin hasn’t caught on: it uses C# as the dominant development language.

PS: I’m not against C#, I’m not saying it’s bad, I’ve written in C# too, it’s a lot like Java. Java: you C# can imitate my face, you can’t imitate my soul. Before.net Core, the C# family of products was relatively closed and had few open source resources compared to the slowly growing popularity of Javascript at the time, which resulted in the inherent disadvantage of Xmamrin.

Xamarin Android terminal architecture:

Xamarin iOS terminal architecture:

As you can see, Xamarin is much more complex than Cordova, with a full set of Android & Java Bindings and a cross-platform one. NET Runtime — Mono. Xamarin is roughly divided into several parts: Xamarin.android, xamarin.ios, Xamarin.mac (which came later), and Xamarin.Forms.

Interested can look at the website: dotnet.microsoft.com/apps/xamari…

Xamarin and Cordova have both had their name changed, and I’m sure some people will ask about the relationship between Xamarin frameworks:

.net Framework,.NET Core, Mono, Xamarin

.NET Framework: The first version was released by Microsoft in February 2002 and only supports development and running on the Windows platform (highlighted: closed source, commercial).

Mono: Mono is an open source framework published by third-party company Ximian, which first released Mono version 1.0 in June 2004. Mono is supported on Linux, Windows, Unix, Android and other platforms. (Wild version of the.NET Framework open source implementation)

.NET Core: Microsoft will launch in 2014. NET Core is open source and its implementation was released in June 2016. NET Core 1.0. The content includes cross-platform virtual machine CoreCLR, implementation subsets of.net Framework APIs, and new class libraries. (Emphasis: Open source, based. NET Framework added some new class libraries.

Xamarin: Formerly known as Mono, Xamarin was acquired by Microsoft in February 2016. The Mono project was acquired by Xamarin in 2011. Support Windows, Linux, macOS, iOS, Android and other mainstream platforms and operating systems.

To better illustrate the problem, here’s a picture from a blogger: www.cnblogs.com/wer-ltm/p/8…

Finally, the pros:

1. Coding in C# speeds up the engineering cycle by reusing up to 96% of the source code. Xamarin also makes maintenance and updates much easier.

2. Performance close to native. It has much less performance loss than Cordova. Cordova has to bear the heavy cost of Web Rendering, whereas Xamarin only has the cross-language cost, which is relatively light, which is the advantage it brings to visual Rendering. For example: built using the Xamarin.Forms tool, which transforms application UI components into platform-specific interface elements at application runtime.

3. Enrich built-in functions. Xamarin components provide thousands of custom UI controls, a variety of charts, graphics, themes, and other powerful features that can be added to applications with just a few clicks. This includes built-in payment processing (such as Stripe), beacon and wearable integration, out-of-the-box push notification services, cloud storage solutions, multimedia streaming capabilities and more

Let’s look at the downsides:

1. Compatibility issues with third-party libraries and tools: Previously, new Native apis had to wait for official packages to be used, but now Xamarin is open source, but it is still slow. Also, although Xamarin has its own component store, you may need specific features or integrations in your application that these platforms don’t provide, so this can be a pain in the ass. Some people have also given me feedback that some of the details of android and iOS interaction are not so good.

2. Support for the latest updates to native platforms will not be forthcoming. This is entirely up to the Xamarin development team, these changes and/or the introduction of new plug-ins etc will take some time, and despite Xamarin’s claims of same-day support, there may still be some delays.

2.Xamarin open source ecosystem issues. The Xamarin community is much smaller than iOS or Android. Therefore, finding an experienced Xamarin developer can be a challenge.

4. The application is large. Xamarin applications are generally larger than Native applications, for example: a simple “Hello, World” application for Android may require up to 16 MB.

5. Not suitable for heavy graphics applications. Building games in Xamarin, rich custom user interfaces, or complex animations can be very limited.

6. Use MvvmCross(www.mvvmcross.com/), need to do two sets of interface, Android performance has been improved, but occupy less resources, third-party library conversion trouble. MvvmCross is a framework developed specifically for Xamarin and the mobile ecosystem. It supports Xamarin.ios, Xamarin.android, Xamarin.mac, Xamarin.Forms, Universal Windows Platform (UWP) and Windows Presentation Framework (WPF).

Titanium

Titanium’s logo looks like this:

Sorry, I am not familiar with this, I just remember that there was also a charge at the beginning, and then I walked in the form of JS to Native Binding, but I heard that Lei Super much, SO I didn’t step on it, if there are friends who have used it before, you can come and talk about your experience. I noticed that Github has open source, is it open source now? The github code is as follows: github.com/appcelerato…

The following pros and cons are summarized from the blog: devblog.axway.com/mobile-apps…

Advantages:

1. Directly invoke native platform features and functions without the need for other tools. Titanium is designed to provide a more advanced API for cross-platform native mobile development, so you have direct access to a wide range of native features and functions, from user interface components and socket interfaces to notification system integration. Titanium’s goal is to reduce the difference in functionality between Titanium applications and pure native applications to almost zero.

2. Integration and extension are easy. Because Titanium can be extended with visual components that plug into the same view hierarchy as the rest of the application, you can eventually implement any possible user interface on the underlying console. Need to use special native code to scroll a TableView at 60fps? You can do this. Want to seamlessly integrate your game’s OpenGL drawing surfaces while preserving the logic of running loops in JavaScript? You can do this. You can integrate these user interface extensions directly into applications written with the core Titanium API.

3. Get close to the native experience. The look and feel of Titanium applications is also an advantage when using common user interface window components. No visual emulation (either by applying CSS, or rendering user interface window components using OpenGL or Flash). When you create NavigationGroup, it is supported by the actual UINavigationController on iOS. Animation and behavior are consistent with what native application users would expect because you use the same user interface controls.

4. Low barriers to entry. Because Titanium provides an advanced native programming API through JavaScript, it significantly lowers the barrier to entry in native programming for anyone who has used an ECMAScript-based language.

Disadvantages:

1. The scope of the Titanium API makes it difficult to add new platforms. Implementing the Titanium API on a new legacy platform is a daunting task. Because of this, Titanium is only available on what are currently considered the most important mobile platforms: iOS, Android, and the Web.

2. Mobile Web browser support is not market-ready. Titanium continues to work on improving the performance and feel of our set of UI window components, as well as the implementation of the core Titanium API.

3. Titanium’s internal framework still suffers from sub-optimal API implementation due to the large level of abstraction it provides. In some cases, some UI components cannot perform as well as native UI components, such as very large table views with highly customized layouts. Optimizing the core user interface components remains a top technical priority for the Titanium team.

4. Also, scaling Titanium wasn’t easy due to the ambitious goals of the Titanium platform. To effectively integrate a new native control or API, a deep understanding of Titanium’s architecture and environment is essential. Developer experience, API documentation, and general guide for module developers.

NativeScript

NativeScript was developed by Telerik (who did Kendo UI) and later converted to open source. Their idea is similar to Titanium in that they want to bind JS to Native in the form of Reflection. NativeScript does not use Java reflection to dynamically find apis because of poor performance. It generates a pre-generated Metadata in the APK for searching and matching the mapping.

Advantages: 1. Achieved great expansibility by means of mapping. NativeScript maps all Android/iOS apis to NativeScript Runtime, allowing developers to call these native apis directly from Javascript, similar to V8 engine. This gives NativeScript super extensibility because you can use “any” API that native apps can use, including third-party lib, without doing any extra processing; When the platform has API changes, all changes can be used immediately (unless the reflection mechanism is broken in the update), unlike Xamarin, which has to wait for the team to make the update. From this point of view, there is a slight advantage. 2.NativeScript also does a good job on Views and UI integration with modern Angular/Vue for high efficiency. In addition to the Native components, it also provides a CSS subset for USE as STYLING, which makes it more convenient for UI development than Native apps. NativeScript started out using Angular for its UI, but they have since separated three development approaches: basic JS/TS, Angular, and Vue (which is why I’m not going into Weex), and all of them can feel data-binding. 3.NativeScript also has the great advantage of treating TypeScript as a first-class language (NativeScript itself is written in TypeScript). This is a good thing to think about, because in the case of reflection, API reflection without TypeScript can be a real death experience.

Disadvantages: 1. Developers must have a certain degree of Native knowledge. Because NativeScript Runtime is based on V8 /JavaScriptCore, not Webkit, you can’t use any WebAPI (unless someone implements it for you). For example, common XmlHttpRequest or FETCH is implemented in the Webkit layer, and NativeScript requires the use of native platform implementation for encapsulation, which also increases developers’ reliance on native knowledge. 2. The main reason why it is not red is that it appears at a bad time. Just a few months after NativeScript was released, React Native burst onto the scene with the superhuman spirit of the React community. If it had happened earlier, the landscape would be different today.

NativeScript

If you’re in the Angular camp yourself, NativeScript is a good thing to try.

Election

Originally called Atom-shell, Electron was a byproduct of GitHub’s release of Atom, an open source editor, but the byproduct became so much more influential than Atom Editor that it was renamed a separate project, now called Electron. Electron is simply Chromium+Node.js and communicates with each other via IPC.

Advantages: 1.Electron has been very mature so far, developing Electron app is as simple as drinking boiled water for engineers with a certain level of JS. The front end is a complete Web environment, and there is Chromium with high compatibility and leading edge of The Times, which can use various advanced grammars and WebAPI; The backend is Node.js, and the version is quite advanced. 2.Electron also doesn’t need to worry about insufficient interaction with the platform. Thanks to the abundant Node.js ecosystem, you can find modules for most of the functions you need. Like the tagline on the website, Electron takes care of a lot of the chores for you, so you just have to focus on the core features.

Disadvantages: 1. Bloated. You have to bring the whole Chromium in, so the smallest HellowWord can compress to tens of megabytes, but that’s not a problem for desktop software. 2. Memory consumption and startup time. Because of Chromium in the front end, Electron has been criticized for its memory consumption. It is common for Electron to consume 1XX MB of memory when it starts, and the number will rise sharply if the application complexity is high. Electron’s team is probably powerless, but it’s up to Chromium to fix the problem in the future. Similarly, Electron team can do nothing about the startup time, and can only see whether Chromium can improve the problem in the future. The startup time of Chromium will become a bottleneck.

If you want to develop a desktop-based cross-platform app, the Electron is the perfect choice. Whether it is the overall maturity, community popularity, available resources, flagship showcase, from all aspects are reassuring.

Uni-app (Using Vue at bottom)

Later, my friend recommended using HBuilder (later upgraded to HBuilderX), which is very easy to develop, so I went to the HBuilder website to search and found a framework called Uni-App. Uni-app is a framework for developing all front-end applications using vue.js. Developers write a set of code that can be distributed to iOS, Android, H5, and various small apps (wechat, Alipay, Baidu, Toutiao, QQ, Dingding). It is the ultimate cross-port tool for the Web. After all, after eating a few more years of rice, the research is not the same ah… O(∩_∩)O haha ~). Uni-app is a must for lazy people. It uses vue.js to write your business code.

First, its advantages:

1. Use HBuilderX to create project templates in one click. HBuilderX and UNI-App are made by the same company, as well as other frameworks that allow you to use HBuilderX to create the type of project you want and write your code.

2. Uni-app is friendly to front-end developers. The packaged components are exactly the same as those of wechat mini programs.

3. Uni-app has strong expansion capability, encapsulated WITH H5+ and supports NVUE, as well as native Android and ios development. You can change your mobile app and H5 app to UNI-app. Uni-app comes with a complete applet engine built into the app side, complemented by an optional WEEx engine for performance-demanding developers. This is why UNI-App can run wechat applet code normally on the app side. No other Cross-platform Web framework can do this.

Let’s talk about its disadvantages:

1. Using Vue development, you must be familiar with H5, Vue, small programs, learning costs are very high. If you are not familiar with these words, take the time to learn new frameworks such as applets and Vue.

2. Uni-app has not been released for a long time, and the compatibility of mobile platforms is still incomplete in many aspects, with many defects. The performance of Uni-App on Android platform is worse than that of wechat mini program and iOS, which needs to be improved.

3. Performance is still an issue. After all, the JS used at the bottom of uni-App, even if it can be compiled into native programs, is a problem in terms of performance and compatibility. If it is just for Web, it is fine.

React Native

I was one of the first people to use React Native in production environments (it was version 0.0.3 at that time, the first public version, think I was really bold at that time).

Instead of reflecting like NativeScript, ReactNative constructs a set of RCTBridges for interaction between JS and Native. If you want to use Native API or native component, you need to bridge in the Native layer. Then import it into js (similar to how you would write Node’s C++ addon).

Advantages: 1. The response of ReactNative today is largely due to the overall development advantages of the React ecosystem and the fact that Facebook has already carried out product practice on its app, which is a shot in the heart for many people. Besides, large companies such as Airbnb and Uber have also adopted it. More caused to promote the effect. 2. The output package will be smaller than NativeScript, and the architecture will be simpler. Because ReactNative does not reflect like NativeScript, but constructs a set of RCTBridges for interaction between JS and Native, the printed packages are smaller than those of NativeScript, and the architecture is simpler. 3.ReactNative was launched with the slogan “Learn once, Write Everywhere”, allowing different platform features on different platforms. The architecture of this central idea makes it easy for ReactNative to scale to other platforms, For example, react-Native MacOS implemented by third party developers, React-Native AppleTV (later integrated into the official), React-Native Windows (originally named UWP) developed by Microsoft, and React-Native of Samsung – Tizen, ReactNative can be seen on almost every platform, whether it is mature or not remains to be studied.

Disadvantages: 1.ReactNative is not in a stable state at present. It will be updated every two weeks, which should be paid attention to during development. 2. You must have knowledge of the Native platform. It should be said that every major cross-platform solution since Cordova requires some level of native platform knowledge. While ReactNative can compile and package a working app without any native knowledge compared to NativeScript, this greatly limits your scalability and can accidentally turn your CPU into a ticking time bomb without any knowledge of native rendering and how it works. 3. It is very troublesome to bridge each native Module by itself.

Weex(Vue at the bottom)

Weex data is too little, I will not do the introduction, anyway, I stepped on the pit, and then gave up WEEx, documentation is not complete, API lack, expansion function is not perfect, performance is not where…

Flutter

Flutter is a new high performance, high consistency, cross-platform development framework released by Google.

【 Advantages: 】

Dart is available for Android,iOS,Web(Beta), Desktop(Alpha), and Windows PC and Linux platforms. So you don’t have to worry about how the framework works for you. You only need a command line to run your code on the corresponding platform, for example, flutter run XXX, where XXX refers to the name of your platform device. For example, “flutter run chrome” means to run the application on the browser. 2. Independent Skia rendering engine, high performance and consistency. Your code compiles into a program with 60bps performance. 3. Rich component support, you can do according to your ideas, the expansion is very powerful, MD style, as well as ios style components, enough to meet the usual development needs. The Flutter layout is based on the react and Flex ideas. 4. Rich community support. Currently commonly used components and some third-party packages have been open source, enough to deal with the usual development. If you don’t know, I’ve collected a collection of Flutter tools that contain everything you need to quickly find what you need. You can check them out here: github.com/AweiLoveAnd… 5. Open source and free. You can modify the kernel engine code, as well as the component code, and customize your development. Big companies like Xianyu, Tencent, Bytedance and others have customized their App development solutions based on Flutter, if you are interested. 6. Use the Dart language for development. Dart syntax is a lot like JS+Java+Swift+Kotlin+C#+TypeScript+JavaScript+PHP. You don’t have to worry about it. You can still develop, just in a different language, but much of it is familiar. Basically, the cost of getting started is very low. The disadvantages: If you are not familiar with native development and third-party packages cannot meet your needs, then you need to write or modify existing plug-ins. This requires learning a little knowledge of native development (in fact, this is also an essential step for many cross-platform technologies). Of course, if you have Android or ios programmers in your company, Ask them to help write a plugin, which is a minor problem for them.

Comment on Flutter:

Flutter, Google’s own son, is currently the most popular cross-platform framework. It is also the closest to native of all cross-platform frameworks, and the most efficient. At present, the application is in the mobile terminal (Android terminal, iOS terminal), and the Web has also released a preview version, but it can not be really put into the small program or Web project practice. Currently, there is no real alternative to the Ionic framework on the Web. The Dart language community has been growing for more than a year. There are all kinds of open source libraries and tools for Flutter and Dart on Pub. dev. The development of Flutter is good, but the Development of Flutter Web is not yet complete. Some package level 1 browsers on many Web sites are not fully functional.

Comment on Flutter:

I do front-end, my friend is mobile, he takes the Flutter route, he is doing Android development, using Java, he said that Flutter is close to native experience, very good. However, our company needs to launch the App quickly and still takes the route of WebView. He and I made a small Demo at the same time to compare and find that the App’s performance experience is really great. The order is as follows: native >= Flutter > WebView.

A few final questions?

1. The most difficult thing about cross-platform is the difference between different platforms. How to solve this problem?

2. What’s the difference between Cordova and RN and NativeScript?