Preface: I do not know Fortunately or unfortunately, from the early career was often done in a variety of cross-platform development, from the early Cordova to the present ReactNative, from SmartTV to Android, iOS, MacOS and Windows (Windows Phone still dead , my lovely Lumia 720 only become a machine elderly), although not say all mastery, but how many have accumulated some experience and ideas. Before taking advantage of memory degradation forgot to be smooth, write articles to record the history of the development in recent years, cross-platform development, the way to sum up experience, while others may be incorrect or the age-old memory usage updates, also please feel free to correct me.
To send a Teresa Teng's songs "past recollection only" dedicated to everyone.
Programming experience in those years of cross-platform development tools, framework for the evolution of history, you want all here. Cordova, Xamarin, Titanium, NativeScript, React Native, Electron, uni-app, Flutter
I made a detailed analysis and comparison of the advantages and disadvantages of the ins and outs, spent a night finishing, like it, like a point of support for it, thank you for your attention.
This paper is AWeiLoveAndroid original, without permission is forbidden. No more dry welcome public attention [ Flutter those things ], a lot of wonderful, do not miss oh.
Cordova & Ionic (underlying use of the Angular)
When it comes to cross-platform, like most people would first think of the little robot.
Cordova is a very early cross-platform solution, it is from the earlier PhoneGap branch out. In those days I was just getting started with cross-platform development (probably in 2012), it is the most popular cross-platform solution. why? Because it is quick and simple, and then its opponent is Xamarin with Titanium, both of which are to be paid (both back will be introduced).
Let's look at Cordova architecture diagram:
Cordova的架构很简单，就是一个简单的Activity（为了避免麻烦，底下的架构都用Android的观点来解释，绝对不是我iOS不熟喔，只是内容有限，就做一部分解读了），上面搭载一个CordovaWebView Component，他是一个改造过的WebView，加装了一些Cordova API，让你借此和Native的部分交互。你的App基本上就是一个Mobile Web，只是多了一些跟Native交互的能力。
优点：
1.好上手：前端工程师（或Web工程师，那个年代还不是大家都听过前端这个词）只要知道怎么做Mobile Web(只要会Web，然后刚好遇到了Cordova，刚好一拍即合)，就可以无痛的构建出一个跨平台的App，Ionic入门很容易，用Web写App简直就是无脑操作，快得很，写代码就是一把梭！听起来是不是很吸引人呢？
2.Cordova的跨平台解决方案,尤其是ionic，已经看起来和大部分原生app一样了。
3.Cordova有丰富的插件去衔接Native平台(Android和iOS)，你基本上很少去管Native的交互，社区也比较完善，还是很不错的。
4.使用Ionic可以一套代码在安卓端、iOS端、网站端、小程序端通吃，做到了“write once, run everywhere”，开发和学习成本极低。
但是事情总是没有想像中的美好。Cordova这种简单明了的架构是个两面刃，它也有它的缺点：
Cordova(Ionic)成也WebView，败也WebView，使用Web性能体验很差。虽然它开发起来很快，但是终究是个Web，也成不了Native，就好比你再怎么打扮也成不了吴彦祖，胡歌一样的道理。那个年代Mobile设备的硬件条件非常有限，还只是1GB RAM的时代，Mobile Web的性能体验和Native相比起来差距非常大。比如：Android上的Web UI跟Native UI比起来差异很大，比如iOS上的高延迟，掉帧，黑屏等。相同硬体条件下，iOS 上面就没有那么明显的差距，原因归结于Android和iOS两个平台的底层渲染机制架构不同所产生的差异。
后来的改进方案：
Web工程师们也意识到了这个问题的严重性，在js或是css部分可以做一些trick來做GPU加速来改善Android上的UI体验。其中最好的当然就是Inoic了。PS：那个年代我买了第一台小米手机，体验一下什么是：“为发烧而生”，那个年代小米那个配置确实很牛逼啊（纯粹为了怀旧）。那个年代也是智能手机快速发展的时候，当然随着而来的就是各种Mobile Web框架了，比如：JQuery Mobile、Bootstrap等等，还有各大厂推出的开源框架和工具，当然还有一些叫不出名字的。Inoic虽然推出的晚一些，不过也算是“长江后浪推前浪”，也算是不错的了。最新的ionic4控件做的相当完美，为了一些十分微小的UX细节不断的改进。另外Ionic4好像有想要解决一些性能问题，推出了一个capacitor的工具，Ionic team是想做一個工具来优化web-based的跨平台开发体验。但是Cordova的性能部分（特別是渲染效能）基本上Ionic team这边应该是不太能做什么大的改进的，因为框架就是那样设计的。或许在js或是css部分可以做一些trick來做加速（他们也确实花了很多工在这上面），但是整体的性能还是依赖于平台上的WebView。之前有人提出把Cordova webview替换成Chromium，虽然会造成app体积臃肿，不过也在一定程度上提升了性能。当然功能是满足不了需求的，也可以通过原生插件来进行修补。
【Phonegap、Ionic、Angular和Cordova的区别和联系】：
很多人都搞不清楚的问题，在这里我也帮大家解答一下：Phonegap、Ionic、Angular和Cordova的究竟有什么区别和联系？
Phonegap原本由Nitobi公司开发的，现在由Adobe拥有，它是一个使用HTML、Javascript、CSS等Web API开发跨平台的移动应用程序的框架。
2011年，Adobe/Nitobi把PhoneGap的源代码贡献给Apache软件基金会（ASF）托管，后来社区将这份开源的代码取名位：“Cordova”。PhoneGap是Apache Cordova的一个分支。你可以这样想，Apache Cordova是一台发动机，运行在PhoneGap上，就像WebKit浏览器引擎运行在Chrome浏览器和Safari浏览器上。
Ionic 是一个全堆栈的混合应用开发框架， Ionic = Cordova + Angular + Ionic UI，Ionic主要功能是负责页面的实现。
Angular 是一个JavaScript的前端框架。
Cordova提供了一组原生设备相关的API，通过这些API可以使用JavaScript访问原生的设备功能，如摄像头、麦克风等。同时Cordova负责将实现的页面包装成原生应用（Android是apk的形式；iOS是ipa的形式）。
简单的打个比方吧：就像你吃柚子一样，最内层的柚子瓤是Angular，柚子瓤外面的一层皮就是Ionic，而最外层的厚厚的柚子皮就是Cordova。
在那个年代Cordova风风火火了一阵子，但是在在架构及硬体环境下呈现出来的视觉表现，不太乐观，远远比不上原生平台的体验，所以给人一种“跨平台=效果差劲”的错觉。后来其他的跨平台推出时的时候，很多开发者都会说：“我之前使用Cordova，那个体验太差了，我宁愿原生的做，也不做跨平台了”，所以说成了WebView，败也WebView，树大招风，Cordova招你惹你了，居然躺枪，看来火起来了在哪里都被提起，躲都躲不过啊。
Xamarin
接下来登场的是C#家族的框架“Xamarin”了。
Xamarin跟Cordova差不多是同一个时期的产物，它在被微软收购之前，就已经是小有名气的跨平台框架了，不过跟开源的Cordova不同，Xamarin当时是需要收费的，这也可能是它的名气不如Cordova的原因吧。另一个Xamarin没有红起来的原因是：它使用C#当主导开发语言。
PS：我不是针对C#,不是说它不好，我也用过C#写过程序，很像Java语言的。当年就是借鉴Java语言出道的（Java：你C#可以模仿我的脸，你不能模仿我的灵魂）。在.NET Core还没出现之前,C#家族的产物都是相对的比较封闭的，开源的资源比较少，相比当时的慢慢火起来的Javascript来说，简直是太少了，这就造成了Xmamrin先天上的劣势。
Xamarin android端架构图：
Xamarin iOS端架构图：
从图中可以看出Xamarin比Cordova复杂多了，有一组完整的Android & Java binding，还有一个跨平台的.NET runtime — Mono。Xamarin大致上分成几个部分：Xamarin.Android、Xamarin.iOS、Xamarin.Mac（后来才出现的）以及Xamarin.Forms。
感兴趣的可以看看官网介绍：https://dotnet.microsoft.com/apps/xamarin
这里我又要来顺便科普一下，Xamarin和Cordova都出现过改名风波，肯定有人会问的Xamarin的几个框架之间的关系：
【.NET Framework、.NET Core、Mono、Xamarin之间的区别和联系】：
.NET Framework:微软2002年2月发布第一个版本，只支持在Windows平台上开发和运行（重点圈起来：闭源，商业化）。
Mono：Mono是一个开源框架，它是第三方公司Ximian发布的，最早在2004年6月发布了Mono 1.0版本，支持在Linux、Windows、Unix、Android等平台。（野生版的.NET Framework开源实现）
.NET Core：微软在2014年将.NET Core开源，2016年6月发布其实现.NET Core 1.0。内容包括跨平台虚拟机CoreCLR、.NET Framework APIs的实现子集以及新增类库等。（重点：开源，基于.NET Framework新增一些类库）
Xamarin：Xamarin的前身是Mono，Mono项目几经转手，2011年落入Xamarin公司手中，2016年2月，微软正式收购Xamarin。支持包括Windows、Linux、macOS、iOS、Android在内的各种主流平台和操作系统。
为了更好地说明这个问题，借鉴网友的一张图表示：
此图片来源于博主：https://www.cnblogs.com/wer-ltm/p/8776846.html
最后来看看优点：
1.使用C＃编写代码，可以重复利用多达96％的源代码加快工程周期。同时Xamarin使维护和更新变得更加简单。
2.性能接近原生。它的性能损耗比起Cordova少的多。Cordova必须承担Web Rendering所带来的巨大损耗，但Xamarin只有跨语言层面的损耗而已，相较起来相当轻微，这也是它在视觉渲染上带来的优势。比如：使用Xamarin.Forms工具构建，该工具可在应用程序运行时将应用程序UI组件转换为平台特定的界面元素。
3.丰富内置功能。Xamarin组件提供了数千个自定义UI控件，各种图表，图形，主题和其他强大的功能，可以仅添加到应用程序中点击次数很少。这包括内置支付处理（如Stripe），信标和可穿戴设备集成，开箱即用推送通知服务，云存储解决方案，多媒体串流功能等等
再来看看缺点：
1.与第三方库和工具的兼容性问题：以前是新的Native API必须等待官方的封装才能使用，不过现在Xamarin也开源了，但是还是比较慢。另外，尽管Xamarin拥有自己的组件商店，但您可能需要在您的应用中需要特定的功能或整合，而这些平台并未提供这些功能或整合，所以这一点就很蛋疼了。有些网友也给我反馈过：android和iOS的一些交互细节也会不太好。
2.对原生平台的最新更新的支持不会很及时。这完全取决于Xamarin开发团队，这些更改和/或引入新的插件等需要一些时间，尽管Xamarin声称提供当天的支持，但仍然可能有些延误。
2.Xamarin开源生态系统问题。Xamarin社区比iOS或Android的小得多。因此，找到一个有经验的Xamarin开发人员可能是一个挑战。
4.应用程序比较大。Xamarin应用程序通常比Native应用程序大，比如：Android的一个简单的“hello，world”应用程序最多可能需要16 MB。
5.不适用于重图形应用程序。在Xamarin中构建游戏，丰富的自定义用户界面或复杂的动画变有很大的限制。
6.使用MvvmCross(https://www.mvvmcross.com/)，需要做两套界面，android性能有所提高，但占用资源少，第三方的库转换麻烦。MvvmCross是专门为Xamarin和移动生态系统开发的框架。它支持Xamarin.iOS，Xamarin.Android，Xamarin.Mac，Xamarin.Forms，通用Windows平台（UWP）和Windows Presentation Framework（WPF）。
Titanium
Titanium的logo就是下面这个：
对不起，我跟这个不熟，只记得当初也是要收费的，然后走的是JS to Native Binding的形式，可是听说雷超级多，就没有去踩了，如果有曾经用过的朋友们，可以来聊聊你的体验。我以外的发现了github有开源代码，难道现在开始开源了？github代码如下所示：
https://github.com/appcelerator/titanium_mobile
以下优缺点总结来源于博客：
https://devblog.axway.com/mobile-apps/comparing-titanium-and-phonegap/
优点：
1.直接调用原生平台特性和功能，无需其他的工具。Titanium的目的是为跨平台的原生移动开发提供一种更高级的API，所以你可以直接访问一系列广泛的原生特性和功能，从用户界面组件、插座接口到通知系统集成。Titanium的目的是，将Titanium应用程序和纯原生应用程序之间在功能方面的差异缩小到几乎为零。
2.集成和扩展很方便。由于Titanium可以用插入到与应用程序其余部分一样的视图层次体系的可视组件来扩展，你最终能够在底层原生平台上实现任何可能的用户界面。需要使用特殊的原生代码，让表格视图（TableView）以60fps的速度滚动？你能做到这一点。想无缝地集成游戏的OpenGL绘制曲面，同时用JavaScript保留运行循环的逻辑？你能做到这一点。你可以把这些用户界面扩展直接集成到用核心Titanium API编写的应用程序中。
3.接近原生体验。使用常用的用户界面窗口组件时，Titanium应用程序的外观和感觉也是这种平台的一个优点。不用进行可视仿真（或通过应用CSS，或者使用OpenGL或Flash渲染用户界面窗口组件）。当你创建NavigationGroup时，它得到iOS上的实际UINavigationController的支持。动画和行为与原生应用程序用户预期的相一致，因为你使用同样的用户界面控件。
4.入手门槛低。由于Titanium通过JavaScript提供了一种高级的原生编程API，为用过基于ECMAScript的语言的任何人大大降低了原生编程方面的准入门槛。
缺点：
1.Titanium API的范围使得添加新平台有难度。在一种新的原生平台上实现Titanium API是项艰巨任务。正由于如此，Titanium平台只出现在目前被认为最重要的移动平台上：iOS、Android和Web。
2.移动Web浏览器支持还没有达到可以投放市场的质量。Titanium在继续致力于改进我们的用户界面窗口组件集的性能和感觉上，同时完善核心Titanium API的实现。
3.由于Titanium提供的抽象层很庞大Titanium的内部框架仍存在API实现未达到最佳标准的问题。在一些情况下，一些用户界面组件还无法做到性能与原生用户界面组件一样好，比如布局高度定制化的非常庞大的表格视图。优化核心的用户界面组件对Titanium团队来说仍是首要的技术任务。
4.另外由于Titanium平台的宏伟目标，扩展Titanium并非易事。想有效地集成一种新的原生控件或API，深入了解Titanium的架构和环境必不可少。开发者体验、API文档和面向模块开发者的总体指南。
NativeScript
NativeScript是Telerik（做过Kendo UI）推出的，后来转成开源的形式。他们的想法跟Titanium类似，都是想做JS跟Native之间的binding，而他们采用的是反射（reflection）的形式，NativeScript并不是直接用Java的反射去动态查找API，因为性能不哈，他会预先生成一个Metadata在apk里，用于查找和匹配mapping。
优点：
1.用映射的方式达到了极大的扩展性。NativeScript把Android / iOS上的API都映射到NativeScript runtime里，让开发者可以直接以Javascript调用这些native API，类似于V8引擎的原理。
这种做法给NativeScript带来超级强大的扩展性，因为你可以使用“任何”原生app可以使用的api，包括第三方lib，而且不需要做额外的处理；当平台有API变更时，所有的变更也都可以马上被使用（除非反射机制在更新中被破坏了），这个不像Xamarin那样需要等待团队去做更新。从这一点上看，还是有一点优势的。
2.NativeScript在View上也做得不错，UI上也跟现代的Angular / Vue做结合，带来了很高的开发效率。除了原生的组件之外，他还提供了一个CSS subset作为styling使用，这让它在UI开发上比Native app更加方便。NativeScript一开始是使用Angular来做UI，不过后来他们分离出了三种开发方式：基本的js/ts、Angular、Vue（这就是为什么我没打算研究Weex的原因），而且三种方式都可以享受到data-binding的爽感。
3.NativeScript还有一个很大的优点，它把TypeScript当成一等语言（NativeScript本身也是用TypeScript写成的）。不过想想这也是理所当然，毕竟在使用反射机制的情况下，如果没有TypeScript辅助，光是API 反射就会搞死人（没接触过TypeScript的朋友，就试想一下用记事本写Java的感觉吧，哈哈。。。）
缺点：
1.开发者要有一定程度的Native知识。因为NativeScript runtime是基于v8/JavaScriptCore，而不是Webkit，所以你没有办法使用任何的WebAPI（除非有人帮你实现）。举例来说，常见的XmlHttpRequest或fetch是属于Webkit这层的实现，在NativeScript里就需要使用native平台上的实现来做封装，这也加重了开发者对于Native相关知识的依赖。
2.它之所以没有红，主要的原因是出现的时间点有点差。NativeScript刚推出没几个月，还来不及成熟的时候，React Native就夹带着React社群的超人气横空出世了。如果它能够早一点出现，也许现今的版图分布会不太一样了。
网友对 NativeScript 的评价：
如果本身是走Angular阵营的话，NativeScript是一个相当值得尝试的东西。
Election
Electron：PC跨平台。
Electron的前身叫做Atom-Shell，本来是GitHub发布开源编辑器Atom时一并发布的副产物，但是后来这个副产物的影响力远远的超过了Atom editor本身，于是便改名为一个独立专案，也就是现在的Electron。Electron的本质很简单，就是Chromium+Node.js的组合，两者之间透过ipc通讯。
优点：
1.Electron至今已经很成熟了，开发Electron app对js有一定水平的工程师而言就跟喝开水一样简单，前端是一个完整的Web环境，而且还是兼容性高、走在时代前端的Chromium，可以使用各种先进的语法以及WebAPI；而后端是Node.js，而且版本也相当高。
2.Electron也不需要担心跟平台的互动性不足，得利于丰沛的Node.js生态圈，大部分你需要的功能都可以找到模块，而像自动更新跟打包发布这些大多数App都需要的东西， Electron跟他的生态圈也都帮你搞定了。就如同官网的标语，Electron帮你处理了许多琐事，你只要专心在核心功能的开发上就好了。
缺点：
1.臃肿。你必须把完整的Chromium带进去，所以最小的HellowWord压缩起来也要几十mb，不过这其实对桌面软体而言不成问题。
2.消耗内存、以及启动时间问题。因为前端用的是Chromium的关系，Electron在内存消耗上一直为人所诟病，基本上开起来就吃个1xx mb内存是很正常的事，应用复杂度高的话数字也会猛烈攀升。Electron团队应该是无能为力，只能看Chromium未来能不能改善这个问题了。同样的，Electron在启动时间问题上Electron团队应该是无能为力，只能看Chromium未来能不能改善这个问题了，Chromium的启动时间会成为一个瓶颈。
【小结】如果要开发一个桌面为主的跨平台app，那Electron可以说是当仁不让的首选。不论是整体的成熟度、社群的热门程度、可用的资源、旗舰级的showcase，从各方面来看都令人安心。
uni-app(底层使用Vue)
后来朋友推荐使用HBuilder工具（后来升级为HBuilderX），开发很方便，然后我就去HBuilder工具官网搜索了一下，发现了一个叫做uni-app的框架，uni-app是一个使用Vue.js开发所有前端应用的框架，开发者编写一套代码，可发布到iOS，Android，H5，以及各种小程序（微信/支付宝/百度/头条/ QQ /钉钉）等多个平台，简直就是Web极致跨端口的工具（算不上真正意义的跨平台，但是比前面的Cordova感觉要厉害一些，毕竟多吃了纪几年饭，研究出来的东西就是不一样啊。。。O(∩_∩)O哈哈~）。可以说uni-app是懒人必备吧，它使用Vue.js编写你的业务代码。
先来说说它的优点：
1.使用HBuilderX工具开发，一键创建项目模板，快捷方便，HBuilderX和uni-app都是同一家公司推出的，该公司还有其他一些框架，都可以使用HBuilderX创建你要的项目类型以及编写你的代码。
2.uni-app对前端开发人员比较友好，封装的组件和微信小程序的组件一毛一样，熟悉小程序的朋友应该会觉得很不错。
3.uni-app拓展能力强，封装了H5+,支持nvue，也支持原生Android，ios开发。可以将原有的移动应用和H5应用改成uni-app应用。uni-app的App端，内置一个完整小程序引擎，并补充了可选的weex引擎给对性能要求更高的开发者。这也是uni-app在App端能够正常运行微信小程序代码的原因。其他Web跨平台框架做不到这点。
再说说它的缺点：
1.使用Vue开发，你必须要熟悉h5，vue，小程序，学习成本很高。如果不熟悉这些话，需要花时间学习新框架，比如小程序、Vue都要学习。
2.uni-app问世的时间还比较短，移动端平台的兼容性有很多地方还不是完善，坑很多，在Android平台上表现较微信小程序和iOS上差，需要完善。
3.性能还是一个问题。毕竟uni-app底层使用的js，就算能够编译成原生程序，那个性能和兼容性方面也是个问题，如果只是做Web还行，小程序什么的还算出色。
React Native(底层使用React)
小弟算是第一批把React Native用在生产环境上的人（当时是0.0.3版，第一个public版，想想我当时胆子还真大）。
ReactNative没有像NativeScript一样做反射，而是建构了一组RCTBridge，用来做js跟native之间的交互，要使用native API或native 组件的话都要在native层做桥接，然后导入到js里面（类似你写Node的C++ addon的感觉）。
优点：
1.ReactNative能有今天的反响，很大一部分是得利于React生态圈的整体发展优势，以及有Facebook已经在他们的app上做过产品实践，这对很多人而言是一剂强心针，再加上诸如Airbnb，Uber等大型公司也纷纷采用，更造成了推波助澜的效果。
2.打出来的包会比NativeScript的小，架构实现上也比较单纯。因为ReactNative没有像NativeScript一样做反射，而是建构了一组RCTBridge，用来做js跟native之间的交互，所以打出来的包会比NativeScript的小，架构实现上也比较单纯。
3.ReactNative当初出现时打的口号是“learn once, write everywhere”，让不同平台上保有不同的平台特性。这个中心思想所带来的架构设计，让ReactNative可以很轻易的扩展到其他平台上，例如第三方开发者实现的react-native-macos、react-native-appletv（后来被整合进官方里）、微软官方开发的react-native-windows（原名是uwp）、Samsung官方的react-native-tizen，几乎可以说所有平台上都可以看到ReactNative的影子，具体是否成熟有待研究。
缺点：
1.ReactNative目前其实还不算是在一个稳定的状态，他们每两周都会更新一次，这也是开发时要注意的一点。
2.你必须拥有native platform相关的知识。应该说，自从Cordova之后的主流跨平台方案都会要求要具备一定程度的平台原生相关知识。虽然说比起NativeScript，ReactNative在没有任何的原生知识的情况下也是可以编译打包生成一个可用的app，但是这会大大的限缩了你的可扩展性，而且在不了解原生的渲染以及运作方式的情况下，可能会不小心让CPU发烫成了定时炸弹。
3.每个native module都要自己桥接一次，非常麻烦。
Weex(底层使用Vue)
weex资料太少了，我就不做介绍了，反正我是踩过坑的，后来放弃weex了，文档不齐全，API缺少，扩展功能不完善，性能也好不到哪里。。。
Flutter
Flutter是谷歌推出的一个全新的高性能高一致性的跨平台的开发框架。
【优点：】
1.你只需要使用Dart语言写一套代码，即可自动编译到各个平台，目前支持Android,iOS,Web(Beta)，Desktop(Alpha)，当然也有Windows PC和linux平台的兼容支持官方正在研发中。所以你完全不用担心框架内部是如何帮你实现的。你只需要一个命令行就可以在对应平台运行你的代码了，比如：flutter run xxx，这里的xxx指的是你的平台设备名称，比如“flutter run chrome"表示将程序运行在浏览器上面。
2.独立的Skia渲染引擎，高性能高一致性。你的代码编译出来的程序可以达到60bps的高性能。
3.丰富的组件支持，你完全可以按照你的想法去做，扩展性非常强大，MD风格的，以及ios风格的组件都有，足够满足平时开发需求。而且Flutter基于react以及flex的思想进行布局。
4.丰富的社区支持。目前常用的组件以及一些第三方包都有大佬开源出来了，足够应对平时的开发了。如果你不清楚的话，也没关系，我特意收集了Flutter工具集合，这里面啥都有，足够让你可以快速找到你要的东西，你可以点进来看看：https://github.com/AweiLoveAndroid/Flutter-learning/
5.开源免费的。你可以随意修改内核引擎代码，以及组件代码，定制化的开发，比如闲鱼，腾讯，字节跳动等大厂都基于Flutter进行针对他们的App开发做了定制化的整合方案，当然你要是感兴趣的话，你也可以这么做。
6.使用Dart语言进行开发。Dart语法很像JS+Java+Swift+Kotlin+C#+TypeScript+JavaScript+PHP，虽然表面上没有使用web开发，但是你完全不用担心，你仍然可以进行开发，只是语言写法不一样，但是这里面很多都是熟悉的东西，基本上上手成本也是很低的。
【缺点：】
如果不熟悉原生开发，第三方包满足不了你的需求的时候，那么就需要你自己去写或修改已有的插件，这个需要学习一点原生开发的知识（其实这也是很多跨平台技术必不可少的步骤），当然如果你们公司有android或ios的程序员，可以让他们协助写一个插件，这对于他们来说都是小问题。
网友对 Flutter 的评价：
Flutter是Google的亲儿子，目前最火爆的跨平台框架，也是跨平台框架中最接近原生的一种框架，也是效率最高的。目前应用在移动端(安卓端，iOS端)，Web也发布了预览版，但是还无法真正放在小程序或者Web项目中实战。目前来看，Web上面还是无法真正的替代ionic框架。虽然脱离了JS强大的社区,但是这一年多以来Dart语言社区也在逐渐长大，pub.dev上面各种Flutter和Dart的开源库和工具都有，开发项目起来还是不错的，只是Flutter Web发展还不够完善，很多Web的一些包一级浏览器的功能还不完善。
网友对 Flutter 的评价：
我是做前端的，我朋友是移动端的，他走的Flutter路线，他是做安卓开发的，用的java，他说Flutter接近原生体验，非常好。而我们公司需要快速上线，还是走的是WebView的路线，我和他同时做一个小Demo出来对比了一下，发现App的性能体验真的很大，排序如下：原生 >= Flutter > WebView。
最后来提几个问题？
1.跨平台最难的就是各平台之间的差异性这个问题如何解决？
2.Cordova 和 RN, NativeScript 有什么不同呢?
