Flutter在OpenHarmony记事本中的实战：架构、适配与性能优化

1. 选型复盘：OpenHarmony 记事本为什么用 Flutter 来做

1.1 记事本应用的关键约束不在 UI，而在交付效率

我最早接到这个任务时，团队里其实吵过一轮：OpenHarmony 自己的声明式 UI 框架 ArkUI 已经挺好用了，为什么要绕一圈用 Flutter？这个问题的答案，恰恰是记事本这类"轻量级应用"最容易被低估的地方。

记事本的 UI 复杂吗？不复杂。无非是一个列表页、一个编辑页、一个搜索交互、一个数据持久化。真正复杂的是"多端一致性和交付节奏"。我们当时的规划里，这个记事本不止跑在 OpenHarmony 上，还要同步出 Android 版、桌面版甚至 Web 版。如果每一端都用原生技术栈重写一遍，一个小工具类应用的人员投入会被放大好几倍。而我一个人，靠一套 Flutter 代码，就能把 OpenHarmony 和 Android 两端的核心逻辑同时覆盖——这个杠杆效应，对于个人开发者和小团队来说，几乎是决定性的。

另一个约束是"轻量"本身。Lightweight 这个关键词意味着首包体积不能离谱、内存占用要克制、打开要快。Flutter 的 Skia/Impeller 渲染体系在移动端已经打磨了很多年，在列表滚动这种高频场景下，只要不写出 O(n²) 的 build 逻辑，帧率稳在 60fps 问题不大。再加上 Flutter 自带的 Material 组件库，一套默认风格就能把 UI 做得很体面，省下的时间可以全砸到业务逻辑和用户体验上。

1.2 Flutter for OpenHarmony 的工程接入方式

聊到工程接入，这里要先澄清一个容易混淆的点：Flutter for OpenHarmony 并不是把 Flutter SDK 原封不动跑在 OpenHarmony 上，而是 OpenHarmony 社区基于 Flutter 框架做的适配层，它把 Flutter 引擎的渲染输出接到 OpenHarmony 的图形栈上，同时用 Flutter 插件机制对接 OpenHarmony 的能力接口。

具体到工程接入，目前比较顺的路子是直接用 OpenHarmony 版本的 Flutter SDK 和 Dart SDK，创建项目后，工程里会同时出现两个壳：

• ohos/ 目录：OpenHarmony 的 HAP 工程外壳，负责打包、权限声明、原生入口。
• lib/ 目录：你真正的 Flutter/Dart 代码。

实际写业务的时候，你的代码几乎不需要关心底层是 OpenHarmony 还是 Android，唯一要留个心眼的是插件生态。比如 path_provider、shared_preferences 这类常用插件，OpenHarmony 版本要确认是否有对应的原生实现，没有就得自己用平台通道补一个。记事本这种应用，数据持久化是刚需，我在选型时就提前把"插件是否兼容 OpenHarmony"列成了一个重要考察维度，避免开发到一半发现某个依赖根本跑不起来。

提示：创建工程时，检查一下 flutter doctor 是否能正确识别 OpenHarmony 的环境，如果识别不到，大概率是环境变量没配对，先解决环境再谈编码。

1.3 与原生 ArkUI 的取舍

我并不是说所有 OpenHarmony 应用都该用 Flutter。如果你做的是一个深度系统工具，要高频调用系统 API、要跟状态栏/通知/后台任务死磕，那 ArkUI 甚至 C++ 原生更合适。但记事本不一样，它涉及的平台能力就三样：文件读写、数据库、可能再加一个分享。这些在 Flutter 生态里都有非常成熟的插件，属于"跨平台框架最舒服的舒适区"。

而且从团队演进角度看，Flutter 的招聘池更大，社区资料更多，遇到问题搜解决方案时，一条报错关键字能翻到几百条讨论帖。这个隐性成本，往往比框架本身的性能差异更值得认真权衡。

2. 主页面架构的主线：页面、状态、数据三明治结构

2.1 三明治的每一层分别管什么

记事本主页面看起来简单，但"简单"和"乱"之间只有一步之遥。很多人写主页面，喜欢把数据请求、状态管理、UI 构建全塞进一个 StatefulWidget 里。前期数据量小看不出来，一旦加了搜索、分类、多选删除，那个 build 方法就会膨胀到几百行，改一个需求牵一发动全身。

我设计主页面时，刻意把代码分成了三层，结构上像个三明治：

• View 层：NoteListPage，只负责渲染。它接收一个状态对象，根据状态的不同组合展示列表、空态、加载态或错误态。
• ViewModel/State 层：NoteListViewModel，继承 ChangeNotifier，负责持有笔记列表数据、搜索关键字、加载状态，并向外暴露操作方法。
• Repository/Data 层：NoteRepository，负责读写数据库、处理排序、做关键词过滤。ViewModel 永远不直接碰数据库。

这个分层不是花架子。它带来的最大好处是：每一层都可以独立测试。我可以不启动 UI，直接单测 ViewModel 的搜索逻辑；也可以不连真实数据库，用一个 Mock Repository 去驱动 UI 跑各种状态。在后面接入 OpenHarmony 真机时，这套分层还帮了大忙——平台适配层有问题时，我只需要替换 Repository 的实现，UI 层完全不用动。

2.2 状态管理选型：为什么弃用 Bloc 改用 Provider + ChangeNotifier

Flutter 社区的状态管理方案一抓一大把，Bloc、Riverpod、GetX、Provider 都有拥趸。说实话，用 Bloc 写出来的代码结构更"标准"，事件驱动流式处理，非常适合大型团队协作。但记事本主页面的状态流转并不复杂：加载笔记、搜索、点击跳转、返回刷新。为这点状态引入 Bloc，意味着要写一大堆 Event 和 State 样板代码，反而把轻量级应用搞重了。

我最终选了 Provider + ChangeNotifier，理由就三个：

1. 代码量少。一个 ChangeNotifier 子类加 notifyListeners() 就能完成状态更新，没有额外的概念负担。
2. Flutter 框架内置，不引入额外状态管理库，依赖树更干净。
3. 主页面的状态是"单一数据源"模式，不存在跨页面共享复杂状态，ChangeNotifier 的粒度刚刚好。

ViewModel 的核心骨架长这样：

dart复制class NoteListViewModel extends ChangeNotifier {
  final NoteRepository _repository;

  List<Note> _notes = [];
  List<Note> get notes => _notes;

  ViewState _viewState = ViewState.loading;
  ViewState get viewState => _viewState;

  String _keyword = '';
  String get keyword => _keyword;

  NoteListViewModel(this._repository);

  Future<void> loadNotes() async {
    _viewState = ViewState.loading;
    notifyListeners();
    try {
      _notes = await _repository.fetchAllNotes(keyword: _keyword);
      _viewState = _notes.isEmpty ? ViewState.empty : ViewState.content;
    } catch (e) {
      _viewState = ViewState.error;
    }
    notifyListeners();
  }

  void updateKeyword(String keyword) {
    _keyword = keyword;
    loadNotes();
  }
}

注意我在 updateKeyword 里直接触发了重新拉取。这里有一个性能上的考量：本地数据库查询通常很快，没必要做防抖，但如果你把 Repository 换成远端接口，就一定要在 ViewModel 这层加防抖。这个粒度放在 ViewModel 而不是 Widget 里，也是为了让搜索逻辑可以被单元测试覆盖。

2.3 数据层抽象：主页面的 Repository 接口设计

Repository 是主页面架构里最容易随手写、也最容易写坏的一层。很多人的 Repository 长成"数据库访问工具类"，每个方法直接对应一条 SQL，完全没有抽象。这样做的后果是：当你想把本地存储从 sqflite 换成 drift，或者从纯本地改为"本地缓存 + 远端同步"，整个页面层都得跟着改。

我设计 Repository 时，接口全部围绕"业务意图"定义，而不是围绕存储方式：

dart复制abstract class NoteRepository {
  Future<List<Note>> fetchAllNotes({String keyword});
  Future<Note> fetchNoteById(String id);
  Future<void> upsertNote(Note note);
  Future<void> deleteNote(String id);
}

至于底层是 sqflite 还是 drift，是存在文件里还是存在数据库里，ViewModel 完全不关心。这就给后续扩展留下了余地。

这里顺带聊一个 Dart 语言层面的小知识：如果模块内部拆分成多个文件，可以借助 part 和 part of 关键字组织私有实现。不过说实话，我在这个项目里没怎么用 part，因为 part 会把文件之间的依赖关系隐式化，IDE 跳转和代码审查体验变差。Dart 官方更推荐的还是 import 配合 library 的可见性控制。part 更适合的场景是：你要在一个文件里访问另一个文件的私有成员，或者做代码生成时被迫使用。日常业务代码能不碰 part 就别碰，这是我踩过坑之后的直接建议。

3. 主页面 UI 拆分与 Widget 组织：列表、搜索、新建入口

3.1 页面骨架：SafeArea、Column 与 Expanded 的配合

主页面 UI 的组织方式，直接决定了后续能不能干净地扩展。我的布局骨架是：

code复制Scaffold
└── SafeArea
    └── Column
        ├── SearchBar（固定高度）
        ├── Expanded
        │   └── AnimatedSwitcher（切换 loading/list/empty/error）
        └── FloatingActionButton（新建）

这个结构看起来简单，但有几个细节值得展开：

第一，SafeArea 必须放在最外层。 OpenHarmony 真机上，设备顶部可能是状态栏，底部可能有导航条或安全区留白。如果不处理 SafeArea，列表第一项可能被刘海遮挡，或底部按钮被系统手势条盖住。Flutter 的 SafeArea 会自动读取系统 MediaQuery 的 padding 信息，省掉手动适配的活。

第二，搜索栏不要和列表放在同一个可滚动区域。 我见过有人把搜索框放在 CustomScrollView 的 SliverAppBar 里，实现"滚动收起搜索框"的效果。好看是好看了，但耦合了 UI 和滚动状态。轻量级应用要优先保证维护性，固定搜索栏带来的稳定体验，远比"花哨的收起动画"重要。而且固定搜索栏还能顺便解决一个搜索焦点的问题：用户输入到一半列表刷新了，搜索框不会被滚出屏幕，体验反而更稳。

第三，AnimatedSwitcher 是处理多状态切换的利器。 加载态、空态、列表态之间的切换，如果直接 if/else 返回不同 Widget，会有很生硬的跳变感。用 AnimatedSwitcher 包一层，切换时自动做淡入淡出，代码量没增加多少，体验却档次提升。

3.2 笔记列表项的真实取舍：标题、摘要、时间谁优先

记事本列表项的设计，最考验产品直觉。一个笔记本大小的卡片上，能放的信息无外乎标题、摘要、创建时间、修改时间、标签。放得越多，列表越重，越违背"轻量"的定位。 我的取舍是：一级信息放"标题 + 修改时间"，二级信息放"摘要（最多一行）"，标签、字数统计这些信息全部放弃。

标题用 maxLines: 1 加 ellipsis，摘要用 maxLines: 1 或 2，时间放在右下角小字号灰色。这样一个列表项的高度能被压缩到 72 像素左右，一屏能展示更多内容，用户扫视的效率反而更高。

代码上我强烈建议把列表项单独抽成一个 Widget，比如 NoteListItem，并且使用 const 构造器尽可能复用：

dart复制class NoteListItem extends StatelessWidget {
  final Note note;
  final VoidCallback onTap;

  const NoteListItem({super.key, required this.note, required this.onTap});

  @override
  Widget build(BuildContext context) {
    return ListTile(
      title: Text(note.title, maxLines: 1, overflow: TextOverflow.ellipsis),
      subtitle: Text(note.contentPreview, maxLines: 1, overflow: TextOverflow.ellipsis),
      trailing: Text(note.updatedAtText()),
      onTap: onTap,
    );
  }
}

为什么强调 const？因为列表项是列表滚动中最频繁被构建的对象。Dart 里 const 构造器可以被编译器缓存，只要参数不变，同一个位置的列表项 Widget 就不会重新生成。虽然现代 Flutter 的 diff 机制已经很快，但这种"小而美的习惯"积累起来，对帧率是有实打实帮助的。

3.3 搜索、空态、加载态三态联动的处理细节

主页面最容易被轻视的是"边界状态"——即不是正常列表状态的那些 UI。一共四类：加载中、搜索无结果、数据为空、加载失败。每一个状态我都做了独立 Widget，但让它们的切换逻辑统一收敛在 ViewModel 的 viewState 字段上。

加载态我用了 CircularProgressIndicator，但这个组件在 OpenHarmony 真机上偶尔会出现动画掉帧的情况，我在第 5 章会详细讲。空态不能是一个干巴巴的"暂无数据"，至少要配一个 icon 和一句引导文案。搜索无结果则是"没有找到 xxx 相关的笔记"，和空态要有区分，因为用户在心智模型里要的是"重新搜索"而非"去新建笔记"。

加载失败的状态最容易做崩。很多应用在加载失败时只是弹一个 Toast，然后页面变黑或者停在原地。我的建议是：失败态一定要给出"重试"按钮，并且重试操作直接复用 ViewModel 的 loadNotes()。这不仅让错误可恢复，还让 ViewModel 的测试覆盖变得更容易——模拟 Repository 抛异常，然后断言 viewState == ViewState.error。

4. 路由与数据流：从主页面到编辑页再回来

4.1 路由跳转时传 ID 还是传整个对象

从主页面点击一个笔记，跳到编辑页，这个动作看起来是"传一个对象过去"这么简单，但设计上的分歧很大。

一种做法是把 Note 整个对象传过去。简单直接，编辑页拿到对象直接填充表单。但这里有个隐患：如果编辑页修改了标题或内容，你必须手动把改动同步回主页面的列表项。一旦忘记同步，就会出现"返回到列表，显示的还是旧标题"的经典 bug。

另一种做法是只传 note.id，编辑页通过 Repository 重新加载完整数据。这样数据源天然一致，编辑页修改后写入数据库，主页面在 onReturn 时重新从 Repository 拉取，永远保证最新。

我选了第二种。原因是：主页面和编辑页共享同一个数据仓库，传 ID 是一种"弱耦合但强一致"的方式。编辑页压根不用关心主页面长什么样，它只需要对 Repository 负责。

4.2 编辑返回后两种刷新机制：回调 vs 状态同步

当编辑页保存完返回主页面后，列表怎么刷新？我实践下来有两种主流方案，各有适用场景：

• 方案 A：Navigator.push 的返回值回调。编辑页 save 成功时 Navigator.pop(context, true)，主页面在 push().then((result) 里判断是否刷新。这个方案最简单，适合单入口、无其他页面依赖的情况。
• 方案 B：共享 ViewModel，靠 ChangeNotifier 同步。如果主页面和编辑页共享同一个 ViewModel 实例，那么编辑页修改数据后直接触发 notifyListeners()，主页面自动刷新。适合"编辑页由列表的多个入口打开"的场景。

记事本这个项目里，我用了方案 B 的变体：主页面持有 ViewModel，并把 ViewModel 传给编辑页。这样编辑页保存笔记时，调用 ViewModel 的更新方法，列表自动变化。用户在返回时甚至能感觉到"列表已经是最新状态了"，比"返回后再闪一下加载"体验更好。

不过注意，跨页面共享 ViewModel 的前提是：这个 ViewModel 的生命周期必须比两个页面都长。就算用户从编辑页返回后再点系统返回键退出应用，ViewModel 里的数据也不应该持有泄漏的页面引用。用 ChangeNotifier 时，编辑页记得在 dispose() 里移除监听，否则轻则内存泄漏警告，重则卡顿闪退。

4.3 新建/删除后列表定位与撤销提示

这里是我个人非常看重的一个细节：用户在编辑页删除了当前笔记，返回列表后应该看到什么？最简单的做法是"列表刷新，那一行消失"。但这会带来一个体验缺口——用户其实不确认"我删的到底是不是这一条"。尤其当笔记很多、标题相近时，用户删除后能不能快速定位到删除位置，直接影响信任感。

我实现了一个"列表底部浮现删除提示"的交互：删除后返回列表，列表停留在删除前的位置，并且弹出带有"撤销"按钮的 SnackBar。用户如果误删，直接点撤销恢复；如果不撤销，SnackBar 倒计时消失。这个交互让删除这种破坏性操作有了安全感。

代码层面，ViewModel 里维护一个 lastDeletedNote 和 lastDeletedIndex，undoDelete() 时把笔记重新插回原位置并保持列表滚动位置。实现并不复杂，但给用户带来的踏实感很强，特别适合记事本这种以"记录信任"为生命线的小应用。

5. OpenHarmony 真机适配踩坑：渲染、线程与包体

5.1 Impeller 渲染引擎在真机上带来的列表帧率变化

Flutter 3.7 之后 iOS 上的默认渲染引擎逐渐切换到 Impeller，OpenHarmony 的适配也陆续支持了 Impeller。Impeller 和 Skia 最大的区别在于：Skia 是即时模式光栅化（每帧重新记录和绘制指令），Impeller 是预编译着色器加缓存管线。说白了，Impeller 的强项是把绘制指令先编译成 GPU 友好的格式，降低绘制一帧时的 CPU 开销。

我在 OpenHarmony 真机上实测打一个千级笔记列表后，明显感觉到 Impeller 的滚动流畅度高于 Skia。具体到数据上：用 Skia 时列表快速滑动偶发掉帧（命中 60fps 线以下），切换到 Impeller 后基本全程稳定 60fps。这个 60fps 的意义在于，列表滚动中文字、光标的绘制不能出现"一跳一跳"的卡顿，否则用户对 App 的性能印象会很差。

但 Impeller 也不是没有坑。它的着色器编译时机和缓存加载策略，在应用冷启动时可能造成短暂的白屏或渲染延迟。如果你在真机上发现启动后首帧有点慢，先别急着怀疑业务代码，可以对比一下切换回 Skia 的效果——这是排查方向上的一个重要分支。

提示：在 OpenHarmony 的 Flutter 适配版本中，能否开启 Impeller 取决于 SDK 版本和 GPU 驱动支持。建议在 flutter run 时先确认目标设备支持再决定是否启用。

5.2 多线程与异步在 OpenHarmony 上的表现差异

Flutter 的 UI 线程是单线程模型，但异步任务（数据库 IO、JSON 解析）可以通过 Isolate 或 compute 函数跑到后台线程。在 OpenHarmony 的适配实现里，Isolate 的调度依赖底层的线程池和事件循环。我实测下来，compute 函数在 OpenHarmony 上能正常工作，但创建 Isolate 的开销比 Android 上略大。

这带来的实际影响是：如果你在列表滚动过程中频繁用 compute 做大数据量 JSON 解析，反而可能因为线程池竞争导致主线程被拖慢。对记事本这种轻量应用，最保险的做法是"能不用 Isolate 就不用"。本地 SQLite 的 select 操作本身是异步的，几乎不会阻塞 UI，真正需要后台处理的场景其实很少。

另外要注意 OpenHarmony 后台任务的限制。应用退到后台后，系统可能挂起或冻结后台进程的定时任务。记事本如果有"自动保存草稿"的需求，要在 AppLifecycleListener 的 paused 状态里及时落盘，不要指望后台一直在跑。

5.3 权限、包名与工程配置的坑

Flutter for OpenHarmony 的工程配置，有几处跟 Android 差异很大，第一次上手很容易卡住。

包名（bundle name）在 OpenHarmony 里叫 bundleName，配置在 ohos/AppScope/app.json5 或者模块的 module.json5 里。这个 bundleName 在打包签名后会变成应用的唯一标识，比 Android 的 applicationId 约束更严格。有一次我把 bundleName 写成了带下划线的格式，编译直接报错，后来改成 com.example.notes 这种常规域名倒序格式才通过。

权限声明：Android 清单文件用 <uses-permission>，OpenHarmony 是在 module.json5 的 requestPermissions 数组里声明。如果你的应用不涉及网络、相机、定位，记事本这种纯本地应用其实可以不申请任何敏感权限。这一点比 Android 省心很多，但反过来，一旦你需要申请存储权限，OpenHarmony 的 granular 权限分级逻辑跟 Android 也不是完全一致，建议真机上每种权限都亲手过一遍。

应用图标和启动图：OpenHarmony 应用外观配置在 resources/base/media 目录下，图标格式是 .png，文件名要按规范来。如果你用 Flutter 的默认工程模板，这里一般已经配好了，不需要额外动。但如果你改了 bundleName 或应用名，记得同步更新 string.json 里的 app_name。

5.4 轻量化体积控制：从 APK 到 HAP 的裁剪思路

"轻量级"这个词最终要落到产物上。Flutter 应用打包成 HAP 之后，体积一般由三部分构成：

• Dart 代码编译产物（业务代码 + 框架代码）。
• Flutter 引擎库（libflutter.so 等）。
• 资源和字体文件。

Dart 业务代码占比通常很小，大头是引擎库和各种组件资源。控制 HAP 体积的有效手段包括：

1. 开启 --split-debug-info 和 --obfuscate：关闭调试信息，压缩代码。注意开启混淆后，堆栈信息会变得不可读，需要提前把 Symbol 文件归档好。
2. 删除用不到的字体。Material 库默认带了一套 Roboto 字体（几十 MB 级），如果你的应用全中文界面、自定义了字体主题，完全可以把默认字体剔除，换成思源黑体或系统默认字体。
3. 图片压缩。记事本很少有图片资源，但如果有启动图、空态插图，务必压到 WebP 或适当尺寸的 PNG，不要直接丢一张 2K 分辨率的大图。

我给的参考目标：一个基础记事本 HAP，去掉调试信息后控制在 30MB 以下 是比较合理的。如果大于这个值，先查资源再查引擎配置，大概率是资源或字体没优化到位。

6. 轻量级背后的细节：首帧速度、内存与后续扩展

6.1 首帧优化：主页面的数据预加载

用户点击 App 图标，到看见列表内容，这个时间窗口是决定"是不是第一眼就喜欢"的关键。Flutter 应用启动的一般流程是：原生壳初始化 → Flutter 引擎启动 → Dart VM 加载 → 首帧渲染。其中 Dart 侧的耗时大部分花在 runApp 到主页面的 loadNotes() 完成这一段。

我在主页面里做了一个很小的优化：把数据加载提前到 ViewModel 构造阶段发起，而不是等页面 initState 里再调用。

dart复制class NoteListViewModel extends ChangeNotifier {
  NoteListViewModel(this._repository) {
    loadNotes(); // 构造时即开始加载
  }
}

这样，UI 还在构建首帧时，数据请求已经在跑，等用户看到页面时，数据往往已经就绪或即将就绪，首帧到可交互的时间差被压缩了。对 SQLite 这种本地数据库，效果尤其明显——查询耗时本身只有几十毫秒，但省掉这几十毫秒可以让首帧体验从"闪了一下加载动画"变成"直接就是内容"。

6.2 内存与对象复用：列表项尽量避免在 build 中频繁创建新对象

Flutter 性能优化的第一条铁律是：不要在 build 方法里做耗时的分配工作。列表项尤其如此，ListView.builder 每滚动一帧，所有可见项都可能重建 build，如果你在 build 里去创建正则表达式、拼接大字符串、做数据库查询，滚动帧率必然崩。

我的约束清单如下：

• 列表项的时间格式化结果，在 Repository 返回数据时就算好，存到 Note 的 updatedAtText 字段里，不要在 Item 的 build 里反复格式化。
• 颜色、字号、间距全部用常量或 Theme.of(context) 读取，不要在 build 里计算。
• 构建列表项时，将不需要变化的子组件用 const 构造。

这套习惯在真机上直接体现为：千级列表快速滚动不掉帧，内存曲线平稳，不会有反复 GC 造成的微卡顿。

6.3 后续扩展的边界：保持轻量的同时不堵死未来功能

轻量级应用最怕的不是功能少，而是"扩不动"。所以即便现在只做记事本，我也在架构上留了几个口子：

• 标签功能：Repository 接口里预留了 fetchNotesByTag 方法，虽然 UI 还没做，但数据层已经准备好了。
• 排序方式：ViewModel 的加载方法接收一个排序参数，默认按修改时间倒序，后续加"按创建时间排序"只需要一个字段的事。
• 主题切换：UI 层没有硬编码颜色，全走 ThemeData，未来接深色模式零成本。
• 同步能力：Repository 的抽象接口是天然的热插拔点。等哪天真要接"云同步"，我只需要写一个 CloudNoteRepository implements NoteRepository，把所有方法改成"本地查 + 远端拉取合并"，主页面和编辑页的代码一行都不用动。

这些口子不是"过度设计"，而是"留白设计"。它们的存在没有增加当前代码的复杂度，却能在需求来临时避免"推倒重写"的窘境。

从我个人的实际开发体验来说，OpenHarmony + Flutter 的组合目前在轻量级应用上已经达到了可以正经交付的水平。选型的时候别被"新平台"吓住，真正决定成败的不是框架，而是你分层的清晰度、对边界状态的覆盖程度，以及提前踩坑时积累的应对手册。如果你现在正准备从零搭建一个 OpenHarmony 上的 Flutter 应用，我的建议是：先把主页面这几件事想清楚——状态怎么管、数据怎么来、返回怎么刷、异常怎么兜。想清楚这四件事，剩下的功能基本都是往这个骨架上加肉，翻不了车。