复杂应用flutter,复杂应用题六年级

Flutter Android端集成排坑 - armeabi 适配 & FlutterBoost

Flutter可以算是当下最火热的新技术之一，我现在所在团队也准备将Flutter技术应用到线上工程中。

关于混合工程，官方文档其实写的已经比较清楚了，按着文档走一般问题不大，

但是有一点值得注意的是，Flutter工程引入的库的gradle的 buildTypes 要与原工程保持一致，如果不一致需要手工添加。

进入正题，现在Flutter官方默认只提供armeabi-v7a、arm64-v8a、x86和x86-64，其中x86和x86-64是为模拟器准备的。目前我们使用的SDK大部分只使用了armeabi架构，直接使用我们会遇见找不到 libflutter.so，libapp.so 的情况，所以我们需要对FlutterSDK做一定的改造。

首先我们要了解下Flutter编译产物，因为不同版本产物是不同的，这里我们只针对Flutter 1.9.1-hotfixes来说。除了资源文件之外，Flutter打包会生成两个非常重要的so库，他们分别是 libflutter.so，libapp.so 。其中 libflutter.so 是Flutter的SDK产物而 libapp.so 正是我们编写的dart文件的产物。默认情况下，这两个文件都会出现在armeabi-v7a中，因此我们要作出对应的改造。

libflutter.so 位于FlutterSDK中，这里顺带提一句，除了这对不同CPU架构，它还分为Debug版和Release版，它们的区别在于Debug是为JIT编译方式打造的，体积较大而Release是为AOT编译方式打造的，体积很小。对 libflutter.so 的改造，只要将其移动文件路径即可，运行以下脚本即可，此脚本来自美团分享的Flutter文章。

移动完了 libflutter.so 之后我们打包发现， libapp.so 仍然会出现在armeabi-v7a中，所以第二部我们就是移动 libapp.so 。这个需要更改 flutter.gradle ，我们在 flutter.gradle 的45行可以看到如下定义，它定义了我们的环境。

在524行我们可以看到，abiValue的取值就是根据上述定义值。

所以结论很简单，只要将

private static final String ARCH_ARM32 = "armeabi-v7a";

改为

private static final String ARCH_ARM32 = "armeabi";

就可以完成对与 libflutter.so 的移动。

前期工作我们都做好了，打成aar就非常简单了

直接使用 flutter build aar --target-platform android-arm

打出来后可以解压检查下 libflutter.so，libapp.so 是否都在armeabi文件夹下即可。

说完了armeabi适配问题，这里下说下有关于有关于FlutterBoost的接入。这个东西接入有两点要注意。

在主app内加上即可，常规操作，强制统一support包的版本号

注释flutter.gradle第655行。因为编译过程中，会去初始化插件项目的buildType下面的debug配置，而插件项目下并未配置debug，导致报错。

如果发现文章中有错误或者有更好的解决方案欢迎指正留言，当然如果本篇文章帮助你解决了问题，也不要吝啬你的感谢。谢谢各位。

相关问答

Q1: Flutter 启动页的前世今生适配历程

APP 启动页在国内是最常见也是必备的场景，其中启动页在 iOS 上算是强制性的要求，其实配置启动页挺简单，因为在 Flutter 里现在只需要：

一般只要配置无误并且图片尺寸匹配，基本上就不会有什么问题， 那既然这样，还有什么需要适配的呢？

事实上大部分时候 iOS 是不会有什么问题， 因为 LaunchScreen.storyboard 的流程本就是 iOS 官方用来做应用启动的过渡；而对于 Andorid 而言，直到 12 之前 windowBackground 这种其实只能算“民间”野路子 ，所以对于 Andorid 来说，这其中就涉及到一个点：

所以下面主要介绍 Flutter 在 Android 上为了这个启动图做了哪些骚操作～

在已经忘记版本的“远古时期” ， FlutterActivity 还在 io.flutter.app.FlutterActivity 路径下的时候，那时启动页的逻辑相对简单，主要是通过 App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 来进行判断。

在 FlutterActivity 内部 FlutterView 被创建的时候，会通过读取 meta-data 来判断是否需要使用 createLaunchView 逻辑 ：

是不是很简单，那就会有人疑问为什么要这样做？我直接配置 Activity 的 android:windowBackground 不就完成了吗？

这就是上面提到的时间差问题， 因为启动页到 Flutter 渲染完第一帧画面中间，会出现概率出现黑屏的情况，所以才需要这个行为来实现过渡 。

经历了“远古时代”之后， FlutterActivity 来到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本发布之前，Flutter 又针对这个启动过程做了不少调整和优化，其中主要就是 SplashScreen 。

自从开始进入 embedding 阶段后， FlutterActivity 主要用于实现了一个叫 Host 的 interface ，其中和我们有关系的就是 provideSplashScreen 。

默认情况下它会从 AndroidManifest 文件里是否配置了 SplashScreenDrawable 来进行判断 。

默认情况下当 AndroidManifest 文件里配置了 SplashScreenDrawable ，那么这个 Drawable 就会在 FlutterActivity 创建 FlutterView 时被构建成 DrawableSplashScreen 。

DrawableSplashScreen 其实就是一个实现了 io.flutter.embedding.android.SplashScreen 接口的类，它的作用就是：

之后 FlutterActivity 内会创建出 FlutterSplashView ，它是个 FrameLayout。

FlutterSplashView 将 FlutterView 和 ImageView 添加到一起， 然后通过 transitionToFlutter 的方法来执行动画，最后动画结束时通过 onTransitionComplete 移除 splashScreenView 。

所以整体逻辑就是：

当然这里也是分状态：

当然这个阶段的 FlutterActivity 也可以通过 override provideSplashScreen 方法来自定义 SplashScreen 。

看到没有，做了这么多其实也就是为了弥补启动页和 Flutter 渲染之间， 另外还有一个优化，叫 NormalTheme 。

通过该配置 NormalTheme ，在 Activity 启动时，就会首先执行 switchLaunchThemeForNormalTheme(); 方法将主题从 LaunchTheme 切换到 NormalTheme 。

大概配置完就是如下样子， 前面分析那么多其实就是为了告诉你，如果出现问题了，你可以从哪个地方去找到对应的点 。

讲了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被弃用了，惊不喜惊喜，意不意外，开不开心 ？

通过源码你会发现，当你设置了 splashScreen 的时候，会看到一个 log 警告：

为什么会弃用？

其实这个提议是在 这个 issue 上，然后通过 这个 pr 完成调整。

大概意思就是： 原本的设计搞复杂了，用 OnPreDrawListener 更精准，而且不需要为了后面 Andorid12 的启动支持做其他兼容，只需要给 FlutterActivity 等类增加接口开关即可 。

也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 来实现延迟直到加载出 Flutter 的第一帧。

为什么说默认情况？ 因为这个行为在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才会被调用，而 RenderMode 又和 BackgroundMode 有关心 。

所以在 2.5 版本后， FlutterActivity 内部创建完 FlutterView 后就会执行一个 delayFirstAndroidViewDraw 的操作。

这里主要注意一个参数： isFlutterUiDisplayed 。

当 Flutter 被完成展示的时候， isFlutterUiDisplayed 就会被设置为 true。

所以当 Flutter 没有执行完成之前， FlutterView 的 onPreDraw 就会一直返回 false ，这也是 Flutter 2.5 开始之后适配启动页的新调整。

看了这么多，大概可以看到其实开源项目的推进并不是一帆风顺的，没有什么是一开始就是最优解，而是经过多方尝试和交流，才有了现在的版本，事实上开源项目里，类似这样的经历数不胜数：

Q2: Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack

大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。

分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter

Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。

在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。

我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。

但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。

在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理

在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。

Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。

TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。

然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。

通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL

在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。

音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM

在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。

在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件

整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。

管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。

模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。

线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。

从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。

基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。

上图为整个功能实现的代码和结构图。

结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划

1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

Q3: 做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

Q4: Flutter真香，我用它写了个桌面版JSON解析工具

Flutter支持稳定的桌面设备开发已经一段时间了，不得不说，Flutter多平台支持的特性真的很香。我本人并没有任何桌面开发的经验，但仍然使用Flutter开发出了一个桌面版小程序，功能很简单，就是对输入的json做格式化处理和转模型。

话不多说，先来看看实际效果。 项目源码地址

开发环境如下：

Flutter : 2.8.1

Dart : 2.15.1

IDE : VSCode

JSON作为我们日常开发工作中经常要打交道的一种数据格式，它共有6种数据类型： null , num , string , object , array , bool 。我们势必对它又爱又恨。爱他因为他作为数据处理的一种格式确实非常方便简洁。但是在我们做Flutter开发中，又需要接触到json解析时，就会感觉非常棘手，因为flutter没有反射，导致json转模型这块需要手写那繁杂的映射关系。就像下面这样子。

数据量少还能接受，一旦量大，那么光手写这个解析方法都能让你怀疑人生。更何况手写还有出错的可能。好在官方有个工具**json_serializable**可以自动生成这块转换代码，也解决了flutter界json转模型的空缺。当然，业界也有专门解析json的网站，可以自动生成dart代码，使用者在生成后复制进项目中即可，也是非常方便的。

本项目以json解析为切入点，和大家一起来看下flutter是如何开发桌面应用的。

要让我们的flutter项目支持桌面设备。我们首先需要修改下flutter的设置。如下，让我们的项目支持 windows 和 macos 系统。

接下来使用 flutter create 命令创建我们的模版工程。

创建完项目后，我们就可以 run 起来了。

先来看下整体界面，界面四块，分别为功能模块、文件选择模块、输入模块、输出模块。

我们在新建一个桌面应用时，默认的模版又一个Appbar，此时应用可以用鼠标拖拽移动，放大缩小，还可以缩到很小。但是，我们一旦去掉这个导航栏，那么窗口就不能用鼠标拖动了，并且我们往往不希望用户将我们的窗口缩放的很小，这会导致页面异常，一些重要信息都展示不全。因此这里需要借助第三方组件 bitsdojo_window 。通过 bitsdojo_window ，我们可以实现窗口的定制化，拖动，最小尺寸，最大尺寸，窗口边框，窗口顶部放大、缩小、关闭的按钮等。

通过 InkWell 组件，可以捕捉到手势、鼠标、触控笔的移动和停留位置

这个功能是鼠标移动后的UI交互界面。要在窗口上显示一个提示框，可以使用 Overlay 。需要注意的是，由于在 Overlay 上的 text 的根结点不是 Material 风格的组件，因此会出现黄色的下划线。因此一定要用 Material 包一下 text 。并且你必须给创建的 OverlayEntry 一个位置，否则它将全屏显示。

读取说表拖拽的文件一开始想尝试使用 InkWell 组件，但是这个组件无法识别拖拽中的鼠标，并且也无法从中拿到文件信息。因此放弃。后来从文章《Flutter-2天写个桌面端APP》中发现一个可读取拖拽文件的组件 desktop_drop ，能满足要求。

使用开源组件 file_picker ，选完图片后的操作和拖拽选择图片后的操作一致。

Textfield 如果要显示富文本，那么需要自定义 TextEditingController 。并重写 buildTextSpan 方法。

在做导出功能时遇到下列报错，保存提示为没有权限访问对应目录下的文件。

通过Apple的开发文档找到有关权限问题的说明。其中有个授权私钥的key为 com.apple.security.files.downloads.read-write ，表示 对用户的下载文件夹的读/写访问权限 。那么，使用Xcode打开Flutter项目中的mac应用，修改工程目录下的 DebugProfile.entitlements 文件，向 entitlements 文件中添加 com.apple.security.files.downloads.read-write ，并将值设置为YES，保存后重启Flutter项目。发现已经可以向下载目录中读写文件了。

当然，这是正常操作。还有个骚操作就是关闭系统的沙盒机制。将 entitlements 文件的 App Sandbox 设置为NO。这样我们就可以访问任意路径了。当然关闭应用的沙盒也就相当于关闭了应用的防护机制，因此这个选项慎用。

原文地址：

Q5: Flutter入门这一篇效率文章就够了

本文面向 Flutter 初学者，旨在用易懂的方式带大家入门。除了 Flutter 代码，还会介绍到语法、原理、特性等基础知识。相信本文能帮助你学习和理解 Flutter。

我们先看一下目前的一些跨平台方案，从前端渲染的角度来分类的话，大致可以分为以下几种方案。

WebView 渲染

这种方案就很好理解，现在很多项目都会嵌入 H5 的页面。就是用 JavaScript 等前端技术进行开发，在客户端上用 WebView 来进行渲染。微信小程序目前使用的就是这种方案。

它的优点很明显，使用成熟的前端技术进行开发，学习成本低，开发效率高，并且支持动态发布代码。

但缺点也很明显，在性能体验上，和原生还是存在较大差距的。

原生控件渲染

既然 WebView 的性能不够好，于是就有了使用原生控件进行渲染的方案。这种方案，同样也是使用 JavaScript 开发，区别是它最终是调用原生控件进行渲染的。这种方案的代表是 Facebook 的 React Native。

由于使用原生控件进行渲染，性能体验也会更接近原生。但也只是更接近，和原生还是有差距的，因为它需要频繁的进行 JavaScript 和原生之间的通信，这个通信效率是比较低的。

另外，由于需要适配各个平台的控件，那就有可能出现，系统控件更新了，而框架本身还没有更新，由此产生了一些问题。换句话说，这种方案是受到原生控件限制的。

绘图引擎渲染

接下来就是主角了。

在前端，如果完全不使用原生控件，我们可以通过系统的绘图 API 绘制出一个用户界面。从这个角度出发，可以在各个平台使用一个统一接口的绘图引擎来进行界面绘制，这个引擎最终调用的是系统的 API 绘制的。这样的话，它的性能可以做到接近原生，并且又不受原生控件的限制，在不同平台上能够做到 UI 统一。

Flutter 就是这样的一个开发框架。

一个跨平台 UI 解决方案

Flutter 是由 Google 开发的，一个跨平台 UI 解决方案。换句话说，它原则上只管 UI 的问题，如果涉及到平台本身的一些功能，比如调用蓝牙、摄像头，一般还是需要原生代码去操作。但现在也会有一些第三方库帮我们解决这些问题。

绘图引擎 Skia

Flutter 使用 Skia 作为它的绘图引擎。Skia 已经被 Google 收购，目前很多 Google 旗下的产品都是用 Skia 绘制的，包括 Android。

Android 内置了 Skia，但 iOS 没有，所以在打 iOS 安装包的时候，会把 Skia 一起打进去。这就导致了，用同一份 Flutter 代码打包之后，iOS 的包要比 Android 的包大一些。

开发语言 Dart

Flutter 使用的开发语言，叫 Dart。Dart 也是 Google 自家的，它是一门面向对象的语言，从它身上会看到一些其他开发语言的影子。学习起来难度不大的。

前面讲跨平台方案的时候，可以发现别的方案基本都是用 JavaScript 作为开发语言的，但为什么 Flutter 不用？就因为 Dart 是谷歌自家的吗？这个问题先留着，我们后面会提到。

这里部分就简单点带过了，具体的搭建流程可以在官网查看:

主要的搭建步骤如下:

下载 Flutter SDK

官网下载地址：

由于在国内访问可能受限，官方为中国开发者搭建了镜像：

更新环境变量

解压后，将 flutter\bin 的全路径添加到环境变量 PATH 中。

安装开发工具

理论上，任何文本编辑器都可以用来开发 Flutter 应用，但推荐的开发工具是 Android Studio、IntelliJ 以及 VS Code。因为在这些开发工具上，可以安装官方的 Flutter 和 Dart 插件，得到更好的开发体验。文章里使用 Android Studio 来演示。

如果你打算开发 iOS 应用，则还需要安装 Xcode。

安装插件

在开发工具的插件设置中，安装上面说到的 Flutter 和 Dart 插件。Flutter 插件用于支持 Flutter 的运行、调试、热重载等功能，而 Dart 插件则提供了代码的输入校验、代码补全等功能。

万物始于 Hello World，我们先来创建一个显示 Hello World 的 Flutter 项目。

在 Android Studio 的欢迎页面选择 Start a new Flutter project ，或者通过菜单栏的 File New New Flutter Project ，创建一个新的 Flutter 项目。

创建好的项目里面包含了 android 和 ios 两个文件夹，它们是标准的 Android 和 iOS 项目。我们的 Flutter 代码，存放在 lib 文件夹里。项目创建好后，会默认带一个计数器的示例，我们不管它，把 main.dart 的代码改成 Hello World:

启动一个模拟器，或者连上真机，点击 Run 运行一下，就能看这样一个界面了：

具体代码先混个眼熟就好，具体的后面会再讲到。

在写 Flutter 之前，还要先跟大家简单介绍一下 Dart 的语法。如果你有 Java 或 JavaScript 的开发经验，以及面向对象的编程思想，学起来是很快的。

我们可以在 test 文件夹下新建一个 dart 文件，用来写测试代码。

指定类型

var

但和 JavaScript 不同的是，以下代码在 JavaScript 是不会报错的，但在 Dart 里会报错：

Object

如果非要上面这样写，那也可以。把 var 换成 Object 就不报错了：

和 Java 类似，Object 是所有对象的根基类。但是这样的话，如果想打印一下 num 的字符串长度，是会报错的：

因为 length 是属于 String 的，但系统只知道 num 是一个对象，并不知道它是一个 String。

dynamic

如果还是非要这样写，那也可以。Dart 有一个特有的关键字 dynamic，把 Object 改成 dynamic 就不报错了：

我们运行一下这个文件，可以在控制台看到正确打印出了字符串长度。

函数

dynamic

在 Dart 里，函数也是可以不写返回类型的，不写的话会被当做 dynamic 来处理。这样的话，函数的类型就是 return 的类型，如果没有 return 则是 void 类型。比如可以这样:

运行之后是能正确打印出字符串长度的。

用于传参

Dart 里的函数也是一个对象，所以可以把函数作为参数来传递，比如：

可选参数

在 Dart 的函数传参里，有一个叫可选参数的概念，我们以文字控件 Text 为例，在源码里可以看到 Text 的构造函数是这样的:

首先，在参数里有一个 data，它是要显示的文字内容，是一个必填项。而 data 后面的一堆参数，是用一个大括号括起来的，这些参数就叫做可选参数，意思是这些参数可传可不传。

假如我们要显示一个比较长的文字，又想限制它最多显示两行，就可以这样来创建一个 Text:

可选参数，在 Flutter 里面用的非常多。

异步

Future

在 Dart 里使用 Future 来处理异步任务，比如我们现在延时一秒打印 666，代码如下：

Future 的语法和 Promise 非常像。任务执行成功会调用 then，执行失败会调用 catchError，而无论成功还是失败，都会调用 whenComplete。

async/await

如果你不喜欢上面那种写法，或者是想把异步转成同步，就可以用 async 和 await 这两个关键字来转换。

我们把上面的代码转换一下，写一个 getString 方法，返回的类型是 Future，它会延时返回一个字符串。在 main 函数后面加上 async 关键字，在 getString() 前面加上 await，代码如下:

运行之后可以看到，能正常延时一秒后，把字符串打印出来。这里 getString() 返回的类型是 Future，而 await getString() 则是返回了延时之后返回的字符串。await 要在 async 的函数里面才能使用。

async 和 await 其实是一个语法糖，它最终也是转换成 Future 调用链的形式执行的。

接下来回到 Flutter，Flutter 里最重要的一个概念是 Widget（下面翻译作控件）。

在原生开发里面，我们可能会在界面上区分，这是一个 View，这是一个 Layout，这是一个 View Controller。但在 Flutter 里面，它们全都属于一个统一的模型 Widget。可以说，在 Flutter 界面里，所有东西都是 Widget。

以前学面向对象的时候，我们都听过一句话，叫万物皆对象。我这里套用一下，在 Flutter 里， 万物皆控件 。

具体有哪些控件，我做了一下简单的分类。

根控件

所有的控件都属于 StatefulWidget 或 StatelessWidget 。它们的区别是，StatefulWidget 拥有状态 State ，而 StatelessWidget 没有。

StatefulWidget

当一个控件是可变的时候，就要使用 StatefulWidget 来构建。StatefulWidget 本身不可变，但它持有的状态 State 是可变的。

StatelessWidget

当一个控件状态是固定不可变的时候，就可以使用 StatelessWidget。前面我们写的 Hello World 就是使用 StatelessWidget。

容器控件

容器类控件一般是将某些属性或配置，作用在它的子控件上，比如控件所在的宽高、背景、位置等。

常用的容器控件有 Container、Center、Padding 等。

布局控件

布局控件可以类比作原生开发中的 Layout，通常它会拥有一个 children 的属性，用于接收一个控件数组，对这些控件进行特定的排版。

常用的布局控件有 Row、Column、Stack、Flex 等。

基础控件

基础控件就是常用的文字、按钮、图片等控件。

常用的基础控件有 Text、TextField、Button、Image 等。

功能控件

在 Flutter 里还有一类控件，它们不影响 UI 布局，但带有一些特定的功能，比如页面跳转、事件监听、定义主题等。我们把这一类控件称作功能控件。

常用的功能控件有 Navigator、NotificationListener、Theme 等。

开始写 Flutter 代码了。还记不记得，在 Flutter 项目创建之后，是自带一个计数器 demo 的，现在我们用自己的代码实现一遍。代码修改成如下：

运行之后，就可以看到这样的界面了：

按钮每点击一次，数字就会加一。下面我们来分析一下这段代码，看下里面用到的一些 Widget。

StatefulWidget

由于页面中的数字是跟随状态变化的，所以该页面改用 StatefulWidget。StatefulWidget 并不会直接返回一个 Widget，而是返回状态 State，在 State 里再返回 Widget。

Scaffold

Scaffold 是一个标准的 Material Design 页面，它包含了标题栏、浮动按钮、侧滑菜单、底部导航栏等配置。我们这里用到了标题栏 appBar、页面内容 body、浮动按钮 floatingActionButton。

AppBar

AppBar 就是标题栏，通过查看控件的构造方法，我们可以知道它可配置的属性。

AppBar 的可选参数除了标题 title，还可以配置标题前的内容 leading，右侧的操作按钮 anctions，控件垂直高度 elevation 等。我们只传了 title，其他属性都用默认值。

Center

Center 是一个容器类控件，它的作用就是让它的子控件居中显示。

FloatingActionButton

熟悉安卓开发的应该对这个控件比较熟悉，它就是页面右下角一个特定样式的 Button，参数里面的 onPressed 是一个必填项，要传一个点击之后的回调函数。

根据这个例子，下面给大家介绍一下 Flutter 两个比较重要的特性。

点击 Button 之后，我们把 num 变量加一，并使用 setState 通知状态发生了改变，Flutter 会根据新的状态更新 UI。如果有接触过小程序开发，setState 就和小程序的 setData 类似。

在 Flutter 里面我们不需要用 set 方法来更新 UI，可变控件是和状态绑定的，这就是 Flutter 的响应式 UI 编程。

在 Android Q 和 iOS 13 里都加入了暗黑模式，我们也换一个暗黑主题来玩一下。MaterialApp 里有一个 theme 的属性，我们把它配置一下:

这次改完之后不点 Run 了，我们点一下闪电图标 Flutter Hot Reload ，就能看到界面发生了变化:

这就是 Flutter 的 热重载 ，在修改完代码之后，通过热重载就能马上在设备上看到修改结果，可以很大程度上增加开发效率。

下面再给大家介绍几个 Flutter 里的常见操作。

在 Flutter 里，使用 Navigator 来管理页面跳转，比如要跳转到一个 NewPage 可以这样写:

进栈使用 push，出栈则是 pop。

使用 MaterialPageRoute 会模拟出 Android 上页面跳转的过场效果。

我们来看看怎么显示一张本地图片。

先在根目录新建一个存放图片的文件夹，比如叫 images，把图片 picture.png 放进去。

找到根目录下的 pubspec.yaml 文件，这个便是 Flutter 依赖配置文件，我们需要在这里配置一下刚才的图片：

这样，我们就能使用 Image 控件把这张图片显示出来了：

和 node 的 npm 以及 Android 的 jcenter 类似，Flutter 也拥有一个公共仓库 pub.dev。pub.dev 是 Google 官方的 Dart 仓库，在上面可以找到我们需要的包和插件。

Flutter 本身没有 Toast，我们来接入一个。在 pub.dev 上搜索后，我决定使用 fluttertoast：

按照说明，在 pubspec.yaml 文件里的 dependencies 下配置：

点一下 Android Studio 右上角的 Packages get 同步之后就可以使用了：

我们上面使用的都是 Material Design 的控件，它们都是在 flutter/material.dart 包里面的。如果要使用 iOS 风格的控件，则要用到 flutter/cupertino.dart 包：

iOS 风格的控件，基本都以 Cupertino 开头。我们把计时器页面里的控件替换一下：

效果如下：

代码的部分就到这里了，接下来跟大家聊一下编译方式，编程语言的编译方式有两种。

关于它们孰优孰劣，就要看从哪个角度去对比了。JIT 的话，它的一大特点就是支持动态发布代码，也就是支持热更新。但要是从性能的角度考虑，AOT 会更好，因为在运行的时候不用再进行编译的操作的，运行的效率会更高一些。

回到我们一开始的时候留下的问题，为什么别的跨平台方案都是用 JavaScript，而 Flutter 要用 Dart 来开发。JavaScript 的编译方式是 JIT 的，它不支持 AOT。而 Dart 同时支持 JIT 和 AOT。

Flutter 在开发阶段使用 JIT，让我们用上了热重载，增加了开发效率。在打包时改用 AOT，保证了正式版应用的性能。

最后讲一下大家比较关心的一个东西，Flutter 是否支持热更新？前面说到 Dart 支持 JIT，所以从技术层面它是支持的。但是目前是不支持的，在官方的计划文档中，可以看到:

至于原因，官方在这里进行了说明。总的来说，是由于政策的限制，以及出于对性能和安全性的考虑，暂时不支持了。

到这就结束啦。由于想把 Flutter 基础在一篇内讲完，没有涉及太多细节，如果要写 Flutter 代码还需要深入学习。但相信理解之后再学，会轻松很多。