前三篇我们已经统一了三个关键结论：

• FlutterEngine 是系统级资源

• 企业级混合项目必须做引擎统一管理

• 单引擎是默认正确模型

现在问题自然变成了一个工程问题：

👉 当 Flutter 页面越来越多、业务越来越复杂时，Flutter 侧该怎么组织？

如果没有模块化，Flutter 很快就会变成：

• 巨型工程
• 全局状态混乱
• 改一个模块全量编译
• 无法并行开发
• 混合项目难以长期维护

这一篇，我们专门解决：
👉 Flutter 在混合项目里的“组件化架构设计”。

一、先说结论：混合项目的 Flutter，必须“去 App 化”

很多 Flutter 项目天然是：

一个完整 App
一套入口
一套路由
所有业务都往里加

但在混合项目里，这种形态是灾难。

因为混合项目里的 Flutter，本质角色是：

👉 “被嵌入的 UI 子系统”

所以 Flutter 架构必须从：

❌ App 形态
升级为：
✅ Shell + Feature Modules

这和你熟悉的 Android 组件化，本质完全一样。

二、企业级 Flutter 模块化推荐结构

推荐你从一开始就设计成三类工程：

repo_root/
  flutter_shell/         # 唯一入口壳工程（唯一 main）
  flutter_pay/           # 业务模块（package）
  flutter_profile/
  flutter_panel/

职责非常清晰：

模块	角色
flutter_shell	App 壳、路由中枢、全局状态、Native Bridge
flutter_xxx	业务模块，只提供页面/能力

👉 shell 负责“系统”，模块负责“业务”。

三、flutter_xxx 必须长什么样？（非常关键）

每一个 flutter 模块，应该像一个Android library module：

它应该：

✅ 能被依赖
✅ 能独立开发
✅ 能独立调试
✅ 不控制全局

所以 flutter_pay 里，推荐只有：

• 页面（PayPage）
• 子路由（payRoutes）
• 控制器 / store
• 模块初始化（可选）

🚫 不应该有：

• runApp
• MaterialApp
• 全局 Navigator
• 全局插件注册

一句话：

👉 模块 = Widget + 能力，不是 App。

四、那模块如何“单独跑起来”开发？

这就是 Flutter 里常用的：example 调试壳模式

flutter_pay/
  lib/
  pubspec.yaml
  example/
    lib/main.dart
    pubspec.yaml

flutter_pay 本体是“库”。
flutter_pay/example 是“调试 App”。

开发时：

cd flutter_pay/example
flutter run

这相当于 Android 里的：

单模块调试 Application

好处非常明显：

• 不用启动整个宿主
• 专注开发某个模块
• 可 mock 登录态/环境
• 模块边界自然清晰

五、flutter_shell 扮演什么角色？

flutter_shell 是整个 Flutter 世界的“系统壳”。

它至少负责：

• 唯一 main()
• MaterialApp
• 路由总表
• 模块注册
• 全局状态
• Native Bridge
• 主题 / 语言 / 登录态

它不写具体业务页面，只“组装模块”。

就像 Android 主 App 不写业务实现，只做：

• Application
• 路由初始化
• 模块注册
• 环境搭建

六、模块如何接入 shell？（路由中枢）

真实工程里，通常会设计一个“模块注册机制”。

例如（概念层面）：

• flutter_pay 暴露：PayModule.routes
• flutter_profile 暴露：ProfileModule.routes

flutter_shell 在启动时统一注册：

• /pay → PayPage

• /profile → ProfilePage

这样 Android 只需要告诉 Flutter：

👉 open("/pay")

而 Flutter shell 决定：

👉 这个 route 属于哪个模块，渲染哪个页面。

七、这套结构解决了哪些真实工程问题？

✅ 1. 单引擎可控

• 引擎不变
• 显示由 shell 调度
• 页面不再串

✅ 2. 模块边界清晰

• 模块之间没有 Navigator 依赖
• 没有全局状态污染
• 模块可以独立演进

✅ 3. 支持多人协作

• 一个模块一个仓库 / 目录
• 各自 example 调试
• shell 只负责集成

✅ 4. 非常适合混合架构

• shell 可天然承接 Native 指令
• 模块只关心业务 UI
• Android ↔ Flutter 通信集中在壳层

八、从系统角度看，这就是“Flutter 子系统”

你现在这套结构，其实已经非常“系统工程化”了：

• FlutterEngine：运行时内核
• flutter_shell：系统壳
• flutter_modules：业务插件

这在架构层面，已经不再是“写页面”，而是：

👉 在 Android 进程里，搭了一个 Flutter 子系统。

这一步，是从“会 Flutter”走向“跨端架构”的关键跃迁。

九、和 Android 组件化的一一对应

Android	Flutter
Application	flutter_shell
App 壳工程	flutter_shell
Library Module	flutter_pay
debug 壳 App	flutter_pay/example
ARouter	Flutter Router
Module Init	Module Register

你会发现：
👉 你原来那套经验，可以几乎 1:1 迁移。

十、这一篇你真正应该带走的结论

✅ Flutter 在混合项目中，必须“组件化”
✅ 组件必须“去 App 化”
✅ shell 是中枢，不是业务堆积地
✅ example 是 Flutter 的 debug 壳模式

十一、下一篇我们进入“最难、也最关键的一步”

前面四篇，你已经完成了：

• 混合认知
• 接入闭环
• 引擎模型
• 模块架构

下一篇，我们进入真正让混合项目“像系统一样运转”的部分：

Android 原生页面嵌 FlutterView 的工程化落地（通信 / 路由 / 返回栈 / 性能）