模块化设计，迎接模块化未来 --- Flutter 解耦 Material 和 Cupertino，以实现更大的自由和更好的性能
Flutter UI 架构的一次里程碑式变革
##a 引言
终于，这件事发生了！Flutter 长期以来将 Material 和 Cupertino 这两大设计系统融合在一起的模式，正在向一个更模块化、更具弹性的新范式演进。Flutter 团队正式宣布，将 Material 和 Cupertino 分离为独立的软件包。这次重大的架构调整不仅是一次技术上的重构，更标志着 Flutter 生态系统进入了一个关键时刻，它将带来更整洁的代码库、更快的开发速度，以及更具针对性的 UI 创新。
在这篇文章中，我们将深入探讨这次转变的"是什么"、"为什么"和"如何做"，剖析它对开发者们的影响，并提供一份指南，帮助你的应用适应 Flutter UI 的未来。无论你是经验丰富的 Flutter 开发者，还是刚刚入门的新手，这次更新都将直接影响你的工作流程。
1. 当前状况：Material + Cupertino 都在 flutter 包里
到目前为止，Flutter 一直将 Material 和 Cupertino 紧密地捆绑在核心的 flutter 包中。你需要通过 package:flutter/material.dart 导入 Material Design，通过 package:flutter/cupertino.dart 导入 iOS 风格的 Widget。即便你只是想构建一个完全自定义的 UI 或一个平台特定的 UI，这两个系统都会被一同打包到你的应用中。
旧方法的优点
- 可以轻松访问两个系统
- 一个导入语句搞定一切
- 快速原型开发，跨平台效果一致
旧方法的缺点
- 增加了应用体积，因为打包了未使用的 Widget
- 依赖臃肿，耦合度高
- 拖慢了任一设计系统的创新和更新速度
- 没有清晰的职责分离
多年来，社区一直呼吁更强的模块化，现在，这个愿望终于变成了现实。
2. 为什么这次改变是必要的
随着 Flutter 的成熟，对灵活性、性能和可维护性的需求也随之增长。这就是 Flutter 团队决定将 Material 和 Cupertino 分离成独立软件包的原因：
- 更好的模块化 更小、更具针对性的软件包能让只需要其中一个系统的团队进行更快的迭代，并减少开销。
- 性能优化 只使用一个设计系统的应用，将无需捆绑另一个，从而使得构建包更小，编译时间更短。
- 设计系统独立性 许多开发者创建的自定义 UI 系统，并不完全符合 Material 或 Cupertino。这次改变能让他们更容易地从头开始构建自己的系统。
- 改进维护方式 通过解耦软件包，Flutter 的贡献者可以独立地更新和演进每一个设计系统。
- 赋能社区 这一举动为社区驱动的 UI 系统打开了大门，现在它们可以更容易地被构建和采纳。
3. 这对开发者意味着什么
影响是巨大的------但大部分都是积极的。以下是你将要面对的变化：
✅ 应用更小 只使用 Material 或 Cupertino 的应用，打包后会更轻量。
✅ 导入更清晰 当你只需要一种设计语言时，不再需要臃肿的导入语句。
✅ 更快的热重载和开发周期 通过分离依赖，构建和重载会更快。
✅ 自定义 UI 开发者欢呼吧 设计一个全新的 Widget 库？你将不再受 Material/Cupertino 的包袱所累。
❗ 破坏性变更 是的，会有一个过渡期。你需要修改你的 pubspec.yaml 文件中的导入和依赖项。
4. 软件包将如何组织
尽管细节还在不断完善，但我们对新结构已有了一些了解：
material：将存在于一个独立的软件包中 (package:flutter_material/flutter_material.dart或类似名称)cupertino：将被解耦到package:flutter_cupertino/flutter_cupertino.dart中flutter_core：一个新的核心软件包将包含Widget、BuildContext、StatefulWidget等基础元素。
依赖层级结构（提案）
flutter_core
└── flutter_material
└── flutter_cupertino这种解耦模式，允许你只使用核心包，然后从零开始构建你自己的设计系统。
5. 如何迁移你的现有应用
你暂时不必担心。Flutter 团队可能会在一段时间内支持当前的单一结构。然而，未来的更新可能会鼓励你进行迁移。
分步迁移（预期流程）：
- 替换导入语句
dart
// 以前
import 'package:flutter/material.dart';
dart
// 以后
import 'package:flutter_core/flutter_core.dart';
import 'package:flutter_material/flutter_material.dart';- 更新 pubspec.yaml
yaml
dependencies:
flutter_core: ^1.0.0
flutter_material: ^1.0.0测试 Widget 树的兼容性
- 检查与
Theme、Navigator等 Widget 的兼容性。
重构自定义 Widget
- 如果你的 Widget 依赖于隐式的 Material 主题，请考虑注入你自己的
ThemeData。
6. 受益最大的用例
📱 平台特定应用
- 只做 Android 应用？那就只用 Material 包。
- 只做 iOS 应用？那就只用 Cupertino 包。
🛠 自定义 UI 框架
- 正在构建像新拟态（Neumorphic UI）或玻璃拟态（Glassmorphism）UI 的团队，现在可以只依赖
flutter_core。
🕹 Flutter 游戏
- 游戏如果用 Flutter 做 UI，可以完全跳过 Material/Cupertino 包，以获得性能提升。
📦 软件包创作者
- Widget 库的作者可以提供轻量级的包，而无需继承未使用的 Material/Cupertino 逻辑。
7. 潜在的风险和注意事项
这项改变并非没有挑战：
❌ 新开发者的学习曲线
- 新手可能会对拆分后的导入和包感到困惑。
❌ 初始设置的增加
- 你将不得不更明确地管理更多的依赖项。
❌ 可能的兼容性问题
- 一些插件和包如果依赖于旧的单一结构，可能会被破坏。
⚠ 需要迁移策略
- Flutter 必须提供工具来简化过渡，并最大限度地减少中断。
8. 未来的可能性：自定义设计系统
也许最令人兴奋的部分是，这项改变对 Flutter UI 的未来意味着什么：
🎨 自创设计系统
- 想象一下，你可以创建一个完全不依赖 Material 或 Cupertino 的
package:my_custom_ui。
💡 新的社区标准
- 社区可以开始标准化替代的设计系统，就像 React 社区的 Tailwind、Chakra UI 等一样。
🔌 更轻松的设计国际化
- 并非所有国家或平台都遵循 iOS 或 Material 约定。现在，你可以从一开始就定义自己的用户体验。
9. 结论
将 Material 和 Cupertino 解耦成独立的软件包，标志着 Flutter 及其开发者社区迈出了具有里程碑意义的一步。这不仅仅是为了代码更整洁------更是为了向前所未有的定制化、性能优化和设计创新敞开框架。
如果你曾因旧 Flutter 架构的"一刀切"性质而感到受限，那么现在就是你的机会。随着 Flutter 进入这个新的模块化阶段，你的 UI 可以变得更轻、更快，并且独一无二。
这不仅仅是结构上的改变------它是一种理念上的转变。 你准备好了吗？
敬请期待。 保持模块化。 欢迎关注我的微信公众号：OpenFlutter，感恩。