uniapp 开发工具,uniapp和flutter对比

2022-07-06 01:27:55 证券专题

　　回顾这段时间回答各种关于颤振的问题，突然发现很多刚接触颤振的萌芽学生对颤振都有不同程度的误解，每次重复解释都是浪费时间。最后我决定写一篇文章做个总结。　　

　　内容有点长，但相信可以帮助你更好的了解Flutter。　　

　　扑的起源扑的诞生其实挺有意思的。Flutter 诞生于 Chrome 团队的一场内部实验,谷歌的前端团队，在前端去除了一些“杂乱”的规范后，在基准测试中发现性能居然提升了20倍，Flutter也是偶然被认可的。　　

　　所以Flutter是基于前端诞生的，同时基于它的诞生原因，我们可以看到作为框架的“保守”的Flutter 本身就不会有特别多的语法糖,选择的Dart语言也是保守的语言。而它的编程模式，语法都带有浓厚的前端色彩，可是它却最先运用在移动客户端的开发。 　　

　　所以当Flutter出来的时候，它需要面对一个非常尴尬的状态：　　

　　对于客户端原生开发而言，声明式的开发方式一上手就不习惯,习惯了代码与布局的分离(java\kotlin xml)和命令式对象编程，需要额外的学习成本进行声明式开发；对于同时也觉得 Flutter 的嵌套很“恶心”。,Flutter 的环境配置很烦人,的前端开发除了VSCode和Flutter SDK，还需要Java、Gradle、Android SDK、XCode等原生的“环外”环境变量(时不时遇到网络问题)，Flutter 所需要的原生平台知识点对前端来说很不友好;同时也觉得 Flutter 的嵌套很“恶心”。找到了吗？我没有说Dart语言是学习成本，因为Dart 无论怎么看都是“弟弟”,无论是对于擅长JS的前端，还是对于懂Java\Kotlin\Swift的客户端。　　

　　另外，前端和客户端都会攻击Flutter的嵌套“恶心”，但是嵌套问题严重吗？我们以后再谈这个。　　

　　综上所述，无论是前端入坑还是客户端入坑，旋舞都会对孟新产生一定的门槛和心理冲突。那对于前端或者客户端来说，有没有必须要学习 Flutter 呢？ 　　

　　学习Flutter的原因是我接触了有很大一部分其实是“被迫”使用 Flutter.大多数Flutter萌芽学校，因为领导或老板要求学习Flutter，我不得不开始学习Flutter“即使我想”。这是最有力的理由之一：“老板(领导)要”，除非你选择“跳槽”，飞出三界。　　

　　1.在个人竞争力的层面上，发展这个圈子其实很有意思。我们经常会觉得一个技术用久了很热，因为周围的人都在用，而其他框架很冷。由于存在没人用的错觉，尤其是在“媒体”的煽动下，“孕妇效应”很容易导致认知误区。　　

　　去年年中，我在《国内大厂在移动端跨平台的框架接入分析》对53个样本做了一个简单的数据分析，我们可以看到flutter(19)、weex(17)、react-native(22)都在其中。同时下图是libChecker统计的个人手机中Flutter的制作应用。　　

　　这个介绍只是为了表达：Flutter 现在已经不是曾经的小众框架，这两年里它已经逐步成为主流的跨平台开发框架之一。. 　　

　　所以Flutter真的可以帮你找工作。当然，我不建议你从零开始学习Flutter，因为 Flutter 本身只是一个跨平台 UI 框架。. 　　

　　理解上面这句话很重要，因为他可以避免你被“贩卖焦虑”, Flutter支持移动、Web、PC，但作为UI框架，主要帮助我们解决UI的“跨平台”和一些业务逻辑，而和平台相关的诸如蓝牙、平台交互、数据存储、打包构建等等都离不开原生的支持. 　　

　　目前的跨平台框架，无论是Flutter还是react-native还是weex，都定位为UI框架，它们解决的是 UI 业务跨平台的成本,及其开发都离不开原生平台开发的支持。　　

　　如果所有原生平台都死了，有什么区别？现在举个例子，谁来说说穿越WinPhone？所以 Flutter 和原生平台应该是相互成长的局势，而不是那些《xxx制霸，###要 　　

凉的》的“节奏党”，都是寄生和共生的关系，没有对应平台的开发经验，是很难把 Flutter 用得“愉悦”。

不过现在 Flutter 确确实实可以帮助到你的职业发展，因为通过 Flutter 放大你的业务开发能力，让你参与到更多的平台开发中，不过是大前端还是KPI。当然这些 react-native、 uni-app 也可以带给你，甚至对于前端开发来说可能更低，那为什么还要选择 Flutter 呢？

事实上还有一个有意思的点，对于 Android 原生开发来说，学会 Flutter 等于学会了 70% 以上的 Jetpack Compose 。

2、Flutter 的一致性事实上从我个人一直比较推荐客户端学 Flutter ，因为对于前端来说 react-native、 uni-app 确实是性价更高的，当然好像各位的领导和老板们不是这么觉得。

那么使用 Flutter 有什么额外的好处呢？那就是 Flutter 的性能和一致性。

因为 Flutter 作为 UI 框架，它是真的跨平台！ 为什么要强调 “真跨平台” ，因为和 react-native 、 weex 不同，Flutter 的控件不是通过原生控件去实现的渲染，而是由 Flutter Engine 提供的平台无关的渲染能力，也就是 Flutter 的控件和平台没关系。

简单来说，原生平台提供一个 Surface 作为画板，之后剩下的只需要由 Flutter 来渲染出对应的控件，而这个过程最终是打包成 AOT 的二进制完成。

所以 Flutter 的 UI 控件可以做到所见即所得，这个对我个人来说是很重要的进步。为什么这么说呢？这时候就需要拿 react-native 来做对比。

因为 react-native 是通过将 JS 里的控件转化为原生控件进行渲染，所以 rn 里的控件是需要依赖原生平台的控件，所以不同系统之间原生控件的差异，同个系统的不同版本在控件上的属性和效果差异，组合起来在后期开发过程中就是很大的维护成本。

在我 react-native 开发生涯中，就经常出现：

在 iOS 上调试好的样式，在 Android 上出现了异常；在 Android 上生效的样式，在 iOS 上没有支持；在 iOS 平台的控件效果，在 Android 上出现了不一样的展示，比如下拉刷新，Appbar等；当然，这些问题最终都可以通过 if else 和自定义平台控件来解决，但是随着项目的发展，这样的结果无疑违背了我使用跨平台的初衷。

而 Flutter 的控件特性决定了它没有这些问题，我甚至经常只在 iOS 模拟器上开发测试所有界面逻辑，而不用担心 Android 上的兼容，当然屏幕大小的适配是不可避免的。

从这个角度上不严谨地说， Flutter 更像是一个类 unity 的轻度游戏引擎，不过它提供的是 2D 的控件。

当然，Flutter 这样实现也有坏处，那就是当你需要使用平台的控件作为混合开发时，Flutter 的成本和体验无疑被放大 ，这一点上 react-native 反而有着先天的优势。

3、Flutter 的性能 Flutter 的性能一般情况下是比 react-native 好，这里主要介绍几个误区：

1、Flutter 在 debug 和 release 下的性能差距是巨大的，因为它们之间是 JIT 和 AOT 的区别。2、不要在模拟器上测试性能，这个根本没有意义，因为在手机上 Flutter 会更多依赖 GPU 的能力。3、混合开发 Flutter 是有性能有影响的，比如在原有 Android 项目里，把某个模块业务逻辑改用 Flutter 实现，这对性能和内存会有很大的考验，至于为什么？就是前面说过 Flutter 独立的控件渲染和堆栈管理带来的负面效果。4、同一个框架在不同人手下会写出不一样的结果，一般情况下对于普通开发者来说，流行的框架一般不会带来很大的性能瓶颈，反而是开发能力比较多导致项目的瓶颈。怎么学 Flutter ？当你快速搭建好环境，简单了解 Flutter 的 API 之后，学习 Flutter 在我看来主要有两个核心点：响应式开发和 Widget 的背后是什么？

1、响应式开发响应式开发相信对于前端来说再熟悉不过，这部分内容对于前端开发来说其实可以略过，响应式编程也叫做声明式编程，这是现在前端开发的主流，当然对于客户端开发的一种趋势，比如 Jetpack Compose 、SwiftUI 。

Jetpack Compose 和 Flutter 的相似程度绝对让你惊讶。

什么是响应式开发呢？简单来说其实就是你不需要手动更新界面，只需要把界面通过代码“声明”好，然后把数据和界面的关系接好，数据更新了界面自然就更新了。

从代码层面看，对于原生开发而言，响应式开发中没有 xml 的布局，布局完全由代码完成，所见即所得，同时你也不会需要操作界面“对象”去进行赋值和更新，你所需要做的就是配置数据和界面的关系。

举个例子：

以前在 Android 上你需要写一个 xml ，然后布局一个 TextView ，通过 findViewById 得到这个对象，再调用 setText 去赋值；现在 Flutter 里，你只需要声明一个 Text 的 Widget ，并把 data.title 这样的数据配置给 Text ，当数据改变了， Text 的显示内容也随之改变；

对于 Android 开发而言，大家可能觉得这不就是 MVVM 下的 DataBinding 也一样吗？其实还不大一样，更形象的例子，这里借用扔物线大佬在谷歌大会关于 Jetpack Compose 的分享，为什么 Data Binding 模式不是响应式开发：

因为 Data Binding（不管是这个库还是这种编程模式）并不能做到「声明式 UI」，或者说声明式 UI 是一种比数据绑定更强的数据绑定，比如在 Compose 里你除了简单地绑定字符串的值，还可以用布尔类型的数据来控制界面元素是否存在，例如再创建另外一个布尔类型的变量，用它来控制你的某个文字的显示：

注意，当 show 先是 true 然后又变成 false 的时候，不是设置了一个 setVisibility(GONE) 这样的做法，而是直接上面的 Text() 在界面代码中消失了，每次数据改变所导致的界面更新看起来就跟界面关闭又重启、并用新的数据重新初始化了一遍一样，这才叫声明式 UI，这是数据绑定做不到的。

当然 Compose 并不是真的把界面重启了，它只会刷新那些需要刷新的部分，这样的话就能保证，它自动的更新界面跟我们手动更新一样高效。

在 Flutter 中也类似，当你通过这样的 ture 和 false 去布局时，是直接影响了 Widget 树的结构乃至更底层的渲染逻辑，所以作为 Android 开发在学习 Flutter 的时候，就需要习惯这种开发模式，“放弃” 在获取数据后，想要保存或者持有一个界面控件进行操作的想法。另外在 Flutter 中，持有一个 Widget 控件去修改大部分时候是没意义的，也是接下来我们要聊的内容。

2、Widget 的背后Flutter 内一切皆 Widget ，Widget 是不可变的（immutable），每个 Widget 状态都代表了一帧。

理解这段话是非常重要的，这句话也是很多一开始接触 Flutter 的开发者比较迷惑的地方，因为 Flutter 中所有界面的展示效果，在代码层面都是通过 Widget 作为入口开始。

Widget 是不可变的，说明页面发生变化时 Widget 一定是被重新构建， Widget 的固定状态代表了一帧静止的画面，当画面发生改变时，对应的 Widget 一定会变化。

举个我经常说的例子，如下代码所示定义了一个 TestWidget，TestWidget 接受传入的 title 和 count 参数显示到 Text 上，同时如果 count 大于 99，则只显示 99。

/// Warnning/// This class is marked as '@immutable'/// but one or more of its instance fields are not finalclass TestWidget extends StatelessWidget { final String title; int count; TestWidget({this.title, this.count}); @override Widget build(BuildContext context) { this.count = (count > 99) ? 99 : count; return Container( child: new Text("$title $count"), ); }}这段代码看起来没有什么问题，也可以正常运行，但是在编译器上会有 “This class is marked as '@immutable'，but one or more of its instance fields are not final” 的提示警告，这是因为 TestWidget 内的 count 成员变量没有加上 final 声明，从而在代码层面容易产生歧义。

因为前面说过 Widget 是 immutable ，所以它的每次变化都会导致自身被重新构建，也就是 TestWidget 内的 count 成员变量其实是不会被保存且二次使用。

如上所示代码中 count 成员没有 final 声明，所以理论是可以对 count 进行二次修改赋值，造成 count 成员好像被保存在 TestWidget 中被二次使用的错觉，容易产生歧义，比如某种情况下的 widget.count，所以需要加这个 final 就可以看出来 Widget 的不可变逻辑。

如果把 StatelessWidget 换成 StatefulWidget ，然后把 build 方法放到 State 里，State 里的 count 就可以就可以实现跨帧保存。

class TestWidgetWithState extends StatefulWidget { final String title; TestWidgetWithState({this.title}); @override _TestWidgetState createState() => _TestWidgetState();}class _TestWidgetState extends State<TestWidgetWithState> { int count; @override Widget build(BuildContext context) { this.count = (count > 99) ? 99 : count; return InkWell( onTap: () { setState(() { count++; }); }, child: Container( child: new Text("${widget.title} $count"), ), ); }}所以这里最重要的是，首先要理解 Widget 的不可变性质，然后知道了通过 State 就可以实现数据的跨 Widget 保存和恢复，那为什么 State 就可以呢？

这就涉及到 Flutter 中另外一个很重要的知识点，Widget 的背后又是什么？事实上在 Flutter 中 Widget 并不是真正控件，在 Flutter 的世界里，我们最常使用的 Widget 其实更像是配置文件，而在其后面的 Element 、RenderObject 、Layer 等才是实际“干活”的对象。

Element 、RenderObject 、Layer 才是需要学习理解的对象。

简单举个例子，如下代码所示，其中 testUseAll 这个 Text 在同一个页面下在三处地方被使用，并且代码可以正常运行渲染，如果是一个真正的 View ，是不能在一个页面下这样被多个地方加载使用的。

在 Flutter 设定里，Widget 是配置文件告诉 Flutter 你想要怎么渲染， Widget 在 Flutter 里会经过 Element 、RenderObject、乃至 Layer 最终去进行渲染，所以作为配置文件的 Widget 可以是 @immutable，可以每次状态更新都被重构。

所以回到最初说过的问题：Flutter 的嵌套很恶心？是的 Flutter 设定上确实导致它会有嵌套的客观事实，但是当你把 Widget 理解成配置文件，你就可以更好地组织代码，比如 Flutter 里的 Container 就是一个抽象的配置模版。

参考 Container 你就学会了 Flutter 组织代码逻辑的第一步。

同时因为 Widget 并不是真正干活的，所以嵌套事实上并不是嵌套 View ，一般情况下 Widget 的嵌套是不会带来什么性能问题，因为它不是正式干活的，嵌套不会带来严重的性能损失。

举个例子，当你写了一堆的 Widget 被加载时，第一次会对应产生出 Element ，之后 Element 持有了 Widget 和 RenderObject 。

简单的来说，一般情况下画面的改变，就是之后 Widget 的变化被更新到 RenderObject ，而在 Flutter 中能够跨帧保存的 State ，其实也是被 Element 所持有，从而可以用来跨 Widget 保存数据。

所以 Widget 的嵌套一般不会带来性能问题，每个 Widget 状态都代表了一帧，可以理解为这个“配置信息”代表了当前的一个画面，在 Widget 的背后，嵌套的 Padding 、Align 这些控件，最后只是 canvas 时的一个“偏移计算”而已。

所以理解 Widget 控件很重要，Widget 不是真正的 View ，它只是配置信息，只有理解了这点，你才会发现 Flutter 更广阔的大陆，比如：

Flutter 的控件是从 Elemnt 才开始是真正的工作对象；要看一个 Widget 的界面效果是怎么实现，应该去看它对应的 RenderObejcet 是怎么绘制的；要知道不同堆栈或者模块的页面为什么不会互相干扰，就去看它的 Layer 是什么逻辑；是不是所有的 Widget 都有 RenderObejcet ？ Widget 、 Elemnt 、RenderObejcet 、Layer 的对应关系是什么？这些内容才是学 Flutter 需要如理解和融会贯通的，当你了解了关于 Widget 背后的这一套复杂的逻辑支撑后，你就会发现 Flutter 是那么的简单，在实现复杂控件上是那么地简单，Canvas 组合起来的能力是真的香。

Flutter 是个有坑的框架最后讲讲 Flutter 的坑，事实上没有什么框架是没有坑的，如果框架完美得没有问题，那我们竞争力反而会越来越弱，可替换性会更高。

这也是为什么一开始 Andorid 和 iOS 开发很火热，而现在客户端开发招聘回归理性的原因，因为这个领域已经越来越成熟，自然就“卷”了。

事实上我一直觉得使用框架的我们并没有什么特殊价值，而解决使用框架所带来的问题才是我们特有的价值。

而 Flutter 的问题也不少，比如:

WebView 的问题：Flutter 特有的 UI 机制，导致了 Flutter 需要通过特殊的方式来接入比如 WebView 、MapView 这样的控件，而这部分也导致了接入后不断性能、键盘、输入框等的技术问题，具体可以参考：《Hybrid Composition 深度解析》和《 Android PlatformView 和键盘问题》。图片处理和加载：在图片处理和加载上 Flutter 的能力无疑是比较弱的，同时对于单个大图片的加载和大量图片列表的显示处理上，Flutter 很容易出现内存和部分 GPU 溢出的问题。而这部分问题处理起来特别麻烦，如果需要借用原生平台来解决，则需要通过外界纹理的方式来完成，而这个实现的维护成本并不低。混合开发是避免不了的话题：因为 Flutter 的控件和页面堆栈都脱离原生平台，所以混合开发的结果就会导致维护成本的提高，现在较多使用的 flutter_boost 和 flutter_thrio 都无法较好的真正解决混合开发中的痛点，所以对于 Flutter 来说这也是一大考验。