关于flutter:flutter-rn-uniapp-对比

92次阅读

共计 4346 个字符,预计需要花费 11 分钟才能阅读完成。

flutter

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

Fuchsia OS 要兼容便宜物联网设施,要求对硬件的耗费升高,并且为了防止与 oracle 的 java 打官司,Fuchsia 应用了 dart 语言 +flutter 界面库的形式。

比照剖析

性能剖析 和 写法比照

flutter 作为 界面库 ,它惟一要干的事件就是渲染界面。不像 HTML5,flutter 界面库连视频、定位等都没有,就是一个 纯排版引擎 ,绘制文字、按钮、图片等罕用界面控件。
这个排版引擎的特点是 简略、高性能

晋升性能是有代价的,开发便利性和运行性能不可兼得。

举个例子,同样的界面,用 HTML 和 flutter 如何实现:

<div class="greybox">  
  <div class=redbox>  
    smaple text  
  </div>  
</div>  

.greybox {  
  display: flex;  
  align-items: center;  
  justify-content: center;  
  background-color: #e0e0e0; /* grey 300 */  
  width: 320px;  
  height: 240px;  
  font: 18px  
}  
.redbox {  
  background-color: #ef5350; /* red 400 */  
  padding: 16px;  
  color: #ffffff  
}
var container = new Container( // grey box  
  child: new Center(  
    child: new Container( // red box  
      child: new Text(  
        "smaple text",  
        style: new TextStyle(  
          color: Colors.white,  
          fontSize: 18.0,  
        ),  
      ),  
      decoration: new BoxDecoration(color: Colors.red[400],  
      ),  
      padding: new EdgeInsets.all(16.0),  
    ),  
  ),  
  width: 320.0,  
  height: 240.0,  
  color: Colors.grey[300],  
);

能够看出,从代码的写法来说,flutter 没有 tag 和款式的说法,更没有选择器,从头到尾只有 dart 语言,它的界面控件是用 dart 代码 new 进去的,每个控件的款式,是在 new 的时候设置的类 json 写法的参数。

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 响应操作绘制帧动画,或者说 js 间断操作界面元素方面,flutter 折损更少。

这个通信折损,其实普遍存在于所有逻辑和视图拆散的框架中,包含各家小程序也有这个问题。

说回来flutter,它只有一个 dart 引擎,没有来回通信产生的性能问题。不过任何事件都是有利有弊的,flutter 在一般的界面绘制上效率尽管高,但一旦波及原生的界面,反而会遇到更多问题。

后面曾经说过,flutter 只是一个根底排版引擎,短少很多能力,当咱们须要在 flutter 界面上内嵌一个原生的视频播放扩大控件时(flutter 没有内置视频播放能力),或者原生的高德地图 sdk,那么在拖动视频进度时、拖动地图时,flutter 一样会产生原生和 dart 之间的通信,造成性能损耗。

事实上,因为 flutter 是在一个类 canvas 环境绘制的,想把一个原生控件嵌入 flutter 的布局里某些元素之间去排版,还不是一件容易做到的事件,坑很多。

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

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

ui 库

不论是 rn 还是 flutter,有一个设计,很不中国化。它们在 iOS 和 Android 平台上,应用 2 套 ui 库。

rn 和 flutter 这种“跨平台”排版引擎,其跨平台性,对于中国开发者而言,又打了折扣。

其实相似小程序那样的 ui 格调,是可能良好的跨 iOS 和 Android 的体验的,不论用什么手机,关上小程序都不会感觉有问题。

uni-app 默认也是这种通用 ui 格调。uni-app 的开发者只须要写一套界面 ui,就能够适应不同手机的用户,真正的 write once,run anywhere。

动态性

webview、rn/weex,都有一个特点,能够近程动静载入 js 代码,能够更新本地的 js 代码。前端开发者认为动态性是理所当然的,但其实 flutter 并不反对。

flutter 是有编译优化概念的,如果它提供动态性反对,会影响它的性能。

除了 flutter,rn/weex/uni-app 都能够动静热更新。

跨平台排版引擎 和 跨平台利用开发引擎 的区别

一个页面跨平台,和一个利用跨平台,是齐全不同的 2 个概念。

webview、rn/weex、flutter 全副是渲染引擎,webview 因为 HTML5 的倒退,还算是多了一些能力比方位置服务、多媒体等。而 rn/weex、flutter 真的只是一个纯正的排版引擎,没有任何原生能力。

什么是跨平台 利用开发 引擎?岂但 排版 局部要跨平台,开发 API也要跨平台。

利用开发离不开 os 或三方 sdk 的能力调用,如果是单纯的排版引擎,一旦波及 os 能力和 sdk 调用,就必须 iOS、Android 的工程师配合,编写不同的原生代码整合在一起。这就不跨平台了。

uni-app,它的设计指标不是跨平台排版引擎,而是跨平台利用开发引擎。

所以 uni-app 的排版局部,能够抉择小程序强化 webview 引擎和 weex 引擎,可依据本人的需要切换。而能力层面,uni-app 提供了 htmlplus API、Native.js、插件市场,解决了原生能力 js 化的问题。

uni-app 让开发者真的不必懂原生开发就能做出残缺的跨平台利用。遇到极个别的需要,开发者也能够去插件市场找人订做一个原生插件,本人依然应用 js 来集成,依然能够云端间接打包。

学习老本、难度

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

flutter,要求开发者学习 dart,理解 dart 和 flutter 的 API、要求精通 flex 布局,要求原生开发合作。

weex 曾经内嵌到 uni-app 中,就不独自提了。

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

生态

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

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

但对于国内的开发者,那是反过来的,中国开发者须要的全端推送(UniPush 集成了 iOS、华为、小米、OPPO 等泛滥原厂推送)、各种国内登陆、领取、分享 SDK、各种国内地图、各种 ui 库、以及 Echart 图表等,都是在 uni-app 体系里,这方面生态可比 rn、flutter 丰盛多了。uni-app 的插件市场有数千款插件,不能说包罗万象,但的确是最丰盛的跨端开发框架生态了。

另外,uni-app 的生态还比其余竞品强在如下方面:

  • App 和 H5 提供了 renderjs 技术,使得浏览器专用的库也能够在 App 和 H5 里应用,比方 echart、threejs 等
  • 兼容微信小程序 JS SDK,丰盛的小程序生态内容可间接引入 uni-app,并且在 App 侧通用
  • 兼容微信小程序自定义组件,并且 App、H5 侧通用

总结

flutter 与 uni-app 的比拟:

flutter 与 uni-app 的绝对劣势:
  • 性能好一丢丢。比 rn 有劣势,但比领有 bindingx 和 wxs 的 weex/uni-app,在理论开发中没有很显著的差距。
flutter 与 uni-app 的绝对劣势:
  • 须要原生合作,保护 3 套代码,无奈无效升高开发成本,晋升开发效率
  • 嵌套天堂,代码难看难保护
  • 不反对热更新
  • 目前品质和成熟度很低
  • 原生可视控件交融不好,比方 webview、video、map
  • ui 库不适宜国情
  • 学习老本高
  • 利用场景无限,dart 将来错综复杂

uni-app 里其实也能够应用 flutter,有插件作者提供了插件,使得 uni-app 的利用在某些页面能够关上 flutter 页面

rn 和 uni-app 的比拟

rn 与 uni-app 的绝对劣势:
  • rn 的坑尽管比 weex 的少,但 uni-app 曾经填了 weex 的很多坑。这方面差异不大。
  • rn 的生态尽管比 weex 丰盛。但 uni-app 是反过来的,uni-app 的国内利用生态丰盛度超过了 rn。
  • rn 是纯单页的,嵌入原生 App 比拟灵便。而 uni-app 是利用整体的概念,如果要内嵌入其余原生利用的话,要求原生利用内嵌 uni-app 利用整体进来。即集成 uni 小程序 sdk。
rn 与 uni-app 的绝对劣势:
  • 须要原生合作,保护 3 套代码,无奈无效升高开发成本,晋升开发效率
  • 不反对小程序,公布到 h5 也无奈间接发
  • 性能不如 uni-app
  • 国内的插件生态不如 uni-app 丰盛
  • ui 库不适宜国情,learn once,write anywhere
  • 学习老本高,用人老本高,不利于开发商升高开发成本
  • rn 是纯单页利用,如果一个利用的页面很多,用 rn 写会很解体,变量净化和烦扰重大。而 weex/uni-app 反对多页面,页面之间上下文隔离,写页面较多的大型利用更适合
  • 另外 react 在中国的市场占有率远不如 vue。这也是中国与国外不同的特色状况。

原文地址:https://ask.dcloud.net.cn/art…

正文完
 0