共计 2371 个字符，预计需要花费 6 分钟才能阅读完成。
始终以来，跨平台工具采纳以下两种办法之一：
在原生应用程序中嵌入 web view，像构建网站一样构建应用程序。
封装原生平台里的控件并为它们提供一些跨平台的参数。
Flutter 有什么特别之处
为了使挪动端开发变得更好，Flutter 尝试了一种不同的办法。它提供了开发人员工作的框架应用程序和可能托管应用程序的可移植运行时的引擎。该框架依靠 Skia 图形库而构建，提供了理论渲染时用到的 widgets，而不仅仅是原生利用控件的包装器。就像 web 包装器选项提供的那样，该办法能够灵便的以齐全自定义的形式构建跨平台应用程序，同时还会提供晦涩的性能体验。与此同时，Flutter 自带的丰盛的 widget 库以及一些开源的 widgets 使其成为一个功能丰富的平台。
目前曾经有不少大型项目接入 Flutter，阿里的闲鱼、头条的抖音、腾讯的 NOW 直播，都将 Flutter 当做应用程序的开发语言。除此之外，还有一些其余中小型公司也在做。
Flutter 的三个局部
由 Dart 语言负责的 Framework 层；
Dart 语法执行器；
Skia 图像处理引擎。
Flutter 也能够了解为开发 SDK 或者工具包，其通过 Dart 作为开发语言，并且提供 Material 和 Cupertino 两套视觉控件，视图或其余和视图相干的类，都以 Widget 的模式体现。Flutter 有本人的渲染引擎，并不依赖原生平台的渲染。Flutter 还蕴含一个用 C ++ 实现的 Engine，渲染也是蕴含在其中的。
Flutter 的跨端劣势
1、如果当前想在 Google 的新零碎上跑程序的话，用 Flutter 来编写是肯定没错的。
2、Flutter 用 Dart，学习 Flutter 的同时会使咱们把握一门新的语言，买一送一。
3、Flutter 天生反对 iOS 格调的控件，称为 Cupertino，这样咱们能够一套设计，一套 code 跑在两个零碎上。
4、学习 Flutter 的过程会扭转手机端 app 开发的思维，毕竟只有一个 activity，全程跟个游戏引擎一样，60 帧每秒绘图。
5、Hot reload，极大地减速了开发效率。
6、Flutter 提供 method channel 给 Android 和 iOS，其实能够只用 Flutter 来开发 UI，其余底层逻辑能够封装 Android 和 iOS 别离的 lib package，而后间接 Rx 封装写回 method channel，也是一种新的开发模式。
7、性能更好，兼容性更好，开发起来更有乐趣，这才是程序员的人生，正好 Flutter 都能满足。
跨平台计划的比拟
NATIVE
原生应用程序在应用新性能时带来的困扰是起码的。因为应用程序是应用平台供应商本人（Apple 或 Google）的控件构建，为了让用户体验更加合乎给定的平台，因而他们通常遵循这些供应商制订的设计指南。大多数状况下，原生的利用将会比那些跨平台构建的利用性能要好一些，只管在很多状况下两者的差别能够忽略不计，不过具体还要取决于底层跨平台技术。原生利用的一大劣势是：当须要时，他们能够立刻采纳 Apple 和 Google 在测试版中开发的新技术而不必期待第三方的集成。构建原生利用的次要毛病是不足跨平台的代码复用，如果同时开发 iOS 和 Android 利用，那么开发成本可能会很高。
REACT NATIVE
React Native 容许原生利用应用 JavaScript 构建。利用中用到的控件实际上都是原生平台里的控件，所以用户应用起来感觉和原生利用一样。对于那些 React Native 没有提供的须要自定义的利用，依然须要应用原生开发。当须要定制的模块比拟多时，某些状况下，在 React Native 中开发不如应用原生开发更适合。
XAMARIN
当谈到 Xamarin 时，有两种不同的办法将会被提及。跨平台办法：Xamarin.Forms。该办法不同于 React Native，然而从概念上讲是类似的，因为它也是形象原生控件。同样的，在定制方面它也有和 React Native 同样的毛病。第二种办法：Xamarin-classic。该办法离开应用 Xamarin 的 iOS 和 Android 产品来构建实用于特定平台的性能，就像间接应用 Apple/Android 原生性能一样，只不过在 Xamarin 中须要应用 C# 或 F#。应用 Xamarin 的益处是能够共享非平台特定的代码，例如网络、数据拜访、Web 服务等。
NATIVE+ 小程序
说起这个可能首先会想到「原生 + HTML5」，至多一些业务性能通过 H5 的模式实现，能够节俭安装包的体积，也能够实现疾速更新。但会发现 HTML5 开发的形式，性能体验问题较大。比方，HTML5 页面在用户手机上经常出现打不开、始终加载中、卡顿，而且 H5 很多零碎权限获取不了，也不反对本地缓存，须要拜访通讯录、调用硬件、拜访蓝牙啥的这些 H5 都是无奈反对的，导致还是有大量的性能不得不放到客户端上实现。
因为国内的非凡的起因，在微信、支付宝的带动下小程序成为挪动端的时代搅局者，小程序具备弱小的 Web 渲染引擎、提供丰盛组件、反对本地缓存、防止 DOM 泄露等等这些都是，而且小程序技术也有利于帮忙 App 实现「涣散耦合」，比方当 App 的一些业务性能用小程序的模式代替，那么这个小程序可由团队或者集体独立开发、独立部署、独立治理生命周期，随时高低架而不影响 APP 主体，实现 APP 简单业务动态化，多维公布。
目前也有国内厂商推出了成熟的解决方案，之前有理解到 FinClip，这个框架对标微信小程序的性能，雷同的代码，既能在微信端跑，也能在本人的 App 里跑，成果是一样的，相当于把曾经上架的微信小程序可能间接搬到本人的 App 能运行。开发一次就可能在包含 Linux、Windows、MacOS、麒麟等操作系统运行。这意味着，PC 端、车载设施、智能电视都能应用小程序了，实现了“一次开发，到处运行”。
