企业官网建设流程全解析

最近在折腾一块 OpenHarmony 开发板，手头设备的性能还不错，但能跑的第三方应用少得可怜。我一直想验证一个问题：Flutter 在这套系统上到底能不能把一个真实项目完整地跑起来，而不是跑个 Hello World 就发朋友圈的水平。左挑右选，我把目标定在了一个应用上——藏头诗生成器。用户输入几个字，应用生成一首以这几个字作为每句开头字的诗，听起来是个小玩具，但背后覆盖的功能面一点都不小：文本输入、中文校验、数据加载、索引查询、随机算法、页面路由、动画反馈、图片渲染、系统相册写入，这些全被串在一条链路上。项目做完，我对 Flutter for OpenHarmony 的适配成熟度才算真正有了底。这篇文章就是整个项目的完整复盘，从环境搭建、诗库算法、UI 交互到真机适配，踩过的坑和最终的取舍都在里面，想在这条路上少走弯路的可以直接抄作业。

1. 为什么是藏头诗生成器：一个"小而完整"的开源鸿蒙 Flutter 项目

1.1 这个项目覆盖了 Flutter 在 OpenHarmony 上的哪些关键能力

做 OpenHarmony 适配验证，最大的误区是只写一个静态页面看看能不能渲染。真实应用里最容易被平台差异绊倒的，恰恰是那些你看不到的地方。

藏头诗生成器这条链路，几乎把 Flutter 应用最常用的功能面都走了一遍：

我实际做完的最大感受是：Flutter 本身在 OpenHarmony 上跑 UI 是稳的，真正让你花时间的全是"桥"的部分——插件适配、权限模型、媒体库规范。这些恰恰是普通 Demo 不会暴露的。

1.2 我给自己划定的功能边界

做这个项目之前，我给自己立了几条规矩，防止需求越滚越大：

• 不做账号体系，不做社交分享服务端，只做单机核心链路
• 诗体锁定五言和七言，绝句为主，不做词牌、不做藏中诗这些进阶玩法
• 生成算法不追求 AI 级别的语义水平，目标是"首字正确、句子通顺、读起来像诗"
• 诗库用内置数据，纯离线可用，不依赖网络请求

这样收敛之后，整个项目的核心就变成了一条非常清晰的链路：输入几个字 -> 检索诗库 -> 拼出诗句 -> 展示 -> 分享。每一个环节都有明确的验收标准，不会陷入"功能越加越多、适配问题越滚越大"的泥潭。

对想拿这个项目练手的人来说，我建议也保持同样的克制。这个阶段的核心目标是跑通 Flutter 在 OpenHarmony 上的完整开发流程，而不是做一个产品级应用。先把链路打通，后面什么功能都好加。

1.3 Flutter for OpenHarmony 的适配现状

先说清楚一个很多人容易混淆的点：Flutter 官方主线目前并不直接支持 OpenHarmony，你需要在项目里使用 OpenHarmony SIG（特别兴趣小组）维护的 fork 版本。实际操作中就是两个仓库：

• OpenHarmony-SIG/flutter_flutter：Flutter 框架层的 OpenHarmony 适配分支
• 对应的引擎适配仓库，负责把 Flutter 引擎跑在 OpenHarmony 的 ArkUI 能力之上

这意味着你不能直接用flutter.dev官网下载的标准 SDK，得单独拉一套。版本匹配上尤其要小心，不同时期拉取的适配分支对应的 Flutter 版本不同，有的对应 3.7 时代，有的已经追到 3.2x 甚至更高。拉下来之后第一件事就是跑flutter --version，确认版本号再干活，不然容易遇到一些莫名其妙的编译错误。

另一个现实问题是第三方插件生态。pub.dev 上绝大多数插件（比如各种图片保存、分享、权限处理库）都还没有 ohos 平台的实现。你调用的时候不会直接编译报错，而是在运行期收到MissingPluginException。所以项目的原生桥接部分，基本都要自己写 MethodChannel。

这个现状听起来有点劝退，但从另一个角度看，它逼着你把 Flutter 和原生的边界摸清楚，反而是很有价值的锻炼。藏头诗生成器需要桥接的地方不多——主要就图片保存这一处，拿来练手刚刚好。

2. 环境拆解：OpenHarmony 版 Flutter SDK 与首个 HAP 工程

2.1 OpenHarmony 分支的 Flutter SDK 怎么拿

SDK 的获取分三步走，每一步都有讲究：

第一步，拉取 flutter_flutter 仓库的 OpenHarmony 分支。我的做法是用git clone把仓库拖到本地，然后切到对应的 release 分支。这里有个小建议：不要直接拉默认分支，默认分支可能正在开发中，状态不稳定，挑一个带版本号的 release 分支比较省心。

git clone https://gitee.com/openharmony-sig/flutter_flutter.git cd flutter_flutter git checkout <你确认的release分支>

第二步，把 SDK 的 bin 目录加到PATH里。注意这一步的执行顺序，一定要在原来的 Flutter SDK 之前，确保命令行里敲flutter用的是 OpenHarmony 版本。

export PATH="$HOME/ohos_flutter/flutter_flutter/bin:$PATH" flutter --version

第三步，确认 OpenHarmony SDK 本身可用。我是在 DevEco Studio 里配好了 SDK 路径再回到命令行操作的，也就是先把 DevEco Studio 装好，再回来折腾 Flutter，这样环境变量层面不会打架。

这里必须说一个我踩过的坑：一开始我以为只要有了 flutter 的 OpenHarmony 分支，其他事项可以复用原来的 Android 环境。结果构建 HAP 的时候缺了一堆 OHOS 相关的 SDK 组件，报错信息千奇百怪，有的说找不到ohos工具链，有的说 Java 版本不匹配。最后我把 DevEco Studio 和配套的 Command Line Tools 完整装好，所有报错统一消失。在 OpenHarmony 的 Flutter 开发里，DevEco Studio 不是可选项，是必需品。

2.2 创建工程并生成 ohos 目录

Flutter 工程本身创建方式和普通项目没有区别，关键在于创建时要显式声明支持 ohos 平台。我在项目根目录执行了：

flutter create --platforms=ohos --org com.example.acrostic .

执行完之后，项目下除了常见的android/、ios/、lib/目录，会多出一个ohos/目录，这就是 OpenHarmony 侧的原生工程。这里有个细节需要注意：ohos/目录不是手动建的，而是通过flutter create或后续的flutter create --platforms=ohos .命令补生成的。你要是手动复制别人的ohos/目录过来，大概率会因为工程配置和版本不匹配而出各种问题。

ohos/目录里的工程结构，可以理解成 OpenHarmony 应用的标准工程骨架，里面包含了entry/src/main/module.json5、build-profile.json5这些配置文件。后续的权限声明、签名配置都是在这些文件里做的。

Dart 侧的代码结构跟普通 Flutter 项目完全一致：

lib/ ├── main.dart ├── models/ │ └── poem_record.dart # 诗句数据模型 ├── data/ │ └── poem_repository.dart # 诗库加载与索引构建 ├── logic/ │ └── acrostic_generator.dart # 藏头诗生成算法 ├── pages/ │ ├── input_page.dart # 输入页 │ └── result_page.dart # 结果展示页 └── platform/ └── image_saver.dart # 图片保存的平台桥接

2.3 HAP 构建、签名与安装

工程创建好之后，构建 HAP 的命令很简单：

flutter build hap --release

构建产物一般在build/ohos/release/hap/目录下，是一个.hap结尾的安装包。但这里有个前置条件必须有——签名。没有签名的 HAP 无法安装到真机。

签名配置在ohos/工程里的build-profile.json5中，我是在 DevEco Studio 里打开ohos/目录后，通过 IDE 的签名配置功能自动生成签名信息的。如果你不打开 IDE，也可以手动在build-profile.json5里的signingConfigs配置签名证书。手动配置比较繁琐，新手建议直接走 IDE 的自动签名。

安装到真机用的是 hdc 命令，OpenHarmony 的调试工具，用法和 adb 类似：

hdc install build/ohos/release/hap/entry-default-signed.hap

整个流程走通之后，你会得到一个非常关键的认知：HAP 的构建是flutter命令负责的，但签名和安装环节离不开 DevEco Studio 和 hdc 这条原生工具链。后面迭代开发的时候，这个分工要牢记。

2.4 环境搭建中我踩过的三个坑

第一个坑是版本错位。拉取的 flutter 分支和本机 DevEco Studio 的 OpenHarmony SDK 版本对不上，导致编译时出现各种底层报错。解决方案是：先看 flutter 分支 README 里说明了支持哪个版本的 OpenHarmony SDK，再调整 DevEco Studio 的 SDK 版本。这个顺序不要搞反。

第二个坑是 pub 依赖反复下载失败。由于网络原因，Flutter 的 pub 源和 OpenHarmony 的依赖仓库都出现过连接不稳定的情况。解决方式是更换国内镜像源：在环境变量里设置PUB_HOSTED_URL和FLUTTER_STORAGE_BASE_URL，指向可用的镜像地址。

第三个坑最隐蔽——第一次构建时间非常长。flutter build hap --release第一次运行时要下载编译 OpenHarmony 原生依赖，我等了将近半小时，一度以为卡死了。实际上它还在编译，只是没有任何进度提示。后来我习惯性加上了-v参数构建，能看到详细的日志输出，心里才有底。

3. 诗库与算法设计：从分崩离析的诗句到拼出像样的藏头诗

3.1 诗库数据来源与清洗

藏头诗生成的核心资产是诗库。我最初想的方案是直接用一本公开的古诗词数据集，把整首诗作为一个单位存起来，后来发现不行——藏头诗要求每一句诗的首字要等于输入字的顺序，而一首诗内部的句子是固定的，用户输入的字也是变化的，两者直接匹配会导致命中率极低。

正确做法是把诗句从整首诗词中拆出来，以"句"为单位存储。我的清洗流程是这样的：

1. 从公开的古诗词数据集中提取原始文本
2. 按句拆分，只保留五言（每句5字）和七言（每句7字）的诗句
3. 过滤掉包含生僻字的句子，生僻字会导致用户输入常见字时命中率下降，也影响阅读体验
4. 过滤掉包含非汉字字符的句子，比如"其一""并序"这类标题残留

清洗完之后，我得到了一份几千条的诗句集，序列化成 JSON 放进了 Flutter 的 assets 目录。整个文件不到 300KB，对这个体量的应用来说非常轻量。

这里有个关键取舍：我用的是带版权的公开数据集，只作为本地学习项目使用。如果你要正式上架，建议自己整理公有领域的诗词数据，或者购买有授权的数据。

3.2 三层索引：首字、长度、韵脚

诗句数据进入应用后，不能每次生成时全表扫描，那样太低效。我为每条诗句建立了三个维度的索引：

class PoemRecord { final String text; // 完整诗句 final String firstChar; // 首字 final String lastChar; // 尾字 final int wordCount; // 字数：5或7 final String rhymeKey; // 尾字的韵部（简化处理） } class PoemRepository { // 首字 + 长度 -> 诗句列表 final Map<String, List<PoemRecord>> _index = {}; }

组合索引的逻辑是：以firstChar和wordCount两个字段拼接成 key（比如"春_7"），这样给定输入字和诗体选择，就能在 O(1) 时间内拿到候选诗句列表。

韵部索引是后来加的。为了让生成的诗读起来像诗，我会在生成时尽量保证押韵，但押韵不是简单的"尾字相同"，而是按韵部匹配。我内置了一份简化的韵部表，把常见的尾字映射到韵部编号上：

{ "东": "ong", "风": "ong", "中": "ong", "红": "ong", "流": "iu", "秋": "iu" }

不用完整版《平水韵》，一是文件体量问题，二是用户根本不会那么较真。简化到常用韵部完全够用。

3.3 拼诗的核心流程与代码

生成藏头诗的完整流程是这样的：

1. 接收用户输入的汉字字符串，校验长度
2. 解析诗体参数（五言/七言），确定每句的目标字数
3. 遍历输入字符串的每个字，作为当前句的首字
4. 在索引中查找以该字开头、长度匹配的诗句候选
5. 如果开启了押韵，且已经选定了第一句，则优先筛选尾字属于同一韵部的候选
6. 从过滤后的候选中随机挑一句，但要避开重复字过多的句子
7. 重复步骤3-6，直到所有输入字都生成对应诗句
8. 返回诗句列表

生成器的核心逻辑我简化后大概长这样：

List<String> generateAcrostic(String input, {required int lineLength}) { final selected = <String>[]; String? rhymeKey; final usedChars = <String>{}; for (final char in input.split('')) { // 1. 获取候选诗句 var candidates = repository.queryByFirstChar(char, lineLength); if (candidates.isEmpty) { throw EmptyWordException(char); // 当前字没有可用诗句 } // 2. 押韵过滤（排除第一句） if (rhymeKey != null) { final rhymed = candidates .where((r) => r.rhymeKey == rhymeKey) .toList(); if (rhymed.isNotEmpty) { candidates = rhymed; } } // 3. 随机打乱，优先选重复字少的句子 candidates.shuffle(); String? chosen; for (final candidate in candidates) { if (_overlapCount(candidate.text, usedChars) < 3) { chosen = candidate.text; break; } } chosen ??= candidates.first.text; // 4. 记录韵部和已用字 selected.add(chosen); rhymeKey ??= repository.getRhymeKey(chosen); for (final c in chosen.split('')) { usedChars.add(c); } } return selected; }

这段代码其实已经把生成算法的核心策略浓缩进去了：先保证首字正确，再尽力押韵，最后做重复字控制。绝大多数情况下，这三点就足够产出一首"看起来像模像样"的藏头诗。

3.4 通顺度、去重与无解兜底

纯靠随机组合，最容易出现的问题是整首诗"意象跳变"。上一句还在写春江月夜，下一句突然变成大漠孤烟，虽然每句单独拎出来都是好诗，拼在一起就很出戏。这个问题我做了两层处理：

第一层，重复字控制。我在代码里直接把候选句中与已用字重复超过3个字的句子过滤掉，优先选重复字少的。这一步不只是为了美观，更是为了防止出现"春风""春雨""春江"连着三句都带"春"这种尴尬情况。

第二层，重试机制。整体生成一次之后，我会检查整首诗的质量分，如果重复字太多就重新生成，最多重试5次。这5次里只要有一次质量达标，就用那次的结果。

但还有一个问题无解——用户输入的某个字，在当前诗库里根本没有以它开头的诗句。这种情况我试过硬凑：用常用字模板拼一个类似"X日东升照九州"的句子出来，但效果很生硬，用户一眼就能看出是模板拼的，体验反而更差。

最后的方案是：不硬凑，直接给用户反馈，提示这个字暂时没有合适的诗句，建议换个字。同时我会在输入页提供一个"常用示例字"的快捷入口，让用户快速试到能生成的字。这个取舍在体验上反而比硬拼模板好得多。

4. 交互体验落地：输入、生成、展示、分享一条链路

4.1 输入页：中文输入、字数限制与防呆

输入页是整个应用的入口，看起来只是一个输入框，实际处理起来细节不少。

第一个问题是输入限制。藏头诗的句数由输入字数决定：输入4个字生成4句（绝句），输入8个字生成8句（律诗），所以输入框需要限制在 8 个字以内。同时只允许输入汉字，不能有字母、数字或标点。这个限制如果你只在前端做校验，很容易被 IME 输入法的候选词绕过，所以我直接用 TextInputFormatter 在输入层拦截：

class ChineseTextInputFormatter extends TextInputFormatter { static final RegExp _chineseRegex = RegExp('[\u4e00-\u9fa5]'); @override TextEditingValue formatEditUpdate( TextEditingValue oldValue, TextEditingValue newValue) { final filtered = newValue.text .split('') .where((c) => _chineseRegex.hasMatch(c)) .join(); if (filtered.length > 8) return oldValue; return newValue.copyWith( text: filtered, selection: TextSelection.collapsed(offset: filtered.length), ); } }

这里有个体验细节：删除和回退操作不应该被 formatter 拦截。实践中最稳妥的做法不是自己写 formatter，而是用 Flutter 自带的FilteringTextInputFormatter.allow(RegExp('[\u4e00-\u9fa5]'))配合maxLength: 8，两者组合使用能避免不少边界问题。为了这一点我重构过一次输入组件，教训是"能用框架自带能力解决的问题，不要自己造轮子"。

第二个问题是诗体选择。我用了两个 ChoiceChip 让用户切换五言/七言，默认七言。五言诗短小精悍，七言诗内容丰富，考虑到藏头诗本身是"每句首字连起来读"，七言更能撑起视觉上的仪式感。

4.2 用 Isolate 跑算法，别让 UI 卡住

藏头诗生成的算法本身不复杂，单次查询索引、随机抽句，耗时一般只有几十毫秒。但这里有一个容易被忽视的性能隐患：首次加载诗库并构建索引的耗时。

诗库 JSON 有几百 KB，第一次需要完整解析并建立起Map索引。在低端开发板上这个操作可能需要几百毫秒。要是在 UI 线程同步执行，用户会明显感觉到点击生成的瞬间界面卡了一下。

我的做法是用Isolate.run()把"加载诗库 + 构建索引 + 生成诗句"整体丢到后台 isolate 执行：

Future<PoemResult> generateInBackground( String input, int lineLength) async { return Isolate.run(() { final repo = PoemRepository(); // isolate 内重新初始化 repo.loadFromAssets(); // 同步加载和构建索引 final lines = repo.generate(input, lineLength: lineLength); return PoemResult(lines: lines); }); }

这里有一个很多 Flutter 新手会困惑的点：Isolate.run里的闭包不能直接访问主 isolate 的变量，它相当于一个全新的执行环境，需要重新加载数据和构建索引。诗库本身是 assets 资源，isolate 里也能读取，这个设计是成立的。

我实测下来，后台执行和 UI 线程完全分离后，不管诗库多大，界面上都不会出现肉眼可见的卡顿。在 Flutter 里做性能优化，第一步永远是把耗时操作挪出 UI 线程。

4.3 结果页：逐字动画与藏头高亮

结果页的设计目的是让用户觉得"这首诗真的被生成出来了"，而不是简单地把几行文字怼在屏幕上。

整首诗我用一个竖向列表展示，每一行对应一句诗。藏头字用不同的颜色和背景高亮，并在一侧用小标签标注这是"藏头字第N位"，让用户一眼就能看到自己输入的字被用在了哪里。

逐字动画是整个页面最有仪式感的部分。我实现了一个简单的逐字淡入效果：把整首诗按"字"粒度拆分，每个字是一个独立 Widget，通过AnimationController控制每个字的透明度，根据它在整首诗里的位置按顺序延迟触发：

AnimatedBuilder( animation: controller, builder: (context, child) { // 根据 delay 计算当前字是否已经淡入 final t = ((controller.value * totalDelay) - delay) / perCharDelay; return Opacity( opacity: t.clamp(0.0, 1.0), child: Text(char, style: charStyle), ); }, )

视觉上的效果是：整首诗像有人在书写一样，从左到右、从上到下逐字显现，每个字淡入的时间大约 150ms。整套动画跑下来有 2-3 秒的体验窗口，配合页面切换时的渐变转场，仪式感拉满。

我还为结果页加了一个"换一换"按钮，用户不满意当前生成的诗可以随时重新随机生成。这个按钮的实现非常简单，但要配合 loading 状态一起处理——重新生成过程中要防止用户连续点击造成重复请求，我用一个isGenerating布尔值做了防抖。

4.4 保存成图片：RepaintBoundary 与平台通道

分享功能是另一个容易踩坑的地方。需求本身很简单：把整首诗渲染成一张好看的图片，保存到相册里。

第一步，把 UI 渲染成图片。这个 Flutter 原生就能做，用RepaintBoundary包裹需要截图的区域，然后调用截图接口得到字节流：

final boundary = _captureKey.currentContext!.findRenderObject() as RenderRepaintBoundary; final image = await boundary.toImage(pixelRatio: 3.0); final byteData = await image.toByteData(format: ui.ImageByteFormat.png); final pngBytes = byteData!.buffer.asUint8List();

这里pixelRatio: 3.0很关键。如果默认是 1.0，截图尺寸只有实际显示的一半甚至更低，放到相册里放大看会很糊。

到这一步都很顺利，真正麻烦的是第二步——把图片存进系统相册。Flutter 生态里的图片保存插件（比如 image_gallery_saver）大多没有 ohos 平台实现，直接调用会抛MissingPluginException。这条路走不通，就只能自己写 MethodChannel。

Dart 侧封装一个简单的方法：

class ImageSaver { static const _channel = MethodChannel('com.example.acrostic/save_image'); static Future<String> saveToGallery(Uint8List bytes, String fileName) async { return await _channel.invokeMethod('saveImage', { 'bytes': bytes, 'fileName': fileName, }); } }

然后在 ohos 侧用 ArkTS 实现这个 channel 的原生逻辑，把字节流写入媒体库或者拉起系统的文件保存控件。

这个桥接过程我在后面"真机适配"章节还会细讲，这里先记住一个结论：在 Flutter for OpenHarmony 上，任何涉及系统能力的功能，你都要做好自己写平台通道的心理准备。

5. 真机适配细节：OpenHarmony 平台特有的几个坑

5.1 权限白名单：相册保存的两种姿势

OpenHarmony 的权限模型和 Android 不完全一样。在 Android 上，保存图片到相册最常见的做法是声明WRITE_EXTERNAL_STORAGE然后直接写，但在 OpenHarmony 上，新版推荐使用PhotoAccessHelper + PhotoViewPicker的方式，让用户主动选择"保存到哪个相册"或"授权给哪个应用"，而不是应用直接申请全量写入权限。

我的实践是走了两条路线对比：

第一种，直接申请ohos.permission.WRITE_IMAGEVIDEO权限，在module.json5里声明：

{ "module": { "requestPermissions": [ { "name": "ohos.permission.WRITE_IMAGEVIDEO", "reason": "保存生成的藏头诗图片到相册", "usedScene": { "abilities": ["MainAbility"], "when": "inuse" } } ] } }

这个方案的问题在于，从申请授权到真正写库，中间会经历一次系统弹窗，用户体验偏重。

第二种，用 Picker 让用户主动选择保存位置。用户点击"保存"按钮后，系统拉起一个文件选择器，用户选好目录后应用直接把图片写进去。这个方案不需要申请任何权限，也没有系统弹窗的额外拦截，体验更轻。

我最终选了第二种方案。对我这种小应用来说，少一个权限弹窗就多一分用户留存。这里额外说一句：权限这个事，能不加就不加，这是我在 OpenHarmony 上做应用适配最大的体会之一。

5.2 中文字体与设备差异

Flutter 应用在 OpenHarmony 设备上显示中文，默认用的是系统的中文 fallback 字体，显示效果基本没问题。但如果你的 UI 设计用到了特殊的字体样式（比如楷体、宋体），就需要把字体文件打包进 assets，然后在应用里显式配置fontFamily。

我在藏头诗生成的结果页想用一点更"中国风"的字体，于是尝试引入楷体，结果发现字体文件动辄 3-5MB。这个体积对移动应用来说是笔不小的开销，尤其是 OpenHarmony 设备普遍存储空间不算宽裕。最后我选择只在结果页的诗句部分使用本地楷体，其他地方全部用系统默认字体，既保证了视觉效果，又把体积增量控制在了可接受范围。

这里有个性能上的小技巧：字体文件不要全局注入，只在需要使用它的页面通过DefaultTextStyle局部覆盖。这样可以避免应用启动时加载大体积字体，降低启动耗时的峰值。

5.3 热重载与日志：真机调试的完整链路

OpenHarmony 上跑 Flutter 的调试体验，跟 Android/iOS 上有一点明显区别：热重载（Hot Reload）支持程度取决于你使用的适配分支版本。我用的这个版本在 Debug 模式下是支持热重载的，但偶尔会遇到热重载后状态错乱的情况，尤其是改到 native 侧代码的时候，热重载直接失效。

我的调试工作流基本是这样的：

1. 先通过flutter run -d <device-id>把应用跑起来
2. Dart 层代码改动用 r 键热重载
3. 原生侧代码改动一律flutter build hap --debug重新安装
4. 需要看原生日志时，用 DevEco Studio 的 Log 窗口过滤 hilog 输出

还有一个非常实用的排查手段：如果是保存图片这类桥接功能出问题，先在 Dart 侧 MethodChannel 调用处打断点，确认参数有没有传到原生侧；再到 ohos 侧的 channel 方法里打日志，两边对比，基本能定位到是传输问题还是原生实现问题。

5.4 包体积、启动速度与内存占用

真机安装 HAP 后，我第一时间看了包体积。Release 版的 HAP 大概在 50MB 上下，其中 Flutter 引擎是绝对的大头，诗库 JSON 只占了几百 KB。这个体积对 OpenHarmony 设备来说还可以接受，但我能明显感觉到 Flutter 引擎没有针对 OpenHarmony 做裁剪优化，同样是引擎，比 Android 端同版本 Flutter 打出来的包要大一些。

启动速度方面，首次冷启动有一个明显的引擎初始化过程，在开发板上需要 1-2 秒。打开应用后，我用了flutter run的 timeline 工具观察，发现内存占用中 Flutter 引擎常驻部分占了绝大部分，Dart 堆本身很小，诗库索引也就消耗了几 MB。

做性能优化时我的注意力主要放在两点：一是避免在启动阶段同步加载诗库，改为进入输入页后再异步加载，不阻塞首帧；二是内存上不保留重复资源，诗库索引只建一份，全局复用。这两点做完之后，应用整体的流畅度已经到了可以正常日常使用的水平。

6. 实测效果与下一步能做的方向

6.1 真机实测数据

在所有开发工作完成后，我在真机上做了完整的回归验证。先放一组我自己记录的实测数据，用的是 OpenHarmony 标准开发板，性能中端水平，仅供参考：

功能层面，藏头诗生成器在真机上完成了所有核心链路的闭环：输入"平安喜乐"生成七言绝句、逐字动画展示、一键保存到相册。这个过程中没有再出现MissingPluginException，也没有出现字体显示异常或页面白屏。对 Flutter for OpenHarmony 的适配现状，我的评价是：能跑，能干活，但需要你愿意亲手处理平台差异。

6.2 后续扩展：内嵌数据库、AI 生成、更多诗体

项目做到这个程度，已经具备了一个完整应用的骨架。如果后面要往深度迭代，我列了几个我认为有价值的方向：

• 内嵌数据库：当前诗库是 JSON 打包在 assets 里的，每次启动都要解析构建索引。如果诗库扩充到几万条甚至几十万条，就需要换用真正的内嵌数据库（在 OpenHarmony 上可以走 sqlite 的 ohos 实现），按首字、韵部建索引，查询效率会高出一截，还能支持模糊匹配。

• AI 语义生成：目前的规则算法本质上是"拼前人诗句"，首字正确但句子之间语义关联弱。如果接入大模型 API，把输入字作为藏头约束，让模型生成语义连贯的新诗，体验会是质变。这需要网络能力和 API Key 管理，适合作为二期功能。

• 藏头词、藏中诗：不只是绝句，可以扩展生成词牌名（如梦令、卜算子）或者藏中诗（每句第N个字连读成句）。这会放大"输入文字生成内容"的玩法和传播性。

• 历史记录与本地收藏：给生成的诗加一个本地收藏夹，记录用户在什么时间、用什么字生成过什么诗。这里正好用上前面提到的内嵌数据库，把数据持久化做起来。

我个人在这个项目上最大的收获，不是藏头诗本身有多实用，而是通过一个足够小的项目，把 Flutter 在 OpenHarmony 上的整个开发链路摸了个透。从 SDK 分支选择到 HAP 签名，从 MethodChannel 桥接到权限模型适配，每一个环节都是实打实干出来的，不是看文档能看会的。如果你也打算在 OpenHarmony 上尝试 Flutter，我的建议是：别从大项目开始，找一个像藏头诗生成器这样功能链路完整的小项目，从头到尾走一遍。跑通的那一刻，你对这个技术栈的信心会比任何教程都来得扎实。