关于flutter:Flutter-28-更新详解

北半球的冬意已至，黄叶与气温均随风而落。年初的最初一个 Flutter 稳固版本已悄悄来到你的背后。让咱们向 Flutter 2.8 打声招呼～

本次更新蕴含了 207 位贡献者和 178 位审核者 的辛勤劳作，所有人独特产出了 2424 个 PR，敞开了 2976 个 issue。在此特别感谢本次公布中最突出的社区贡献者: 来自 VGV 的 Flutter 开发工程师 Bartosz Selwesiuk，他为 Web 平台的 camera 插件并提交了 23 个 PR。

以上的所有产出让 Flutter 引擎和开发者工具 (DevTools) 都有了十分显著的性能晋升，同时带来的还有 Google 挪动端广告 SDK Flutter 版本的稳定版公布、一系列针对 Firebase 的新性能和优化、Flutter WebView 3.0、新的 Flutter Favorite package、向桌面端稳定版迈出的一大步，以及反对更多 package 的新版 DartPad。让咱们一起来看看吧！

Flutter 的首要指标是判若两人地保障其品质。咱们破费了大量工夫以确保 Flutter 在多种多样的设施上都能流畅且稳固地运行。

本次更新优化了利用启动的提早。咱们在领有一百万行以上的代码量的 GPay 利用上进行了测试，以确保改变在理论生产的利用上无效。这些改变 将 GPay 在低端 Android 设施上启动的工夫缩小了约 50%、高端设施上缩小了约 10%。

咱们对 Flutter 调用 Dart VM 的 GC 策略也做了一些改良，以此防止在程序启动期间呈现不合时宜的 GC。例如，在 Android 设施上渲染出第一帧前，Flutter 仅在 TRIM_LEVEL_RUNNING_CRITYCAL 及高于其等级的信号呈现时，告诉 Dart VM 有内存压力。在本地测试中，低端 Android 设施的初始帧呈现间隔时间最多缩小了约 300ms。

在先前的 Flutter 版本中，出于审慎思考，在创立 PlatformView 时会阻塞平台线程。在通过认真的推理和测试后，咱们删除了局部序列化的步骤，使得 GPay 在低端设施上的启动工夫至多缩小了 100ms。

长久以来，在初始化首个 Dart isolate 前初始化默认的字体管理器会引入人为的提早。因为它是首要的提早瓶颈，所以将默认字体管理器的初始化提早到与首个 Dart isolate 同时运行，升高了启动的提早，并让上述的所有启动优化的体现更加显著。

因为 Flutter 会尽可能快地加载 Dart VM 的服务 isolate，并将其和绑定在利用内的 AOT 代码一并加载到内存中，这会导致 Flutter 开发人员在局部内存有限度的设施上难以追踪内存指标。在 Flutter 2.8 版本中，Android 设施上 Dart VM 的服务 isolate 已被拆分至独自的 bundle 中，能够独自加载，缩小了在其加载前约 40MB 的内存应用。本来 Dart VM 向操作系统发送 AOT 程序的内存用量的告诉，已转由一个无需屡次读取的文件反对，后续的内存占用量进一步缩小了约 10%。因而，先前保留了文件数据拷贝的内存能够回收并用于其余用处。

某些场景下，开发者心愿能同时看到 Flutter 和 Android 的性能追踪事件，又或者是在生产模式下查看追踪事件来更好地理解利用的性能问题。为了这一需要，Flutter 2.8 当初能够抉择在利用启动后，将性能追踪事件发送至 Android 的事件记录器，在生产模式下也同样如此。

此外，一些开发人员想要更多的对于光栅缓存行为的性能跟踪信息，以缩小制作动画成果时的卡顿，这容许 Flutter 疾速地对低廉的、重复使用的图片进行复用而不是从新绘制。性能跟踪中的新的 流事件 让开发人员能够跟踪光栅缓存图片的生命周期。

对于调试性能问题，新版的开发者工具 (DevTools) 增加了一个新的「加强跟踪」性能，用来帮忙开发者诊断耗费较大的构建、布局和绘制操作引起的 UI 卡顿。

启用任何一个追踪性能后，时间轴中将视状况展现 Widget 的构建、RenderObject 布局和 RenderObject 绘制的事件。

此外，新版的开发者工具也减少了利用启动性能的剖析反对。该配置文件蕴含了从 Dart VM 初始化到第一帧 Flutter 渲染的 CPU 样本。在你按下「Profile app start up」按钮并加载利用启动配置文件后，你将看到为配置文件抉择了「AppStartUp」标签。你还能够通过在可用用户标签列表中抉择此用户标签过滤器（如果存在）来加载利用启动配置文件。抉择此标签会显示你的利用启动的个人资料数据。

不仅仅是 Android 和 iOS 平台取得了性能晋升，本次公布同时蕴含了对 Flutter Web 平台视图的性能优化。平台视图是从宿主平台向 Flutter 嵌入 UI 组件的媒介。Flutter Web 应用 HtmlElementView widget 实现了这一性能，让你能在 Flutter Web 利用中嵌入 HTML 元素。如果你正在应用 google_maps_flutter 插件或 video_player 插件的 Web 版本，或者你正在遵循 Flutter 团队对于如何优化网络上显示图像的倡议，那阐明你曾经在应用平台视图了。

在之前版本的 Flutter 中，嵌入平台视图会创立一个新的 canvas，每嵌入一个平台视图都会新增一个 canvas。
创立额定的 canvas 是非常耗费性能的操作，因为每个 canvas 的大小都与整个窗口相等。在 Flutter 2.8 中，将复用为先前的平台视图创立的 canvas。因而，你不会在利用的整个生命周期内产生每秒 60 倍的老本，而是只有一次创立的老本。这意味着你能够在 Web 利用中领有多个 HtmlElementView 实例而不会升高性能，同时还能够缩小应用平台视图时的滚动卡顿。

Flutter 不仅仅是框架、引擎和工具——pub.dev 上现有超过 2w 个与 Flutter 兼容的包和插件，而且每天都在减少。Flutter 开发人员大量的日常操作也是宏大的生态系统的一部分，所以让咱们来看看自上一个版本以来 Flutter 生态系统中有什么扭转。

首先也是最重要的是，Google Mobile SDK for Flutter 已于 11 月正式公布。此版本反对 5 种广告格局，集成了 AdMob 和 Ad Manager 反对，并蕴含一个新的直达性能的测试版，能够帮忙你优化广告展示的成果。无关将 Google Ads 集成到 Flutter 利用以及其余货币化选项的更多信息，请查看 Flutter 网站上的页面。

这次 Flutter 附带的另一个新版本是 webview_flutter 插件的 3.0 版本。因为新性能的数量减少，咱们晋升了次要版本号，但也因为 Web 视图在 Android 上的工作形式可能产生了重大变动。在之前的 webview_flutter 版本中，Hybrid composition 曾经可用，但不是默认的。而当初它修复了先前默认以虚构显示模式运行的许多问题。
依据用户反馈和咱们的问题跟踪，咱们认为是时候让 Hybrid composition 成为默认设置了。此外，webview_flutter 还减少了一些呼声极高的性能:

反对应用 POST 和 GET 来加载内容
加载文件或字符串内容为 HTML
反对通明背景
在加载内容前设置 Cookies

此外，在 3.0 版本中，webview_flutter 为新平台提供了初步反对: Flutter Web。曾经有很多人要求可能在 Flutter Web 利用中托管 Web 视图，这容许开发者利用单个源代码库构建挪动或 Web 利用。在 Flutter Web 利用中托管 Web 视图是什么样的？从编写代码的角度来看，其实是一样的:

import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';
import 'package:webview_flutter_web/webview_flutter_web.dart';

void main() {runApp(const MaterialApp(home: HomePage()));
}

class HomePage extends StatefulWidget {const HomePage({Key? key}) : super(key: key);

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  @override
  void initState() {super.initState();

    // required while web support is in preview
    if (kIsWeb) WebView.platform = WebWebViewPlatform();}

  @override
  Widget build(BuildContext context) => Scaffold(appBar: AppBar(title: const Text('Flutter WebView example')),
    body: const WebView(initialUrl: 'https://flutter.dev'),
  ;
}

在 Flutter Web 上运行时，它会按你的预期工作:

请留神，以后 webview_flutter 的 web 实现有许多限度，因为它是应用 iframe 构建的，
iframe 仅反对简略的 URL 加载，无法控制加载的内容或与加载的内容交互。
然而，因为需要呼声太高，咱们决定将 webview_flutter_web 作为未经认可的插件提供。
如果你想尝试一下，请将以下内容增加到你的 pubspec.yaml 中:

dependencies:
  webview_flutter: ^3.0.0
  webview_flutter_web: ^0.1.0 # 显式依赖未经认可的插件

如果你对 webview_flutter v3.0 有任何反馈，无论是否是对于 Web 平台，请将问题提交到 Flutter 仓库中。此外，如果你之前没有应用过 webview 或者想温习一下，请查看新的 webview codelab，它将带你逐渐实现在 Flutter 利用中托管 Web 内容的过程。

Flutter 生态系统委员会再次召开会议，将以下 package 指定为 Flutter Favorite 的 package:

新路由 API (又名 Navigator 2) 的三个自定义路由 package: beamer、routemaster 和 go_router；
drift: 对 Flutter 和 Dart 曾经功能强大且风行的响应式持久性库的重命名，基于 sqlite 构建；
freezed: 一个 Dart「语言补丁」，为定义模型、克隆对象、模式匹配等提供简略的语法；
dart_code_metrics: 一个帮忙您剖析和进步代码品质的动态剖析工具；
以及有着丑陋界面的 package: flex_color_scheme、flutter_svg、feedback、toggle_switch 和 auto_size_text。

恭喜这些 package 的作者，并感激你通过你的辛勤工作反对 Flutter 社区。如果你有趣味提名你最喜爱的 Flutter package 退出 Flutter Favorite 嘉奖，请依照 Flutter Favorite 打算页面上的指南和阐明进行操作。

如果你是 package / 插件作者，你须要申明和实现反对哪些平台。如果你正在应用特定于平台的原生代码构建插件，你能够应用我的项目 pubspec.yaml 中的 pluginClass 属性
来实现，该属性将指定提供原生性能的原生类名:

flutter:
  plugin:
    platforms:
      android:
        package: com.example.hello
        pluginClass: HelloPlugin
      ios:
        pluginClass: HelloPlugin

然而，随着 Dart FFI 变得更加成熟，有可能应用 100% 的 Dart 实现特定平台的性能，就像 path_provider_windows package 所做的那样。在这种状况下，你没有任何本地类能够应用，但你依然心愿将你的插件指定为仅反对某些平台。此时你能够改用 dartPluginClass 属性:

flutter:
  plugin:
    implements: hello
    platforms:
      windows:
        dartPluginClass: HelloPluginWindows

通过这样的设置后，即便你没有任何本机代码，也能够为特定平台定制插件。你还必须提供 Dart 插件的类，无关具体内容，你能够在 Flutter 文档上浏览 Dart 平台实现文档以理解更多。

Flutter 生态中另一个重要组成是 FlutterFire，大概有三分之二的 Flutter 利用都在应用它。这次稳定版减少了一系列新的性能，不便开发者们更好的在 Flutter 里应用 Firebase:

所有 FlutterFire 插件都从测试版毕业，「成长」为稳定版
DartPad 开始反对局部 Firebase 服务，不便线上应用和体验
更不便构建认证和在实时查问 Firestore 数据的 UI 界面
Flutter 中应用 Firestore Object/Document 映射的反对进入 Alpha 版

The FlutterFire plugins 简直曾经全副从测试版转为文稳定版，可用于生产环境。

Android、iOS 和网页版的插件已转为稳定版，包含 Analytics、Dynamic Links、In-App Messaging、Performance Monitoring、Realtime Database、Remote Config 和 Installations。有些 Firebase 库自身在局部平台上仍处于测试阶段，所以它的 Flutter 插件也会是测试版状态，比方 App Check 在 macOS 平台。但相似实时数据库 (Realtime Database)、剖析 (Analytics)、近程配置 (Remote Config) 等 FlutterFire 插件曾经在生产环境中可用了，能够抉择试试看！

因为这些 package 曾经达到生产品质，当初你只用在 Dart 代码中配置，就能够实现 Firebase 的初始化了。

import 'package:firebase_core/firebase_core.dart';
import 'firebase_options.dart'; // generated via `flutterfire` CLI

Future<void> main() async {
  // initialize firebase across all supported platforms
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);

  runApp(MyApp());
}

在 firebase_options.dart 文件中定义的各种配置信息，就能够在抉择的每个反对的平台里初始化 Firebase:

static const FirebaseOptions web = FirebaseOptions(
  apiKey: 'AIzaSyCZFKryCEiKhD0JMPeq_weJguspf09h7Cg',
  appId: '1:111079797892:web:b9195888086158195ffed1',
  messagingSenderId: '111079797892',
  projectId: 'flutterfire-fun',
  authDomain: 'flutterfire-fun.firebaseapp.com',
  storageBucket: 'flutterfire-fun.appspot.com',
  measurementId: 'G-K029Y6KJDX',
);

如果你想为每个平台的初始化自定义数据结构的话，请应用这个 flutterfire 命令行工具实现:

这个命令行工具会从每个平台的子文件夹中找到惟一的 bundle ID，进而用它来查找以及创立匹配的特定平台下的 Firebase 工程详情。这意味着你将省去下载 .json文件到 Android 工程、下载 .plist 文件到 iOS 和 macOS 工程的工夫了，当然，也无需再复制粘贴代码到你的 Web 工程了。换句话说，无论你的利用要为哪些平台初始化 Firebase，这句代码都能够帮你做到。当然，这也可能不是惟一一处初始化代码的中央，比方你须要在 Android 或 iOS 中创立 Crashlytics 调试符号 (dSYM) 的时候。但至多能够针对新的 Firebase 工程可能疾速跑起来。

因为咱们能够只在 Dart 代码中初始化并应用 FlutterFire，那 DartPad 天然也就反对应用 Firebase 啦:

这里有一个应用 Flutter 和 Firebase 构建的在线聊天的演示，所有这些都能够在 DartPad 中间接应用而无需装置任何内容。DartPad 对 Firebase 的反对曾经包含了外围 API、身份验证和 Firestore，随着工夫的推动，将来 DartPad 会反对更多 Firebase 服务。

另一个反对是在 FlutterFire 文档中间接内嵌了 DartPad 实例，比方 Firestore 的示例页面:

在这个示例中，你将看到 Cloud Firestore 的文档以及示例利用的代码，并且能够在浏览器中间接运行和编辑，无需装置任何软件。

大多数用户都有身份验证的流程，包含但不仅限于通过邮箱和明码或者第三方账号登陆等。应用 Firebase 身份认证 (Authentication) 服务，你就能够实现创立新用户、邮箱认证、重置明码，甚至是短信两步验证、应用手机号码登录、将多个账号合并为一个账号等性能。直到明天，开发者们仍须要自行来实现这些逻辑和 UI。

明天咱们很心愿大家尝试一个新的 package，名为 flutterfire_ui。这个 package 能够用大量的代码构建一个根本的身份验证体验，例如，在 Firebase 我的项目中设置了应用邮箱和 Google 账号登陆:

通过这个配置你能够通过上面的代码构建一个身份验证:

import 'package:flutter/material.dart';
import 'package:firebase_core/firebase_core.dart';
import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutterfire_ui/auth.dart';
import 'firebase_options.dart';

Future<void> main() async {WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);
  runApp(MyApp());
}

class MyApp extends StatelessWidget {const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) => MaterialApp(home: AuthenticationGate(),
      );
}

class AuthenticationGate extends StatelessWidget {const AuthenticationGate({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) => StreamBuilder<User?>(stream: FirebaseAuth.instance.authStateChanges(),
        builder: (context, snapshot) {
          // User is not signed in - show a sign-in screen
          if (!snapshot.hasData) {
            return SignInScreen(
              providerConfigs: [EmailProviderConfiguration(),
                GoogleProviderConfiguration(clientId: 'xxxx-xxxx.apps.googleusercontent.com',),
              ],
            );
          }

          return HomePage(); // show your app’s home page after login},
      );
}

这段代码将首先初始化 Firebase，而后会发现用户尚未登陆进而显示登录界面，SigninScreen widget 配置了邮件和 Google 账号登陆，代码里还应用了 firebase_auth package 来监测用户的身份验证状态，因而一旦用户登录实现，你就能够显示接下来的利用内容。应用这个代码片段，你将能够在所有 Firebase 反对的平台上实现身份验证性能。

再退出一些其余配置的话，你还能够增加一些图像和自定义文本 (详情见本文档)，从而为你提供更全面的用户身份验证体验:

下面这个截图是挪动端的身份认证，不过因为 flutterfire_ui 的 UI 是响应性设计，因而在桌面浏览器上，它会是这样的成果:

用户能够应用邮箱地址和明码间接实现登陆，如果他们抉择应用通过谷歌身份验证登陆，不论是在挪动端、Web 端还是桌面端，则将会看到常见的 Google 身份验证流程。如果用户还没有账户，他们能够点击注册按钮进入注册流程。用户登陆之后就会有电子邮件验证、明码重置、登出以及社交账户绑定性能。通过电子邮件和明码的身份验证实用于所有平台，并反对应用 Google、Facebook 和 Twitter 账号登陆，以及在 iOS 零碎上反对通过 Apple ID 登陆。flutterfire_ui 的身份认证反对多种场景和导航计划以及自定义和本地化选项等。查看 FlutterFire UI 的文档理解更多。

此外，身份认证不是 flutterfire_ui 惟一反对的 Flutter UI 的相干性能。它还能够向用户展现一个来自 Firebase 数据查问并有限滚动的数据列表，这个版本也蕴含了一个 FirestoreListView 能够应用:

class UserListView extends StatelessWidget {UserListView({Key? key}) : super(key: key);

  // live Firestore query
  final usersCollection = FirebaseFirestore.instance.collection('users');

  @override
  Widget build(BuildContext context) => Scaffold(appBar: AppBar(title: const Text('Contacts')),
        body: FirestoreListView<Map>(
          query: usersCollection,
          pageSize: 15,
          primary: true,
          padding: const EdgeInsets.all(8),
          itemBuilder: (context, snapshot) {final user = snapshot.data();

            return Column(
              children: [
                Row(
                  children: [
                    CircleAvatar(child: Text((user['firstName'] ?? 'Unknown')[0]),
                    ),
                    const SizedBox(width: 8),
                    Column(
                      crossAxisAlignment: CrossAxisAlignment.start,
                      mainAxisAlignment: MainAxisAlignment.center,
                      mainAxisSize: MainAxisSize.min,
                      children: [
                        Text('${user['firstName'] ??'unknown'}'
                          '${user['lastName'] ??'unknown'}',
                          style: Theme.of(context).textTheme.subtitle1,
                        ),
                        Text(user['number'] ?? 'unknown',
                          style: Theme.of(context).textTheme.caption,
                        ),
                      ],
                    ),
                  ],
                ),
                const Divider(),],
            );
          },
        ),
      );
}

理论的运行成果如下:

或者你想为用户提供对表格数据的增删改查性能，你能够应用 FirestoreDataTable:

class FirestoreTableStory extends StatelessWidget {FirestoreTableStory({Key? key}) : super(key: key);

  // live Firestore query
  final usersCollection = FirebaseFirestore.instance.collection('users');

  @override
  Widget build(BuildContext context) {
    return FirestoreDataTable(
      query: usersCollection,
      columnLabels: const {'firstName': Text('First name'),
        'lastName': Text('Last name'),
        'prefix': Text('Prefix'),
        'userName': Text('User name'),
        'email': Text('Email'),
        'number': Text('Phone number'),
        'streetName': Text('Street name'),
        'city': Text('City'),
        'zipCode': Text('Zip code'),
        'country': Text('Country'),
      },
    );
  }
}

成果是这样的:

无关身份验证、列表视图和数据表的更多信息，请查阅 flutterfire_ui 文档。这个 package 仍处于预览状态，可能会退出更多新的个性，如果你有任何应用的问题或者新的个性需要，请在 GitHub repo 里参加咱们的探讨。

咱们同时公布了 Firestore 对象 / 文档映射 (ODM) 的 Alpha 版本，Firestore ODM 的指标是让开发者更高效的通过类型平安、结构化对象和办法来简化 Firestore 的应用。通过生成代码，你能够以类型平安的形式对数据进行建模，从而改良与文档和汇合交互的语法：

@JsonSerializable()
class Person {Person({required this.name, required this.age});

  final String name;
  final int age;
}

@Collection<Person>(‘/persons’)
final personsRef = PersonCollectionReference();

有了这些类型，你能够执行类型平安的查问:

personsRef.whereName(isEqualTo: 'Bob');
personsRef.whereAge(isGreaterThan: 42);

ODM 还反对强类型子集合，也提供了一些内置、优化过的 widget 来重建其 select 性能，你能够在 Firestore ODM 文档中浏览相干内容。因为这个还是 Alpha 版本，请尽可能在 GitHub repo 里向咱们提出反馈。

Flutter 2.8 版本在 Windows、macOS 和 Linux 稳固版本的路线上又迈出了一大步。
咱们的指标质量标准很高，包含国际化和本地化反对，例如新的中文输入法反对、韩语输入法反对以及刚刚合并的 Kanji（日文）输入法反对。或者，就像咱们在严密构建 Windows 辅助性能的反对一样。
对于 Flutter 来说，在稳定版渠道的桌面端上“运行”是不够的，它必须在世界各地的语言和文化以及不同能力的设施上运行良好。咱们还没有达到咱们想要的指标，但将来可期！

其中一个例子是咱们重构了 Flutter 解决键盘事件以容许同步响应的架构。这使 widget 可能解决按键并拦挡它在整个 widget tree 中的其余部分中的传递。咱们在 Flutter 2.5 中实现了这项工作的落地，并在 Flutter 2.8 中修复了许多问题。这是对咱们如何解决特定于设施的键盘输入的形式的从新设计，以及和重构 Flutter 解决文本编辑形式的继续工作的补充，所有这些都是用键盘这样输出密集型的桌面利用所必须的。

此外，咱们还在持续向 Flutter 扩大视觉密度的定义，裸露对话框对齐形式的设置，以便开发者能够实现更加敌对的桌面 UI。

最初，Flutter 团队并不是惟一一个在为了 Flutter desktop 付出心血的团队。举个例子，Canonical 的桌面团队正在与 Invertase 单干，在 Linux 和 Windows 上开发最风行的 Flutter Firebase 插件。

你能够在 Invertase 博客上浏览无关预览版的更多信息。

如果没有工具的改良，那么这个 Flutter 新版本的公布是不残缺的。咱们将重点介绍 DartPad 的改良，其中最大的改良是对更多软件包的反对。事实上，目前共有 23 个 package 可供导入应用。除了几个 Firebase 服务之外，该列表还包含诸如 bloc、characters、collection、google_fonts 和 flutter_riverpod 等风行的 package。
DartPad 团队会持续增加新的 package，如果你想查看以后反对哪些 package 的话，能够单击右下角的信息图标。

如果你想理解将来咱们向 DartPad 增加新 package 的打算，请查看 Dart wiki 上的这篇文章。
还有另一个新的 DartPad 性能也十分不便，在此之前，DartPad 总是以运行最新的稳固版本运行。在新版本中，你能够应用状态栏中新的 Channel 菜单 来切换到应用最新的 Beta 渠道版本以及先前稳固版本 (咱们称为 “old channel” 旧渠道)。

DartPad 里旧渠道的应用场景比方你正在撰写一篇博客文章，而最新的稳固版本还是特地风行，那这将十分有用。

Flutter 的公布「渠道」(也就是 channel) 决定了 Flutter 框架和引擎在你的开发机器上变动的速度，stable 代表起码的变更，而 master 代表最多。因为资源无限，咱们决定最近将进行更新 dev 渠道。尽管咱们的确收到了一些对于 dev 渠道的问题，但咱们发现只有不到 3% 的 Flutter 开发人员应用 dev 渠道，因而，咱们决定 不久将正式停用 dev 渠道。

因为尽管很少有开发人员应用 dev 渠道，但 Flutter 工程师仍须要破费大量工夫和精力来保护它。
如果你根本都只应用 stable 渠道的 Flutter 版本 (超过 90% 的 Flutter 者都在这么做)，那么这项改变将不会影响你的日常开发。通过放弃保护这个渠道，开发者们也能够少做一个渠道抉择的决定，同时 Flutter 团队也能够将工夫和精力花在其余事件上。你能够应用 flutter channel 命令来决定你想要哪个渠道。以下是 Flutter 团队对每个渠道的打算:

Stable 渠道: 代表咱们领有的最高品质的构建。它们每季度（大抵）公布一次，并针对两头的关键问题进行热修复。这是「慢」通道: 平安、成熟、长期服务；
Beta 渠道: 为那些习惯于更快节奏的开发者提供一种疾速调整的代替计划。目前每月公布，稳固测试后会公布。这是一个「疾速」通道，如果咱们发现 dev 渠道相较于 beta 渠道有特地的需要和需要而 beta 渠道无奈满足，咱们可能会扭转 beta 渠道的打算来满足 (比方，减速公布节奏或升高咱们对该渠道执行的测试和热修复级别)；
Master 渠道: 是咱们沉闷的开发渠道。咱们不提供对该渠道的反对，但咱们针对它运行了一套全面的单元测试。对于对不稳固的构建感到称心的贡献者或高级开发者而言，这是适宜他们的渠道。在这个频道上，咱们跑得很快，突破了一些货色 (而后会很快地修复它们)。

当咱们在将来几个月停用 dev 渠道时，请思考应用 beta 或 master 渠道，这取决于你对变更的容忍度以及对应用「最新」还是「最好」的平衡点。

与平常一样，咱们致力缩小每个版本中破坏性更改的数量。在此版本中，Flutter 2.8 除了已过期并依据咱们的破坏性改变政策被删除的已弃用 API 之外，没有重大变更。

90292 移除已废除的 autovalidate
90293 移除已废除的 FloatingHeaderSnapConfiguration.vsync
90294 移除已废除的 AndroidViewController.id
90295 移除已废除的 BottomNavigationBarItem.title
90296 移除已废除的文本输出格式化类

如果你仍在应用这些 API 并想理解如何迁徙代码，你能够浏览 Flutter 文档网站上的迁徙指南。
与平常一样，非常感谢社区奉献的测试用例，帮忙咱们辨认这些破坏性改变。

在咱们完结 2021 年并瞻望 2022 年之际，Flutter 团队要对整个 Flutter 社区的工作和反对表示感谢。诚然，咱们正在为世界上越来越多的开发人员构建 Flutter，但如果没有你和每位开发者的存在，咱们也无奈保护并构建它。Flutter 社区不同凡响，感激你所做的所有！

关于flutter:Flutter-28-更新详解

性能晋升

利用启动性能

利用内存

性能剖析

Flutter 开发者工具

Web 平台的平台视图 (PlatformView)

生态

实用于 Flutter 广告的 Google 广告

WebView 3.0

Flutter Favorites 我的项目

特定平台的插件

Firebase 相干的更新

生产品质

Firebase 初始化仅需在 Dart 代码中配置即可

在 DartPad 中应用 Firebase

Firebase 用户界面

Firestore Object/Document 映射 (ODM)

桌面平台更新

DartPad

移除 Dev 渠道

破坏性改变 (breaking changes)

总结