交付清单：主题、平台通道、测试与上架

主题：一次定义，全局生效

Material 3 是默认（第 1 章）。在 MaterialApp 顶层定一次，所有页面通过 Theme.of(context)（第 15 章的 O(1) 查表）取用：

MaterialApp(
  theme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF027DFD)),  // 一个种子色生成整套配色
    useMaterial3: true,
  ),
  darkTheme: ThemeData(
    colorScheme: ColorScheme.fromSeed(
      seedColor: const Color(0xFF027DFD), brightness: Brightness.dark),
  ),
  themeMode: ThemeMode.system,   // 跟随系统；也可让用户在设置里切
  home: const HomePage(),
)

ColorScheme.fromSeed 是 M3 的招牌——给一个品牌色，它按 Material 的算法生成一整套协调的明暗配色。用的时候永远走语义色，别硬编码：

final scheme = Theme.of(context).colorScheme;
Container(color: scheme.primaryContainer);
Text('标题', style: Theme.of(context).textTheme.titleLarge);

平台通道：需要原生功能时的桥

Flutter 自己不实现相机、蓝牙、推送这些——它们是平台能力。绝大多数时候，pub.dev 上已经有插件替你封装好了（image_picker、geolocator、firebase_messaging、local_notifications……），你直接用 Dart API 就行，根本碰不到原生。

只有当你要调一个没有现成插件的原生功能时，才需要自己搭桥——平台通道（Platform Channel）：

// Dart 侧
const channel = MethodChannel('school.app/device');
final id = await channel.invokeMethod<String>('getSchoolDeviceId');

// Android 侧（Kotlin，在 MainActivity 里）—— 你的主场
MethodChannel(flutterEngine.dartExecutor.binaryMessenger, "school.app/device")
    .setMethodCallHandler { call, result ->
        when (call.method) {
            "getSchoolDeviceId" -> result.success(readDeviceId())
            else -> result.notImplemented()
        }
    }

iOS 侧对应写一份 Swift。好消息：Android 那半边就是你本来会的 Kotlin——平台通道让你能在需要时随时下沉到原生，你的 Android 功力不但没浪费，还成了别人（纯 Flutter 背景的）搭不了的桥。

测试：Flutter 的三层，比 Android 顺

Flutter 的测试体验是它的强项之一——尤其 Widget 测试，跑在纯 Dart 里、不需要模拟器、快得像单元测试。三层：

Widget 测试长这样，对写惯了测试的人极其亲切：

testWidgets('点加号后计数变 1', (tester) async {
  await tester.pumpWidget(const MaterialApp(home: CounterPage()));
  expect(find.text('0'), findsOneWidget);

  await tester.tap(find.byIcon(Icons.add));
  await tester.pump();                          // 触发一帧重建

  expect(find.text('1'), findsOneWidget);
});

那台 Mac：iOS 半边的现实

这是这一章标题盖「改一下」的核心原因。Android 打包你闭眼会，但 iOS 那半边有几个绕不开的现实，早知道免得临上架抓瞎：

构建与发布：两条平行的流水线

# 开发期
$ flutter run                          # 装到连着的设备/模拟器
$ flutter run --release                # 测真实性能（debug 模式慢很多，别拿它评性能！）

# Android 产物
$ flutter build appbundle              # 传 Google Play 的 .aab
$ flutter build apk --split-per-abi    # 侧载/内部分发用的 apk

# iOS 产物（需要 Mac）
$ flutter build ipa                     # 传 App Store / TestFlight

# 发版前必做
$ flutter analyze                       # 静态检查，CI 里挡住 lint 问题
$ flutter test                          # 跑单元 + Widget 测试
$ flutter build --release               # 用 release 构建量体积、测性能

崩溃监控与日志：上线后你才真正需要的

App 发出去，真正的考验才开始——你看不到用户的屏幕，只能靠遥测。上线前务必接一个崩溃监控（firebase_crashlytics 或 Sentry），它会把线上的异常、堆栈、设备信息收集回来：

void main() {
  runZonedGuarded(() {
    FlutterError.onError = (details) => Crashlytics.recordFlutterError(details);
    runApp(const ProviderScope(child: MyApp()));
  }, (error, stack) => Crashlytics.recordError(error, stack));  // 抓 Dart 层未捕获异常
}

FlutterError.onError 抓 Widget/渲染层的错误，runZonedGuarded 抓 Dart 层未捕获的异步异常——两个都要挂，否则会漏一半。没有崩溃监控的 App 上线，等于闭着眼开车：学校 App 跑在几百种便宜安卓机上，你自己那台测不出的问题，只有遥测能告诉你。

包体积与混淆

两个上架前顺手做的事：

• 看体积：flutter build appbundle --analyze-size 会告诉你包里什么最占地方（通常是图片和字体）。Flutter 的基础包比纯原生大几 MB，但对功能型 App 通常无所谓。
• 混淆：flutter build apk --obfuscate --split-debug-info=build/symbols——混淆 Dart 代码、把符号表单独存出来（崩溃监控需要它来还原堆栈）。别丢了那个 symbols 目录。

持续集成：让机器替你跑那三条命令

哪怕是小项目，配个最简单的 CI（GitHub Actions）都值——每次推代码自动跑：

- run: flutter analyze          # 静态检查
- run: flutter test             # 单元 + Widget 测试
- run: flutter build apk        # 确认能构建出来

三条命令，挡住 90% 的「合并后才发现编译不过 / 测试挂了」。iOS 的构建要 macOS runner（第 24 章前面说的那台 Mac 的 CI 版本），GitHub Actions 提供，配一次一直用。这和你在 Android 项目里配的 CI 是同一件事，只是命令从 ./gradlew 换成了 flutter。

全书总表：从 Kotlin/Compose 到 Flutter

你读到这里，已经把一门框架从渲染原理到交付走了一遍。用一张对照表收束——这也是你以后可以随时翻回来的速查：

最后：给你那个学校 App 的起手式

合上书就能开工的顺序：

1. flutter create school_app，按第 17 章的 feature-first 骨架建目录。
2. 装四样：riverpod + riverpod_generator（状态·第 16 章）、go_router（导航·第 21 章）、dio + freezed（数据·第 22 章）、flutter_secure_storage（存 token·第 22 章）。
3. 先搭登录：一个 AuthNotifier + go_router 的 redirect 守卫（第 21 章）。
4. 课表页用 ListView.builder + AsyncValue 三态（第 19·23 章）。
5. 数据走 Repository，缓存优先（第 22 章）。
6. 逻辑写进 Notifier，配 Widget 测试（第 24 章）。
7. 发版前过一遍上面那张极简清单，别忘了那台 Mac。

你不是从零开始——第 1 章就说了。现在你手上是一张摊开的、每一处折痕都看得清的图纸。去把它折成那个 App 吧。

这一章的一句话

交付 = 主题一次定义全局取用 + 需要原生时用平台通道下沉（你的 Android 功力在这里反成优势）+ 分层带来的可测性 + 别忘了 iOS 那半边和一台 Mac；而这一路的每一步，都能在你 Compose 的经验里找到对应——你要做的只是把口音换过来。