跨平台开发解决方案浅谈

跨平台开发解决方案浅谈 前言 本文所讨论技术都是基于大前端生态下的本文所指跨平台概念无特殊说明时泛指跨安卓和ios用前端工程化技术开发出app也是本文所讲重点

作为用户来说，当然希望使用App的时候能够顺畅流利，不可否认的是，使用iOS和Android开发出来的应用非常流畅而且高效，但是缺点就是需要耗费较长的时间来开发，比如同一个App，需要在Android和iOS两端各自开发一遍，确实比较耗费人力和财力。所以人们希望选择使用跨平台应用来解决这一问题。

一、什么是跨平台应用开发框架？

开发人员可以使用一套相同的代码，一次性地编码即可在多个平台上面运行起来。它减少了开发人员开发应用的时间，并且能够快速地交付。所以目前为止，越来越多的人意识到跨平台应用程序和框架的好处和重要性。

跨平台应用程序开发框架的好处：

一个App适用于多个设备；一个App适用于多个平台；一个App可以在多个应用商店中发布；只需编写一次代码；代码可以跨平台复用；市场分析与测试；快速成型；快速开发；无缝产品维护；统一性、均匀性； 二、Flutter

Flutter由Google开发，它是一个牛逼的开源平台，可用于跨平台应用程序开发。它具有吸引力的原因是：快速的开发，富有表现力的精美UI和类似本机的性能。

使用Flutter的一些公司是Google，eBay，宝马等。

选择Flutter框架进行跨平台应用程序开发的主要原因：

高度稳定DART，AOT编译语言平稳的开发周期强大的热加载功能满足各种需求的UI套件完美匹配的Flutter现在拥有200万用户，并且还在不断增加。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7kCPWNWm-1635665231905)(https://segmentfault.com/img/remote/1460000040175731)]

Flutter 是最新的跨平台应用程序框架之一，由 Google 开发并于 2017 年发布。Flutter是一个免费的开源跨平台框架，它允许你用一组代码创建一个移动应用程序。它的独特之处在于它使用Dart编程语言，不同于其他跨平台应用框架，Flutter根本不使用JavaScript。

你可以改变你的代码并实时看到结果，只需片刻就可以升级应用程序。您可以使用Flutter为iOS、Android和其他不太流行的移动平台创建跨平台的移动应用程序。平心而论，就目前而言，这是为 Fuchsia OS 开发应用程序的唯一途径。

优点：

Flutter 自带图形引擎，这意味着无需为 iOS 和 Android 分别制作界面。Dart 使您能够编写额外的结构化程序代码，从而允许您创建更多层次结构和复杂功能。基于 Flutter 的移动应用程序快速高效。与其他跨平台应用程序框架相比，Flutter 提供了更显着的性能提升。

开发工具：

EmacsVS CodeAndroid Studio 三、React Native

由Facebook在2015年开发的React Native可帮助企业使用Swift，Objective C和Java等语言构建类似于本机的应用程序。

使用React Native框架的一些企业是Facebook，Skype，Tesla等。

选择React本机框架进行跨平台应用程序开发的主要原因：

现成的组件社区驱动热加载开源React Native for Web功能高度可靠本地功能易于访问本机UI组件的实现

在过去的几年中，大多数公司都信任React Native满足混合应用程序的需求。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ONVOeSCG-1635665231922)(https://segmentfault.com/img/remote/1460000040175733)]

React Native 是另一个流行的跨平台应用程序开发框架。它与 iOS 和 Android 兼容。 React Native 于 2015 年初由 Facebook 开发，并由其自己的社区不断改进。它是用 React 构建的，不使用 WebView 或 HTML 技术。它不是 HTML，而是 JSX 中的平台组件，而不是 CSS，它有类似 CSS 的 polyfill。此外，也没有 DOM API。 React Native 由 JavaScript 和 React.JS 的组合组成。此外，它允许开发H人员使用 Swift、Java 或 Objective-C 开发某些部分。

优点：

React Native 专注于用户界面，使应用程序开发人员能够构建高度可靠的界面。允许为各种平台创建应用程序，例如 iOS、macOS、tvOS、Web、Windows、Android、Android TV 和 UWP。

开发工具

JS编辑器SDK, Android Studio, Emulator 三、uinapp

uni-app 是一个使用 Vue.js 开发跨平台应用的前端框架。
开发者通过编写 Vue.js 代码，uni-app 将其编译到iOS、Android、微信小程序等多个平台，保证其正确运行并达到优秀体验。

uni-app 继承自 Vue.js，提供了完整的 Vue.js 开发体验。

uni-app 组件规范和扩展api与微信小程序基本相同。

有一定 Vue.js 和微信小程序开发经验的开发者可快速上手 uni-app ，开发出兼容多端的应用。

uni-app提供了条件编译优化，可以优雅的为某平台写个性化代码、调用专有能力而不影响其他平台。

uni-app打包到App时仍然使用了5+引擎，5+的所有能力都可以在uni-app中可以使用。在App端运行性能和微信小程序基本相同。

对于技术人员而言：不用学那么多的平台开发技术、研究那么多前端框架，学会基于vue的uni-app就够了。
对于公司而言：更低成本，覆盖更多用户，uni-app是高效利器。

四、weex

2016 年 4 月 21 日，阿里巴巴在 Qcon 大会上发布跨平台移动开发工具 Weex，同年 12 月 15 日，阿里巴巴宣布将移动开源项目 Weex 捐赠给 Apache 基金会开始孵化。Weex 致力于使开发者能基于当代先进的 Web 开发技术，使用同一套代码来构建 Android、iOS 和 Web 应用。具体来讲，在集成了 WeexSDK 之后，你可以使用 JavaScript 和流行的前端框架（如 Vue.js 和 Rax）来开发移动应用。

Weex 的另一个主要目标是跟进当代先进的 Web 开发和原生开发的技术，使生产力和性能共存。在开发 Weex 页面就像开发普通网页一样；在渲染 Weex 页面时和渲染原生页面一样。我们可以发现，Weex 在很大程度上借鉴了 React Native 的思想和方式，目标都是通过 JS 语法渲染 Native 页面，但由于起步比较晚，社区没有 React Native 活跃，资料和开源项目也相对较少。

Weex 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验，来构建 Android、iOS 和 Web 应用。简单来说，在集成了 WeexSDK 之后，你可以使用 JavaScript 语言和前端开发经验来开发移动应用。

Weex 渲染引擎与 DSL 语法层是分开的，Weex 并不强依赖任何特定的前端框架。目前 Vue.js 和 Rax 这两个前端框架被广泛应用于 Weex 页面开发，同时 Weex 也对这两个前端框架提供了最完善的支持。Weex 的另一个主要目标是跟进流行的 Web 开发技术并将其和原生开发的技术结合，实现开发效率和运行性能的高度统一。在开发阶段，一个 Weex 页面就像开发普通网页一样；在运行时，Weex 页面又充分利用了各种 *** 作系统的原生组件和能力。

五、总结

每当我们评估新技术时要问的第一个问题就是“它会给我们的业务和客户带来哪些价值？”，工程师们很容易对闪闪发光的新事物着迷，却经常会忽略这些新事物其实可能对我们的客户没有任何好处，反而只会让现有的工作流程更加复杂。

flutter最近比较热闹，毕竟是Google出品。

但我们不是炒作热点的媒体，也不是忽悠你交学费的培训机构，我们作为实际的跨平台开发者，冷静的分析下这个东东。

flutter是Google为Fuchsia *** 作系统设计的应用开发方式。

Fuchsia OS要兼容廉价物联网设备，要求对硬件的消耗降低，并且为了避免与oracle的java打官司，Fuchsia 使用了dart语言+flutter界面库的方式。

从设计上来看，这套方案的性能确实够高。dart虽然属于大前端范畴，但dart是和java一样的强类型语言，这让dart虚拟机可以做很多优化，性能方面超出了js。

dart曾经与typescript竞争，谁才是更好的js？但不幸输给了typescript，chrome也放弃了内置dart虚拟机的计划。

不过dart团队没有解散，几年后，他们借助flutter，再次出现在公众面前。

5.1、性能分析和写法的对比

cordova uni-app这些都是html5+阵营的，基本运营逻辑是app里放一个浏览器，然后为浏览器扩充一些功能函数来调用底层api。

另一个阵营是跨平台编译阵营的，包括weex、react、flutter，其中面向类型最广的是react。据说阿里的许多app都是weex写的，好像淘宝手机版也是。

flutter作为界面库（注意它只是界面库，dart语言是另一个项目），它唯一要干的事情就是渲染界面。不像HTML5，flutter界面库连视频、定位等都没有，就是一个纯排版引擎，绘制文字、按钮、图片等常用界面控件。

这个排版引擎的特点是简单、高性能。

在3大主流渲染引擎里，webview、react native/weex、flutter，复杂度依次降低，渲染性能依次上升。（uni-app是双渲染引擎，webview和weex都内置了，随便开发者使用切换）

所以我们要清楚，提升性能是有代价的，你究竟想要灵活丰富的css3，还是想要固定flex模式排版，抑或是最简单但高性能的flutter排版？开发便利性和运行性能不可兼得。

同时我们要明白，性能的差别，并不是因为Google的chrome团队、Android团队的技术比同公司的flutter团队差。而是flutter提供的布局写法是被限制过的，解析快，所以渲染快。别忘了webview的排版引擎也是世界级工程师用c写的。

但通过这种方式提升性能的代价，就是布局复杂的界面时，flutter的代码嵌套的让人崩溃。

浏览器的html提供了tag和样式分离的写法，还有各种各样的选择器，但其实这也是有代价的。它导致webview初始化时要同时先启动webkit排版引擎来解析这些编写随性的html、css，同时还要启动一个js引擎比如v8或jscore来解析里面的js。

flutter的性能高，除了简单严格，还有一个特点，就是逻辑层与视图层统一，运行在同一套dart虚拟机下。

我们知道rn和weex，也是原生渲染的，它们的性能高于webview。但同为原生渲染的，怎么会慢于flutter呢？其实不是原生渲染慢，而是js和原生通信慢。

rn和weex都采用了独立的js引擎（iOS是jscore，Android是v8，最新版rn开始在Android上搞自己的js引擎Hermes），从js与dart的比较上，性能稍逊一筹。但这不是主要问题，因为v8的jit不是盖的，也是编译为原生代码解析的。性能上的主要问题是：rn、weex的js引擎和原生渲染层是两个运行环境。

当JS引擎联网获取到数据后，通知原生视图层更新界面时，有一个跨环境的通信折损。同样，当用户在屏幕上 *** 作原生视图层时，要给JS引擎发送通知，也会产生这个通信折损。

不过这种性能差别，在大多数场景中，用户是感受不到的。比较影响的场景，是跟手式的JS响应 *** 作绘制帧动画。

这方面，Weex有个值得称赞的技术是 BindingX ，它可以预定义规则，让用户界面在原生层交互时通过预定义规则直接响应，而无需传递给JS层。在需要短时间内来回通信的场景时，可以使用BindingX这类解决方案。它的性能和灵活性比RN更强了一些。

说回来Flutter，它只有一个Dart引擎，没有来回通信产生的性能问题。不过任何事情都是有利有弊的， Flutter在普通的界面绘制上效率虽然高，但一旦涉及原生的界面，反而会遇到更多问题。

前面已经说过，Flutter只是一个基础排版引擎，缺少很多能力，当我们需要在Flutter界面上内嵌一个原生的视频播放扩展控件时（Flutter没有视频播放能力），或者原生的高德地图SDK，那么在拖动视频进度时、拖动地图时，Flutter一样会产生原生和Dart之间的通信，造成性能损耗。

事实上，由于Flutter是在一个类Canvas环境绘制的，想把一个原生控件嵌入Flutter的布局里某些元素之间去排版，还不是一件容易做到的事情，坑很多。

每个人都想要一个像CSS3那样灵活写法的布局引擎，他们给React Native和Weex提需求，给Flutter提需求。殊不知，让这些产品团队实现了CSS3时，他们的性能优势已经不再了，他们相当于又实现了一遍Webview。这种无意义的需求，他们是不会受理了。

性能好，有个度，客观地讲，rn/weex调用原生渲染的性能，和flutter的渲染性能，在用户体验上并没有明显区别，甚至在很多场景下，和webview渲染的小程序也没有明显区别。

也简单说说webview渲染小程序，为什么性能高，核心是预载。点击一个新页面时，webview是提前创建好的，不会走复杂的webkit、v8的初始化流程，连开发者的js代码，也是预载好的。所以点击新页面时，它的渲染速度和原生应用没什么差别。当然也有个坏处，就是启动慢。微信里启动小程序速度看着还行，其实是微信在启动小程序之前，就已经提前初始化了小程序运行环境。

5.2、技术学习成本和难度

rn，要求开发者学习react，要求精通flex布局，要求原生开发协作。

flutter，要求开发者学习dart，了解dart和flutter的API、要求精通flex布局，要求原生开发协作。

weex已经内嵌到uni-app中，就不单独提了。

uni-app，要求开发者学习vue，了解小程序。

另外，dart究竟值不值得学，是一个大问题。

Google的天才工程师也发明了go语言，它确实有很多理论优势，但实际上市场的主流，仍然是c和c++。

5.3、生态

任何开发引擎，都离不开生态。

对于国外的开发者，rn、flutter的生态肯定比uni-app好，比如facebook登陆分享、Google地图等。

但对于国内的开发者，那是反过来的，中国开发者需要的全端推送（UniPush集成了iOS、华为、小米、OPPO等众多原厂推送）、各种国内登陆、支付、分享SDK、各种国内地图、各种ui库、以及Echart图表等，都是在uni-app体系里，这方面生态可比rn、flutter丰富多了。uni-app的插件市场有数千款插件，不能说应有尽有，但确实是最丰富的跨端开发框架生态了。

5.4、综合比较

比较内容	cordova/ionic	react-native/weex	flutter	native
语言	JS	RN：React/Weex：Vue	Dart	Android：Java/Kotlin/iOS：OC/Swift
平台实现	JS 引擎解释执行JS代码	JS 引擎解释执行JS代码	开发版本：Dart 虚拟机解释执行 发布版本：Dart 代码编译成目标机器码	Android：安装时编译成目标机器码/iOS：构建时编译成目标机器码
绘制	1、Html+css 2、浏览器引擎绘制	1、JS 生成 DOM 树 2、Native 端解析 DOM 树，转换成原生 View 显示	1、使用 Dart 实现 UI 组件 2、Skia Engine 渲染	原生 View
控件效果	1、样式一致 2、交互效果和原生控件有差距	1、不同平台样式不一致 2、本身就是原生控件	1、样式一致 2、交互效果和原生控件很接近	/
流畅度	一般	较好	和原生相同	好
动画	差	一般	和原生相同	好
比较内容	cordova/ionic	react-native/weex	flutter	native
跨平台支持	Android、iOS、Web	RN：Android、iOS/Weex：Android、iOS、Web	Android、iOS（2019.5 发布 Web 端预览版，bug 多，性能差）	/
动态更新	支持	支持	不支持	不支持
页面开发	整体 APP、模块、单页面	RN：整体 APP、模块、单页面/Weex：单页面	整体 APP、模块、单页面	/
社区支持	丰富	第三方库多，但质量良莠不齐	第三方库较少	丰富
原生UI组件	不能桥接	可以桥接	可以桥接（性能差）	/
安装包大小增加	1MB	8MB/10MB	10MB	/

六、结论

每种技术的诞生，有其背后公司的目的。

但凡没有明确公司战略的技术，除非是特别简单的技术，否则很难商用，因为为了商用要投入公司非常多资源。

flutter诞生的目的，是为了Fuchsia OS，是为了在下一个互联网大潮，即万物互联的物联网年代，提供一个类似Android在移动互联网位置的垄断性 *** 作系统。

因为Google已经很明确不会在下一个时代使用Android+java的路线了。

至于在Android上去java化，那是Kotlin的使命，与flutter无关。

跨iOS和Android平台开发，这不是Google的战略目标。

但万物互联何时到来？Fuchsia OS何时流行？这在现实中是一个问号，在Google内部，也只是战略储备项目。

一个语言的流行，不是一件简单的事情，不是有优点，就会流行，它需要天时地利人和。

6年前我们就知道dart比js更好，dart不应该消亡，但想成为主流技术，太难太难了。

同样我们也知道go比c++更好，但go还是起不来。

想靠flutter驱动dart流行是不现实的，甚至是反过来的。跨iOS、Android开发在国外不是主流市场，这点价值造就不出一个这么难建的生态。

所以dart能否流行，是要打一个大大的问号的，它可能会像go语言一样，叫好不叫座。

一个跨平台公司，应当是中立的。而flutter在这个位置上很尴尬，它是google出品的、同时跨iOS和Android的开发引擎。

如果这个引擎做大了，Apple会怎么看？那可不是像微信搞个小程序那么简单了，微信是中立三方，且只在中国。Apple不会让google的flutter在iOS上做大的。大家也都知道，即便是chrome，在iOS上也只能使用iOS提供的内核，容不得google在iOS上乱搞的。

目前，flutter在国内一些大厂的原生App里得到了局部应用。这个应用场景，目的不是为了节省成本，flutter开发成本很高，生态也不完善，但因为性能高，一些大公司愿意负担这个代价来使用flutter，在原生app里部分页面使用flutter制作。但是这个场景，有个尴尬，就是flutter页面无法动态更新，但很多大app对动态发版的需求极强，有些厂商改造了flutter使其可动态发布，但又降低了flutter的性能。目前还没有一个完美的解决方案。

当然，还有许多基于大前端生态的框架和不是基于前端生态没有被列举出来，相信随着互联网浪潮的不断向前，越来越多的解决方案、框架会被提出，在不断探索的道路上，我们都可以成为某个方位角的引路人！

我是攻城狮深巷，欢迎关注我的博客:Deep Lane’s Blog和Github:shenxiang216，一起学习更多技术！