走进Flutter | 开篇

Posted 2021-04-29 智慧市政青年社

Back to

School

开篇 | 通往大前端的一把关键钥匙

Flutter

近年来，大前端因为“一套代码，多端运行”的特性成为大势所趋，各公司都致力于将团队培养为Web前端全栈及大前端双通道人员，借此提升前端技术人员在未来很长一段时间的竞争力。

从 Hybrid 到 Weex、React Native 这些跨端技术的出现，确实很好地解决了跨端技术不一致、热加载、提升开发效率，以及降低开发成本的问题，但一个核心技术痛点“性能问题”却一直没有非常好的解决方案。而仅仅出道 2 年的 Flutter，通过自渲染模式，以及在体验和性能上的优异表现一时风头无两，其性能更是在跨端技术中处于领跑地位。

除了大量为适应快速发展节奏和节省人力成本的中小型企业，很多一线互联网企业也在重要项目中落地了 Flutter 技术，包括阿里（闲鱼）、蚂蚁金服（蚂蚁财富）、腾讯（多款在线教育App）、字节跳动（头条和西瓜视频），以及美团（美团 App）和快手（快手 App），等等。

在学习和实践 Flutter 的过程中，很多技术人普遍面临这样几类问题。

1. 学习资料大多从 0 到 1，偏入门+实战。

基础课程是掌握一门新技术的必备环节，但在足够系统的同时，也会有知识点重合度较高的问题。一些常见的知识点学习起来比较浪费时间，需要你自己去抽离重点，毕竟学 Flutter 的技术人，一般也都懂些基础内容。

2. 实践及场景应用少，无法直接反馈到工作中。

学到了些 Flutter 核心技术，但缺少进阶和综合应用，混合开发的内容很少，所以无法开发出一个实际的项目应用，也没办法解决你工作上的实际问题，导致在 Flutter 上还是经常踩坑。

3.直接上手开发，却不了解核心原理，不能从源处寻找一些优化方向和优化策略。

工作中的开发往往只关注实际用法，很少有时间去注重基础原理，从而忽略了这块重要知识，导致优化方向只能从他人的经验中去学习。但是，很多问题都有一定的独特性，需要你具备快速定位和分析解决问题的能力，不能一切依靠“搜索”能力。

其实，学习一门新的语言或者框架无外乎这样一个路径：第一步，需要快速理清一些核心基础知识点，掌握编程语法和运行原理；第二步，实践应用开发，通过项目实践来熟悉开发过程中的一些工具、规范和常见问题；第三步，掌握核心设计思想和实现原理，能够基于一些核心原理寻找一些底层优化策略。本专栏主要从这几个角度来进行分享。

什么是大前端?

随着互联网技术的发展，业务平台对多设备、多终端的需求越来越多，因此，仅掌握单一平台编程开发能力已经稍显欠缺。由于在业务开发过程中，开发者大部分的时间都专研于一种编程语言，如果想要掌握多端开发能力，则又稍显力不从心。因此大前端的概念应运而生，本课时主要介绍大前端的发展历程，以及如何做好大前端技术的选型分析。

大前端概念对于编程开发者来说早已耳熟能详，通过同一套编程代码，经过框架编译转化能够适应于多端平台的前端交互界面。当然这里只介绍目前应用较广的三个方面，即 ios、Andorid 和 Web H5，之后可以再延伸到小程序、TV、Watch 等其他智能设备，如图 1 所示。

大前端的核心是为了解决多端不一致和人力的问题。比如在一些交互复杂度不高的应用中，通过这种模式可以更好地节省人力成本，特别是在一些前期快速发展的创业公司，可以使用较少的人力来支撑一些核心业务功能。

跨端技术的发展

移动端跨平台技术经过了一个漫长的发展史，如图 2 所示。下面主要介绍下在这个发展过程中跨平台技术有了哪些进步或者做了哪些优化。

技术	核心	原生支持	动态性	性能	体验
Ionic/Cordova	JSBridge 封装给 Web 调用	90%	中	差	差
React Native/Weex	JIT 模式应用 JS 与原生通信	20%	好	中	中
Flutter	自渲染	5%	优	良	优

• Ionic/Cordova（Hybrid），在技术原理上的核心是，将原生的一些能力通过 JSBridge 封装给 Web 来调用，扩充了 Web 应用能力。但是这种方法有两个不足，一是依赖客户端，二是在性能和体验上都非常依赖于 Web 端（Hybrid 其实是一个 H5 页面，在每个 APP 中包了一个 H5 的 Web 页面，只是在需要原生功能的地方，通过原生封装一些 JSAPI 给到页面去调用，看起来就像是 H5 拥有了原生 APP 交互功能。）。因此，整体上的体验不可预知。目前这个技术还经常被应用到，例如，当前 App 内会提供白名单域名和可调用的 JSBridge 方法，由此来增强 H5 与客户端交互能力，从而提升 App 内 H5 的灵活性。

• React Native/Weex，在原来的 Hybrid 的 JSBridge 基础上进行改进，将 javascript 的界面以及交互转化为 Native 的控件，从而在体验上和原生界面基本一致。但因为是 JIT 模式（用的是原生的界面，但是用户的各类事件操作，都是需要与 JS 进行操作，而 JS 操作后，需要将响应反馈到原生 Native 中，所以需要一个交互过程），因此需要频繁地在 JavaScript 与 Native 之间进行通信，从而会有一定的性能损耗影响，导致体验上与原生会有一些差异。

• Flutter，取长补短，结合了之前的一些优点，解决了与 Native 之间通信的问题，同时也有了自渲染模式（框架自身实现了一套 UI 基础框架，与原来的渲染模式基本一致）。从而在体验和性能上相对之前的两种框架表现都较好，具体是如何做到的，我会在接下来的第 22 课时中详细介绍。

经过上面的技术原理和优缺点对比，Flutter 在各方面都表现出了突出的优势，因此把 Flutter 作为入门大前端的核心框架。

选择Flutter的思考

大前端这个概念从开始到现在已经有整整 10 年时间，那为什么到现在还没有一统江湖呢？其实从我的角度来看，Flutter 也不会创造一统江湖的成果，因为多端或者智能设备的发展终究不会停止，也很难做到统一标准。那为什么我们还要选择 Flutter 来作为大前端核心框架呢？

事实上 Flutter 的确能够为我们解决一些场景问题，节省人力成本，同时不影响用户体验。

选择 Flutter 并不是为了代替 iOS 或者 Android，而是做一个技术互补，比如，Flutter 负责业务功能，而 iOS 和 Android 则负责部分的底层交互提供服务给到 Flutter 应用。Flutter 也是在这两年刚刚兴起的，在应用起步初期还需要部分底层的服务与原生平台进行交互。相信再经过一段时间的发展，Flutter 在这方面会不断地优化和提升，也将能够独立覆盖到更多复杂的业务场景。因此希望你能够明白大前端的概念，以及 Flutter 目前的应用场景。

分析完后，下面对目前的技术团队和未来技术团队进行一个简单分析，也可以认为是一个预测。如图 3 所示。大部分开发者会集中在跨端技术团队中；而另一部分核心技术攻坚则在相应的平台技术端（比如 android 基础技术团队、iOS 基础技术团队或 Web 基础技术团队），为跨端技术团队提供基础技术服务支撑。当然如果跨端技术团队将组件完善并且可通用化，那么跨端技术团队的人员则可以更快地配置组装的方式构建业务功能。

内部分享，请勿转载

本文节选自 拉勾教育Flutter快学快用24讲