Flutte3.0 遥遥领先|一文教你完全掌握跨平台方案React还是flutter

最新推荐文章于 2024-06-28 17:48:37 发布

datian1234

最新推荐文章于 2024-06-28 17:48:37 发布

阅读量1.1k

点赞数 21

文章标签： react.js flutter android

本文链接：https://blog.csdn.net/datian1234/article/details/136030198

版权

1. Flutter的现状

18,19年刚开始, 2020年和2021年达到了巅峰, 后面22和23开始下降! 很多公司都是为了kpi, 大公司都不用!
咸鱼, 快手都从最初的阵营, 又改回原生了!
1). 为什么呢?
flutter 的特点,1).成本, 但是大厂根本不缺钱
2). 性能, 大厂都追求极致的体验, flutter在和原生交互的时候还是很多问题, 不如原生稳定!
那为什么要学呢?
但是Flutter是跨平台里面最好的了,
3).问题: flutter会取代原生吗?
肯定不会,现在车载, 音视频, 手机都是原生, flutter一般用于金融和电商!
原生会下降趋势, flutter会增长!

2. Flutter和compose区别和比较

总结下就是：

Compose 是 Android UI 的未来，现阶段你可以不会，但是如果未来你会继续在 Android 平台的话，你就必须会。
Flutter 的未来在于多平台，更稳定可靠的多平台 UI 框架。如果你的路线方向不是大前端或者多端开发者，那你不需要会。

从未来的角度看：

如果你是原生开发，还没接触过 Flutter ，那先去学 Compose ，这对你的 Android 生涯更有帮助，然后再学 Flutter 也不难。
如果你已经在使用或者学习 Flutter ，那么请继续深造，不必因为担心 Compose 而停滞不前，当你掌握了 Flutter 后其实离 Compose 也不远了。

3.Flutter产生的原因

跨平台的特点和诞生的原因: 原生开发的2个缺点

动态化内容需求增大；当需求发生变化时，纯原生应用需要通过版本升级来更新内容，但应用上架、审核是需要周期的，这对高速变化的互联网时代来说是很难接受的，所以，对应用动态化(不发版也可以更新应用内容)的需求就变的迫在眉睫。
“一套代码，多端运行”口号的跨平台开发方案，如雨后春笋般涌现，React Native就是其中的典型代表。
用户体验，版本控制也很难做到统一, ios和android开发技术水平和平台都不一样, 做出来的效果可能不一样!

总结一下，纯原生开发主要面临动态化和开发成本两个问题!

Flutter优点:

渲染性能:

1).Flutter采用GPU渲染技术，所以性能极高。120fps超高性能

它开辟了全新的思路，提供了一整套从底层渲染逻辑到上层开发语言的完整解决方案：视图渲染完全闭环在其框架内部，不依赖于底层操作系统提供的任何组件，从根本上保证了视图渲染在Android和iOS上的高度一致性；Flutter的开发语言Dart，是Google专门为（大）前端开发量身打造的专属语言，借助于先进的工具链和编译器，成为了少数同时支持JIT和AOT的语言之一，开发期调试效率高，发布期运行速度快、执行性能好，在代码执行效率上可以媲美原生App。而这与React Native所用的只能解释执行的JavaScript，又拉开了性能差距。

Flutter编写的应用是可以达到120fps(每秒传输帧数),这也就是说，它完全可以胜任游戏的制作。而我们常说的RN的性能只能达到60fps，这也算是Flutter的一个超高竞争力吧。官方宣称Flutter甚至会超过原生性能。

2). 高效, Hot Reload (热重载)

3). Dart语言:

4). 美观, 使用Flutter内置美丽的Material Design和Cupertinowidge`

4.跨平台开发方案的三个时代

跨平台的发展史:

uni-app: 低端的跨平台方案, 主要是用于小程序和网页,要求不高的!

QT:

Qt是一款由挪威Trolltech公司（现在是The Qt Company）开发的C++图形用户界面开发框架。它具有跨平台特性，支持在不同操作系统上编写一次代码，然后在多个平台上运行。Qt提供了丰富的工具和类库，用于开发图形界面、网络应用、嵌入式系统等多种应用。

Qt [1]是一个1991年由Qt Company开发的跨平台C++图形用户界面应用程序开发框架

根据实现方式的不同，业内常见的观点是将主流的跨平台方案划分为三个时代。

Web容器时代：基于Web相关技术通过浏览器组件来实现界面及功能，典型的框架包括Cordova(PhoneGap)、Ionic和微信小程序。
泛Web容器时代：采用类Web标准进行开发，但在运行时把绘制和渲染交由原生系统接管的技术，代表框架有React Native、Weex和快应用，广义的还包括天猫的Virtual View等。
自绘引擎时代：自带渲染引擎，客户端仅提供一块画布即可获得从业务逻辑到功能呈现的多端高度一致的渲染体验。Flutter，是为数不多的代表。

4.1Web容器时代 (webview+js桥接)

最成功的跨平台开发方案其实是依托于浏览器控件的Web。

Web时代的方案，主要采用的是原生应用内嵌浏览器控件WebView（iOS为UIWebView或WKWebView，Android为WebView）的方式进行HTML5页面渲染，

并定义HTML5与原生代码交互协议，将部分原生系统能力暴露给HTML5，从而扩展HTML5的边界。这类交互协议，就是我们通常说的JS Bridge（桥）。

这种开发模式既有原生应用代码又有Web应用代码，因此又被称为Hybrid开发模式。由于HTML5代码只需要开发一次，就能同时在多个系统运行，因此大大降低了开发成本。

由于采用了Web开发技术，社区和资源非常丰富，开发效率也很高。但，一个完整HTML5页面的展示要经历浏览器控件的加载、解析和渲染三大过程，性能消耗要比原生开发增加N个数量级。

所以对于大多数系统能力都没有访问权限，如无法访问文件系统、不能使用蓝牙等。所以，对于 H5 不能实现的功能，就需要原生去做了。

接下来，我以加载过程为例，和你说明这个过程的复杂性。

浏览器控件加载HTML5页面的HTML主文档；(Html)
加载过程中遇到外部CSS文件，浏览器另外发出一个请求，来获取CSS文件； (css)
遇到图片资源，浏览器也会另外发出一个请求，来获取图片资源。这是异步请求，并不会影响HTML文档的加载。(pic)
加载过程中遇到JavaScript文件，由于JavaScript代码可能会修改DOM树，因此HTML文档会挂起渲染（加载解析渲染同步）的线程，直到JavaScript文件加载解析并执行完毕，才可以恢复HTML文档的渲染线程。(JS)
JavaScript代码中有用到CSS文件中的属性样式，于是阻塞，等待CSS加载完毕才能恢复执行。

而这，只是完成HTML5页面渲染的最基础的加载过程。加载、解析和渲染这三个过程在实际运行时又不是完全独立的，还会有交叉。

也就是说，会存在一边加载，一边解析，一边渲染的现象。这，就使得页面的展示并不像想象中那么容易。

通过上面的分析你可以看出，一个HTML5页面的展示是多么得复杂！这和原生开发通过简单直接的创建控件，设置属性后即可完成页面渲染有非常大的差异。Web与原生在UI渲染与系统功能调用上各司其职，因此这个时代的框架在Web与原生系统间还有比较明显的、甚至肉眼可见的边界。

缺点:

ui渲染效果差, 因为经历浏览器控件的加载、解析和渲染三大过程

有人说是动态解析js脚本, 而native都是一句编译优化的字节码,甚至是aot机器码!

web 布局复杂, 导致渲染一帧需要多次遍历UI组件

缺点是性能体验不佳，对于复杂用户界面或动画，WebView 有时会不堪重任。

原理: 用的是原生应用内嵌浏览器控件WebView的方式进行HTML5页面渲染, 通过js进行桥接,完成原生交互.(使用前端技术)

4.2 泛Web容器时代(Js+原生渲染)

对于用户体验更接近于原生的React Native，对业务的支持能力却还不到浏览器的5%，仅适用于中低复杂度的低交互类页面。面对稍微复杂一点儿的交互和动画需求，开发者都需要case by case地去review，甚至还可能要通过原生代码去扩展才能实现。

虽然Web容器方案具有生态繁荣、开发体验友好、生产效率高、跨平台兼容性强等优势，但它最大的问题在于承载着大量Web标准的Web容器过于笨重，以至于性能和体验都达不到与原生同样的水准，在复杂交互和动画上较难实现出优良的用户体验。

而在实际的产品功能研发中，我们通常只会用到Web标准中很小的一部分。面对这样的现实，我们很快就想到：能否对笨重的Web容器进行功能裁剪，在仅保留必要的Web标准和渲染能力的基础上，使得友好的开发体验与稳定的渲染性能保持一个平衡？

答案当然是可以。

泛Web容器时代的解决方案优化了Web容器时代的加载、解析和渲染这三大过程，把影响它们独立运行的Web标准进行了裁剪，以相对简单的方式支持了构建移动端页面必要的Web标准（如Flexbox等），也保证了便捷的前端开发体验；同时，这个时代的解决方案基本上完全放弃了浏览器控件渲染，而是采用原生自带的UI组件实现代替了核心的渲染引擎，仅保持必要的基本控件渲染能力，从而使得渲染过程更加简化，也保证了良好的渲染性能。

也就是说，在泛Web容器时代，我们仍然采用前端友好的JavaScript进行开发，整体加载、渲染机制大大简化，并且由原生接管绘制，即将原生系统作为渲染的后端，为依托于JavaScript虚拟机的JavaScript代码提供所需要的UI控件的实体。这，也是现在绝大部分跨平台框架的思路，而React Native和Weex就是其中的佼佼者。

由于 RN 和 React 原理相通，并且 Flutter在应用层也是受 React 启发，很多思想也都是相通的，因此，我们有必要深入了解一下React原理。

React 是一个响应式的 Web 框架，我们先了解一下两个重要的概念：DOM 树与响应式编程。

如果 DOM 只是外观风格发生变化，如颜色变化，会导致浏览器重绘界面。
如果 DOM 树的结构发生变化，如尺寸、布局、节点隐藏等导致，浏览器就需要回流。

React Native希望开发者能够在性能、展示、交互能力和迭代交付效率之间做到平衡。它在Web容器方案的基础上，优化了加载、解析和渲染这三大过程，以相对简单的方式支持了构建移动端页面必要的Web标准，保证了便捷的前端开发体验；并且在保留基本渲染能力的基础上，用原生自带的UI组件实现代替了核心的渲染引擎，从而保证了良好的渲染性能。

泛Web容器时代不足：

React Native技术关键词：

1）Facebook 出品；
2）JavaScript语言；
3）原生渲染。

React Native的缺点:

1. 渲染: 由于React Native的技术方案所限，使用原生控件承载界面渲染，在牺牲了部分Web标准灵活性的同时，

渲染时需要 JavaScript 和原生之间通信，在有些场景如拖动可能会因为通信频繁导致卡顿。

2. 性能消耗: 除开通过JavaScript虚拟机进行原生接口的调用，而带来的通信低效不谈，由于框架本身不负责渲染，而是由原生代理，因此我们还需要面对大量平台相关的逻辑。

3. 不稳定bug, 而随着系统版本和API的变化，我们还需要处理不同平台的原生控件渲染能力上的差异，修复各类怪异的Bug，甚至还需要在原生系统上打各类补丁。

4. 复杂, 要用好React Native，除了掌握这个框架外，开发者还必须同时熟悉iOS和Android系统。这，无疑给开发者提出了更多挑战

由于渲染依赖原生控件，不同平台的控件需要单独维护，并且当系统更新时，社区控件可能会滞后；除此之外，其控件系统也会受到原生UI系统限制，例如，在 Android 中，手势冲突消歧规则是固定的，这在使用不同人写的控件嵌套时，手势冲突问题将会变得非常棘手。这就会导致，如果需要自定义原生渲染组件时，开发和维护成本过高

5.复杂的动画实现有问题

6. JavaScript 为脚本语言，执行时需要解释执行（这种执行方式通常称为 JIT，即 Just In Time，指在执行时实时生成机器码），执行效率和编译类语言（编译类语言的执行方式为 AOT ，即 Ahead Of Time，指在代码执行前已经将源码进行了预处理，这种预处理通常情况下是将源码编译为机器码或某种中间码）仍有差距。

原理: 保证了便捷的前端开发体验；并且在保留基本渲染能力的基础上，用原生自带的UI组件实现代替了核心的渲染引擎，从而保证了良好的渲染性能。

其UI渲染、动画效果、网络请求等均是由原生来实现的,通过JS代码来调用原生的组件，从而实现相应的功能, 中间经过js的交互, 比较耗性能!

4.3 自绘引擎时代 (自绘UI+原生)

Google新系统Fuchsia的发布, Fuchsia OS 是谷歌研发的一款面向多平台的操作系统，以取代安卓系统

Flutter是构建Google物联网操作系统Fuchsia的SDK，主打跨平台、高保真、高性能。开发者可以通过 Dart语言开发App，一套代码可以同时运行在 iOS 和 Android平台。 Flutter使用Native引擎渲染视图

自绘引擎解决的是 UI 的跨平台问题，如果涉及其他系统能力调用，依然要涉及原生开发

泛Web容器时代使用原生控件承载界面渲染，固然解决了不少性能问题，但同时也带来了新的问题。抛开框架本身需要处理大量平台相关的逻辑外，随着系统版本变化和API的变化，我们还需要处理不同平台的原生控件渲染能力差异，修复各类奇奇怪怪的Bug。始终需要Follow Native的思维方式，就使得泛Web容器框架的跨平台特性被大打折扣。

Flutter是怎么运转的?

与用于构建移动应用程序的其他大多数框架不同，Flutter是重写了一整套包括底层渲染逻辑和上层开发语言的完整解决方案。

这样不仅可以保证视图渲染在Android和iOS上的高度一致性（即高保真），在代码执行效率和渲染性能上也可以媲美原生App的体验（即高性能）。

这，就是Flutter和其他跨平台方案的本质区别：

React Native之类的框架，只是通过JavaScript虚拟机扩展调用系统组件，由Android和iOS系统进行组件的渲染；
Flutter则是自己完成了组件渲染的闭环。

Flutter的关键技术，即Skia和Dart。

而这一时期的代表Flutter则开辟了一种全新的思路，**即从头到尾重写一套跨平台的UI框架，包括渲染逻辑，甚至是开发语言。**Flutter2个主要特点 :skia和dart****

渲染引擎依靠跨平台的Skia图形库来实现，Skia引擎会将使用Dart构建的抽象的视图结构数据加工成GPU数据，交由OpenGL最终提供给GPU渲染，至此完成渲染闭环，因此可以在最大程度上保证一款应用在不同平台、不同设备上的体验一致性。
而开发语言选用的是同时支持JIT（Just-in-Time，即时编译）和AOT（Ahead-of-Time，预编译）的Dart，不仅保证了开发效率，更提升了执行效率（比使用JavaScript开发的泛Web容器方案要高得多）。flutter的表现子热更新和热重载上!

flutter绘制图:

flutter渲染.jpg

对比总结:

flutter比较的方案.jpg

动态化主要指是否支持动态下发代码和是否支持热更新。

值得注意的是 Flutter 的Release 包默认是使用 Dart AOT 模式编译的，所以不支持动态化，

但 Dart 还有 JIT 或 snapshot 运行方式，这些模式都是支持动态化的。

主流框架的对比

从各个维度综合考量，React Native和Flutter无疑是最均衡的两种跨平台开发方案，而其他的方案或多或少都“偏科严重”。

React Native依托于Facebook，经过4年多的发展已经成长为跨平台开发方案的实际领导者，并拥有较为丰富的第三方库和开发社区；

RN的效率由于是将View编译成了原生View,所以效率上要比基于Cordova的HTML5高很多,但是它也有效率问题,RN的渲染机制是基于前端框架的考虑,复杂的UI渲染是需要依赖多个view叠加.比如我们渲染一个复杂的ListView,每一个小的控件,都是一个native的view,然后相互组合叠加.想想此时如果我们的list再需要滑动刷新,会有多少个对象需要渲染.所以也就有了前面所说的RN的列表方案不友好。

Flutter以挑战者姿态出现在我们的面前，可以提供更彻底的跨平台技术解决方案。虽然Flutter推出时间不长，但也有了诸多商用案例，加上清晰的产品路线图和Google的强大号召力，Flutter未来的发展非常值得期待。

，Flutter使用自己的渲染引擎来绘制UI，布局数据等由Dart语言直接控制，所以在布局过程中不需要像RN那样要在JavaScript和Native之间通信，在一些滑动和拖动的场景下具有明显优势。由于滑动和拖动往往会引起布局的变化，所以JavaScript需要不停地与Native之间同步布局信息，这和在浏览器中要JavaScript频繁操作DOM所带来的问题是相同的，都会带来比较可观的性能开销。因此，Flutter能保证每端运行的UI都维持高度一致。

Flutter：吸收了前两者的教训之后,在渲染技术上,选择了自己实现(GDI),由于有更好的可控性,使用了新的语言Dart,避免了RN的那种通过桥接器与Javascript通讯导致效率低下的问题,所以在性能方面比RN更高一筹;有经验的开发者可以打开Android手机开发者选项里面的显示边界布局,发现Flutter的布局是一个整体.说明Flutter的渲染没用使用原生控件进行渲染。

总结: 在Google的强力带动下，Flutter极有可能成为跨平台开发领域的终极解决方案

问题: flutter和React Native的区别是啥?

一句话:  React Native是调用系统的组件渲染, Flutter直接绘制组件!

问题: web容器时代和泛web容器时代的区别是啥?

一个是采用浏览器组件webview渲染, 一个是原生渲染!

其实就是:为什么原生渲染会比webView渲染效果好很多呢

初始化webView过程耗时, ****WebView的渲染进程是独立的，每一帧的更新都要通过IPC调用GPU进程，会造成频繁的IPC进程通信，从而造成性能消耗,

手势、动画 这两个会比较消耗性能

5.为什么大厂不用flutter

flutter接入调研和 flutter实际过程中的缺点

`调研: 看别人的文档

在某一块上线, 观察性能和原生对比`

存在的问题包括但不限于下面列举的一些：

表现不一致问题
1. CSS 定位、布局表现与浏览器表现不一致
2. 部分 API 表现与浏览器不一致(getBoundingClientRect等)
3. iOS，Android系统表现不一致
重大 Bug
1. 页面初始化渲染完成，动态修改元素样式，DOM不重新渲染
2. 滑动监听计算导致 APP 崩溃
调试成本高
1. 不支持 vue-router，单项目单路由
2. 不支持热更新，npm run build 预览
3. 不支持 sourceMap，无法定位源代码
4. 真机调试只支持 element 和 network；dom 和 element 无法互相选中；无法动态修改 dom 结构，无法直接修改样式…
5. 页面白屏，假死

flutter的一些缺点

1.启动

2. 性能

3.渲染, 白屏, 滑动

4.android和ios, 样式表现

少了反射，json解析

flutter适用的业务: 电商: 外卖, 更新比较频繁的跨平台, 手机端

不适合的业务: 手机厂商，车载, 硬件平台相关, 音视频, 游戏

6. 为啥用dart作为flutter语言

最初设计也是为了取代JavaScript成为Web开发的官方语

Dart因为同时支持AOT和JIT，所以具有运行速度快、执行性能好的特点外，Flutter为什么选择了Dart，而不是前端应用的准官方语言JavaScript呢？这个问题很有意思，但也很有争议。

Google公司给出的原因很简单也很直接：Dart语言开发组就在隔壁，对于Flutter需要的一些语言新特性，能够快速在语法层面落地实现；而如果选择了JavaScript，就必须经过各种委员会和浏览器提供商漫长的决议。

，Google公司选择使用Dart作为Flutter的开发语言，我想还有其他更有说服力的理由：

Dart语言的优点:

Dart同时支持即时编译JIT和事前编译AOT。在开发期使用JIT，开发周期异常短，调试方式颠覆常规（支持有状态的热重载）；而发布期使用AOT，本地代码的执行更高效，代码性能和用户体验也更卓越。
Dart作为一门现代化语言，集百家之长，拥有其他优秀编程语言的诸多特性（比如，完善的包管理机制）。也正是这个原因，Dart的学习成本并不高，很容易上手。
Dart避免了抢占式调度和共享内存，可以在没有锁的情况下进行对象分配和垃圾回收，在性能方面表现相当不错。

Dart 运行时和编译器支持 Flutter 的两个关键特性的组合：