flutter版本,flutter版本号规则

Flutter设置APP版本与构建版本

当一个纯Flutter APP开发完成，我们要打包发布到App Store和各大安卓市场，这时候我们需要设置APP的版本号。

站在用户的角度思考问题，与客户深入沟通，找到善右网站设计与善右网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站设计、成都网站制作、企业官网、英文网站、手机端网站、网站推广、国际域名空间、虚拟主机、企业邮箱。业务覆盖善右地区。

如果我们在使用原生iOS或者Android开发的时,我们会在info.plist中设置 version 和 build 或是在build.gradle中设置 versionName 和 versionCode ,他们分别表示APP的版本和构建版本。

但是我们在使用Flutter管理APP版本时，打开 pubspec.yaml 只看到一个 version 字段。这时候我们应该怎么设置APP的 version 和 build 呢？

我们在pub上随便找一个Flutter的组件，例如官方的 camera ,我们可以看到截止目前为止最新的版本为： camera: ^0.5.2+1 。看到这里，我想大家都明白了，Dart采用的是加号式的版本描述方式， + 前面是版本号， + 后面是当前版本的build号。所以我们设置APP的版本号和build次数，在这里设置即可，例如： version: 1.2.0+1 。

当我们新建一个Flutter工程的时候，我们分别使用Xcode和Android Studio打开iOS和Android的工程可以看到，iOS中的 version 和 build 的值分别为 FLUTTER_BUILD_NAME 和 FLUTTER_BUILD_NUMBER ：

同样我们打开Android工程可以看到有如下定义：

事实上，Flutter在编译的时候会生成 ios/Flutter/Generated.xcconfig 和 android/local.properties 文件。这两个文件由Flutter编译自动生成，不可更改。记录了包含SDK路径或者文件路径，版本信息，环境配置（release/debug）等信息。原生工程获取版本信息的变量就定义在这两个文件里面。

为什么Flutter开发APP性能最接近原生，前端程序员请关注

Flutter是谷歌公司推出的跨终端的开发框架，支持Android、iOS和WEB终端。1.0版在2018年12月5日发布，目前的最新版本是1.5，它采用的开发语言是Dart，Dart也是谷歌开发的计算机编程语言，语法类似C，是编译型语言：

hello world例子，打印字符串“Hello World!”：

1、没有桥接层

React Native、Weex等技术都是跨终端的框架，然而性能跟原生App存在很大差距。这是由于它们的工作原理决定的：

React Native、Weex等技术多了一个桥接层，所以界面渲染会慢一些，由于UI渲染非常频繁，想要不卡顿，基本上比较难，性能和用户体验跟原生代码有差距。而这恰恰是Flutter的优势所在：

Dart可以被编译成不同平台的本地代码，让Flutter不通过桥接层直接跟平台通信，自然性能会快一些。

2、编译执行

JavaScript是解释执行的，Dart是编译执行的，性能谁好一目了然。

3、Flutter Engine虚拟机

Flutter是依靠Flutter Engine虚拟机在iOS和Android上运行的，Flutter Engine使用C/C++编写，开发人员通过Flutter框架直接和API在内部进行交互，所以具有输入低延迟和UI渲染高帧速率的特点。除了这特点之外，Flutter还提供了自己的小部件，Flutter小部件是使用从React获取灵感的现代框架构建的。 中心思想是您使用小部件构建UI。

窗口小部件根据其当前配置和状态描述了它们的视图。 当窗口小部件的状态发生更改时，窗口小部件会重建其描述，框架将根据前面的描述进行区分，以确定底层呈现树从一个状态转换到下一个状态所需的最小更改。可以直接在OS平台提供的画布上进行描绘，也就是一些核心类库直接放到虚拟机里面，调用起来更快。

从它的系统结构可以看出，类似安卓的ART(Android Run Time)虚拟机，同样采用AOT(Ahead of TIme)技术，会在APP安装时就编译成机器语言，不再解释执行，从而优化了APP运行的性能。

4、自带渲染引擎

Flutter使用谷歌自己的Skia渲染引擎，而Android系统自带Skia引擎，iOS平台上Flutter也会把Skia引擎打包到APP中，从而实现了高效渲染。而React Native通过桥接层访问原生UI，操作频繁就容易出性能问题。

综合所述，Flutter 是性能最接近原生代码 的一种开发框架，未来也会是构建谷歌Fuchsia应用的主要方式，前途不可限量，唯一的问题就是需要学习一门新的语言：Dart，而有Java或者C#语言基础的程序员会比较容易学习。

Mac--Flutter更换指定版本

类似错误No named parameter with the name ‘XXXXXX‘问题

原因：Flutter版本问题

一、回退到指定版本

1、GitHub搜索flutter 点击进入后，选择tags找到需要的版本点进去，如图：

2、复制版本号

cd  /Users/apple/Documents/flutter    根目录，同bash_profile中PATH配置保持一致即可。

git reset --hard 3595343e20a61ff16d14e8ecc25f364276bb1b8b

执行完成，检测 flutter --version

执行 flutter doctor

????????了

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 开始之后适配启动页的新调整。

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

Flutter 获取App的版本号等信息

通过使用插件 package_info 可以获取到当前APP的包名，版本名，版本号等信息。

修改+号后的构建号，+号前的版本号。

在android和ios原生(ios必须打包)中能发现version变化

要使用这个插件，首先在工程的pubspec.yaml文件中加入对这个插件的依赖：