如何高效、快速学习 Flutter？如何避坑，膜拜大牛
对于客户端原生开发而言，声明式的开发方式一上手就不习惯，习惯了代码与布局分离（java\kotlin + xml ）和命令式的对象编程，声明式开发需要额外的学习成本；同时也觉得 Flutter 的嵌套很“恶心”。
对于前端开发而言，Flutter 的环境配置很烦人，除了 VSCode 和 Flutter SDK 之外，还需要原生的如 Java 、Gradle 、Android SDK 、XCode 等“出圈”的环境变量（时不时遇上网络问题），而且 Flutter 所需要的原生平台知识点对前端来说很不友好；同时也觉得 Flutter 的嵌套很“恶心”。
发现没有？我没有说 Dart 语言是学习成本，因为无论对于擅长 JS 的前端而言，还是对于掌握 Java\Kotlin\Swift 的客户端而言，Dart 无论怎么看都是“弟弟”。
另外不管是前端还是客户端，都会对 Flutter 的嵌套很“恶心”做出抨击，但是嵌套问题严重吗？这个我们后面会聊到。
综上所述， Flutter 对于前端入坑或者客户端入坑的萌新来说，都会有一定程度的门槛和心理抵触。那对于前端或者客户端来说，有没有必须要学习 Flutter 呢？
_2_学习 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 的性能
这里主要介绍几个误区：
1、Flutter 在 debug 和 release 下的性能差距是巨大的，因为它们之间是 JIT 和 AOT 的区别。
2、不要在模拟器上测试性能，这个根本没有意义，因为在手机上 Flutter 会更多依赖 GPU 的能力。
3、混合开发 Flutter 是有性能有影响的，比如在原有 Android 项目里，把某个模块业务逻辑改用 Flutter 实现，这对性能和内存会有很大的考验，至于为什么？就是前面说过 Flutter 独立的控件渲染和堆栈管理带来的负面效果。
4、同一个框架在不同人手下会写出不一样的结果，一般情况下对于普通开发者来说，流行的框架一般不会带来很大的性能瓶颈，反而是开发能力比较多导致项目的瓶颈。
_3_怎么学 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 中也类似，当你通过这样的 true 和? 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 final
class 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("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: () {
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论