爱吃超人的怪兽最近在折腾一件事：用 Flutter 给 OpenHarmony 设备做一个软件开发助手 App，核心功能是算法练习平台。说人话就是，让鸿蒙生态里的开发板、开源手机装上一个能刷题、能写代码、能跑测试用例的 App。这个项目做完以后，我对 Flutter 在 OpenHarmony 上的适配情况有了非常具体的认识，也踩了不少文档里根本没写的坑。如果你正准备入坑 Flutter for OpenHarmony，或者想在非标准 Android 设备上做一款工具类应用，这篇文章应该能帮你省下不少时间。
我会按照这个实战项目的完整脉络来写，从技术选型、架构设计、核心模块实现，到环境搭建、真机调试、问题排查，最后聊到打包发布和后续扩展方向。整个过程会带上具体的命令、配置和踩坑实录，尽量让你照着就能走通一条路。
1. 项目整体设计与技术选型
1.1 为什么是 Flutter 而不是 ArkUI 或原生
做 OpenHarmony 应用，官方主推的是 ArkUI + ArkTS，但我在这个项目里还是选了 Flutter，而且是 Flutter for OpenHarmony 的社区分支。原因有三。
第一，算法练习平台的核心是代码编辑、判题执行、题目管理这类逻辑密集的功能，完全不依赖系统私有的 UI 组件。这类业务天然适合跨平台框架来承载。ArkUI 虽然学习曲线不算陡，但如果你之前积累的 Flutter 组件和页面代码没法复用，等于从零开始搭一套 UI 体系，成本会明显高出一截。
第二，Flutter for OpenHarmony 已经在 OpenHarmony SIG 里持续迭代，主仓库是 gitee 上的 flutter_flutter，它保留了 Flutter 的上层 API，对绝大多数第三方 Flutter 包都有比较高的兼容性。也就是说，你在 Android/iOS 上写的那套 UI 和业务逻辑，大概率能通过这个分支编译成 OpenHarmony 的 HAP 包。
第三，算法题库和判题逻辑本来就适合用 Dart 来实现。Dart 的集合操作、异步模型、类型系统，在写算法题相关代码时非常顺手。我可以把题库解析、测试用例匹配、代码模板生成这些东西全部用 Dart 写完，然后同一套代码直接跑在 Flutter 的 UI 层下面，不需要像 React Native 那样再去搭一层桥。
当然，这个选择也要付出代价。最直接的代价是插件生态的适配。OpenHarmony 不是 Android，那些依赖 Android SDK 的 Flutter 插件，比如 location、camera、share 等，基本不能直接用。好在我们这个项目里，核心插件是自己控制的，网络请求、文件存储、JSON 解析这些都是纯 Dart 实现，可以绕开大量系统 API 差异。
如果你也打算做类似工具型 App，我的建议是：优先考虑“纯 Dart 能力能覆盖 80% 功能”的项目形态。这样 Flutter for OpenHarmony 的兼容性优势才能最大化，而不是被插件适配拖垮。
1.2 整体架构与工程结构
整个 App 我采用了两层架构加一个本地执行引擎。
上层是 UI 层，负责首页题库列表、题目详情页、代码编辑器、运行结果页、学习统计页。状态管理用了 Provider，理由很简单：项目规模没有大到需要 Bloc 之类的重型方案，Provider 配合 ChangeNotifier 足够覆盖题目筛选和刷题状态的联动。
中层是数据层，处理题库 JSON 的加载、解析、搜索和分类筛选，以及刷题记录、收藏列表的本地持久化。这里我刻意把数据层和 UI 解耦，所有数据访问统一走 repository。这样后续想接在线题库，只需要替换 repository 的实现，不用动 UI。
底层是执行引擎，负责接收用户提交的代码，在受限环境下编译运行，然后把测试用例的通过情况逐条返回给 UI。这个模块是整个算法练习平台的关键，也是最容易出问题的地方，后面会单独展开。
工程结构上，我按 feature 分包：
text复制lib/
main.dart
app/
app.dart
routes.dart
theme.dart
features/
home/
question/
editor/
runner/
profile/
core/
models/
repositories/
services/
utils/
data/
questions.json
这里有个值得强调的点：题目数据我放在了 assets 里，而不是启动时从网络拉取。原因是在 OpenHarmony 开发板上，网络环境不一定稳定，而且很多时候你是在没有外网的局域网里调试。把题库内置，既能让首屏秒开，也能保证离线可用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 算法练习平台的核心模块设计与实现
2.1 题库数据模型与题目组织
算法练习平台的题库是内容的根基。我设计的数据模型很简单，但经过了几个版本的调整。
核心字段包括：题目 id、标题、难度、标签、题目描述、输入格式、输出格式、示例输入输出、初始代码模板、测试用例列表。测试用例我用 JSON 数组存储，每个用例包含输入和期望输出。输入统一按照字符串处理，这样在执行引擎里做解析时比较统一。
json复制{
"id": "two-sum",
"title": "两数之和",
"difficulty": "easy",
"tags": ["数组", "哈希表"],
"description": "给定一个整数数组 nums 和一个整数目标值 target，请在数组中找出和为目标值的两个整数，并返回它们的数组下标。",
"template": "List<int> twoSum(List<int> nums, int target) {\n \n}",
"testCases": [
{"input": "[2,7,11,15]\n9", "output": "[0,1]"},
{"input": "[3,2,4]\n6", "output": "[1,2]"}
]
}
题目组织上我按难度和标签做了双维度分类。首页用一个简单筛选栏，支持按难度（简单/中等/困难）和标签（数组、链表、树、动态规划等）过滤。这里用 Flutter 原生的 FilterChip 就能实现，不复杂。
比较坑的是题库 JSON 的加载。Flutter 里用 rootBundle.loadString 在 OpenHarmony 上能不能正常工作，一开始我心里是没底的。实测后发现 flutter_flutter 分支对 asset 的支持是完整的，rootBundle 可以正常读取 assets 文件。但要注意一点：图片、字体这类二进制的 asset 没有问题，纯文本和 JSON 更是没毛病。
另外建议给题库 JSON 做一个本地缓存升级机制。具体做法是：首次启动解析后把题目版本号存到 SharedPreferences，后续如果 assets 里的 JSON 文件有更新，就重新解析一次。否则每次启动都解析大 JSON，部分低配开发板会有可见的卡顿。
2.2 代码编辑器实现与输入交互
代码编辑器是这种软件助手类 App 的门面。用户要在里面写代码，所以语法高亮、行号、缩进、软换行这些基础体验必须有。但请注意，OpenHarmony 的 Flutter 分支对第三方插件的支持是有限的，很多成熟的代码编辑器插件未必能直接跑起来。
我试过几套方案，最后选了自绘方案。基础控件用 TextField，开启 maxLines 为 null 来支持多行输入，然后通过一个独立的 TextPainter 层做语法高亮渲染。简单说就是把用户输入的代码按行拆分，用正则对关键字、字符串、注释、数字做 token 匹配，然后把高亮颜色写入 TextSpan。这个方案在性能和兼容性上都很稳，因为完全走 Flutter 原生渲染，不依赖任何平台通道。
行号的实现也不难。在编辑器的左侧固定一个宽度，用同一个 ScrollController 绑定一个 ListView，让行号列表和内容区域同步滚动。文本行数多的时候，行号的渲染用 ListView.builder 懒加载，避免一次性构建几百个 widget 卡顿。
有几个细节值得单独说。
第一，缩进处理。捕获 Tab 键事件插入两个空格而不是 \t，避免不同设备上制表符宽度不一致。第二，输入框底部弹窗问题。如果编辑器是放在底部弹窗里，比如给用户写笔记或者输入测试数据，键盘弹起时会遮挡内容。这个问题的解法是给弹窗内容包一层 AnimatedPadding，padding 值监听 MediaQuery.of(context).viewInsets.bottom，同时把 showModalBottomSheet 的 isScrollControlled 设为 true。第三，长代码换行会导致横向滚动，需要把 TextField 的 scrollPhysics 设为 BouncingScrollPhysics，配合水平方向单行显示，否则代码会被自动折行，看着很难受。
TextEditingController 的监听也要维护好。用户输入代码后需要实时把代码内容同步到 ViewModel 里，但不要每次按键都触发判题或者持久化，那会带来不必要的性能开销。我用了 debounce，在输入停止 500ms 后才更新状态。
2.3 本地执行引擎与判题流程
判题是算法练习平台里技术含量最高的模块。用户在编辑器里写了一段 Dart 代码，App 要能编译运行它，并且用若干条测试用例去验证结果对不对。
这里有一个关键决策：是本地跑判题，还是把代码提交到服务端判题？
做过在线评测系统的人都知道，跑用户代码是一件有安全风险的事，标准的做法是放在容器或沙箱里。但我们的场景是个人算法练习，不是公开竞赛，用户跑的是自己的代码，风险就是自己折腾自己。这个前提下，本地执行反而更符合“软件开发助手”的定位：离线也能用，响应快，没有网络依赖。
我实现了两种执行方式，双轨并行。
第一种是 Dart 子进程方式。利用 Dart 的 Process.start 启动一个单独 Dart 运行时，把用户代码写成临时文件，传入测试用例作为输入，通过 stdin 和 stdout 和子进程通信。这种方式隔离性好，超时后可以直接 kill 子进程，不会卡死主 App。缺点是需要设备上有可用的 dart 运行时，而且子进程启动有固定开销，大概 200ms 到 500ms，在低配板子上会慢一些。
第二种是纯 Dart 解析模拟执行方式。针对单文件、无额外依赖的算法题，我写了一个轻量级的 runner，直接在 App 进程里解析用户代码。这种方案不需要子进程，速度快，但安全性几乎没有，用户代码如果写了死循环，会直接卡住整个 App。因此这种方案需要配合一个提前设置好的超时保护，简单实现是给 test case 的循环次数做上限，或者依赖 Dart 的 Zone.run 来做异步超时。
实际使用时，我会自动判断：如果代码模板的题目类型是数组、字符串、数学这类简单计算题，走纯 Dart 模拟执行；如果涉及 IO、文件、网络这种系统能力，走子进程隔离执行。
判题流程是这样设计的：
- 把用户代码和测试用例拼接成一个可执行的完整 Dart 文件。
- 用当前设备上的 dart 环境（或模拟执行器）运行这个文件。
- 文件内部逐个读取测试用例，跑完把结果逐条输出，格式约定为 JSON 字符串。
- 主 App 读取解析输出，逐条和期望结果做比较。
- 生成判题报告，展示通过用例数、失败用例的输入和期望输出、实际输出。
判题报告我用表格展示，效果非常直观。测试用例数量一多，用户能一眼看到是哪一条用例挂了，挂在哪里。
关于临时文件的存储位置，OpenHarmony 上建议写到应用沙箱目录。Flutter 里我通过 dart:io 的 Directory.systemTemp 获取临时目录，实测在 OpenHarmony 上是可写可执行的，没有 Android 那种奇葩的存储权限问题。
2.4 学习进度记录与本地存储
算法练习平台除了“练”，还要能“记录”。用户每天刷了哪些题、正确率多少、还有哪些题没做，这些信息需要持久化到本地。
存储方案上，我选择了 sqflite 的 OpenHarmony 兼容版。sqflite 是一个 SQLite 封装的 Flutter 插件，在 OpenHarmony 分支上已经提供了适配。不过为了降低配置风险，我先用 SharedPreferences 存了近一周的刷题记录，等核心功能稳定后再迁移到 SQLite。如果你把 SQLite 作为必选项，建议提前验证插件对当前 SDK 版本的兼容性，我在新版 SDK 上就遇到过数据库文件创建失败的问题，最后通过升级插件版本解决。
刷题状态我用一个枚举来表示：未开始、进行中、已完成。每次用户提交代码并通过全部测试用例，就把状态更新为已完成。同时记录提交次数和最近提交时间，用来生成简单的学习统计。
这里有个体验细节：首页每个题目的卡片上，会用一个圆点表示状态，绿色代表已完成、黄色代表进行中、灰色代表未开始。颜色区分在暗色主题下也很明显，比纯文字直观得多。
另外我还做了收藏夹功能。用户遇到好题可以点星标收藏，收藏列表和题目列表分开展示。这个功能用 SQLite 一张表就能搞定，字段只有题目 id 和收藏时间，不用设计复杂外键。
3. Flutter for OpenHarmony 开发环境搭建与工程配置
3.1 SDK 准备与分支选择
这块是很多新手最容易卡住的地方。OpenHarmony 的 Flutter 不是从官网下载 Flutter SDK 直接用的，而是要用 gitee 上的 OpenHarmony 特化分支。名字叫 flutter_flutter，仓库地址在 openharmony-sig 下面。
环境准备分三步。
第一步，安装 DevEco Studio 和 OpenHarmony SDK。DevEco Studio 主要用来提供 SDK platform 和工具链，包括 hdc、hvigor、签名工具等。单独装命令行工具也可以，但 DevEco Studio 更省事，它会把 SDK 路径默认配置好。
第二步，克隆 flutter_flutter 分支。建议直接 clone 到固定目录，然后把它加入 PATH。
bash复制git clone https://gitee.com/openharmony-sig/flutter_flutter.git
export PATH=$PATH:/your/path/flutter_flutter/bin
flutter --version
第三步，配置依赖仓库镜像。国内环境建议配置 PUB_HOSTED_URL 和 FLUTTER_STORAGE_BASE_URL 这两个环境变量，指向可用镜像，能显著提升依赖拉取和组件下载的速度。否则首次构建可能要等非常久，而且容易中途超时失败。
关于版本选择，我强烈建议锁定版本。flutter_flutter 分支对 Flutter SDK 版本、OpenHarmony SDK 版本之间有对应关系，盲目升级到最新往往会导致编译失败。典型的报错是 flutter error resolving plugin [id: 'dev.flutter.flutter-plugin-loader']，这个很大程度上是因为插件和当前 SDK 版本不匹配。建议直接在项目的 pubspec.yaml 里锁定依赖版本，能用稳定版就别用 beta。
3.2 创建工程与依赖适配
创建工程我用的是 flutter create 命令，记得加上 platform 参数。
bash复制flutter create --platforms ohos flutter_algorithm_app
执行完会发现项目里多了一个 ohos 目录，这是 OpenHarmony 的工程壳。和 Android 的 android 目录类似，里面有 entry 模块、build-profile.json5、hvigorfile.ts 这些文件。如果你对 HarmonyOS 的工程结构不熟悉，这第一眼可能会有点懵，但其实对照着 Android 工程的 gradle 文件看，思路是一样的。
依赖适配是另一个容易踩雷的点。pubspec.yaml 里的第三方包不能直接认为在 OpenHarmony 上可用，要看它是否依赖了原生 Android/iOS 代码。一般纯 Dart 的包，比如 dio、provider、shared_preferences（如果它支持 ohos 平台）都能用。凡是依赖 platform channel 的包，在 OpenHarmony 上就可能需要额外的 ohos 适配层。
我这里用到的依赖大概是：
yaml复制dependencies:
flutter:
sdk: flutter
cupertino_icons: ^1.0.6
provider: ^6.1.1
dio: ^5.3.3
shared_preferences: ^2.2.2
sqflite: ^2.3.0
path_provider: ^2.1.1
如果你的项目里某个包不支持 OpenHarmony，一个临时的处理办法是改用条件导入：在 pubspec 的 flutter 配置里对不同平台指定不同依赖。但这是绕路方案，最终还是要找具备 ohos 适配的包来替换。我在项目里就被 path_provider 的版本坑过一次，后来换到支持 ohos 平台的新版本才解决。
另外要注意 Gradle 和插件加载相关的问题。你在 Android 构建时遇到过 you are applying flutter's main gradle plugin imperatively using the apply 一类的提示，在 OpenHarmony 构建时思路也是一样的：插件要按新式声明式方式加载，别再用旧式的 apply 写法。构建工具越是新版本，越要检查这些规范。
3.3 真机部署：开发板选型与系统烧录
写 OpenHarmony App，光有模拟器不够，最终还是要跑到真机上。目前市面上最常见的 OpenHarmony 设备就是 RK3566、RK3568、RK3588 这几个芯片的开发板。Flutter 对 GPU 有要求，RK3568 起步体验还算流畅，RK3566 在一些复杂动画下会有点吃力，RK3588 则基本不用担心性能。
如果你用的是开发板，第一件事是确认系统版本和编译时选的 SDK 版本一致。我这里用的是 RK3568 的 DAYU200 开发板，烧录的 OpenHarmony 系统版本是 4.0 Release。怎么选设备树？这个问题问的人很多，但它主要发生在编译系统镜像的阶段。如果你是拿官方预编译镜像直接烧录，一般不用关心设备树；如果是自己从源码编译，关键是看你的板子型号和屏幕型号。RK3568 的设备树文件很多，每个对应不同的 evb 板卡、不同的内存颗粒或屏幕，选错最明显的现象是开机后屏幕不亮或者触摸没反应。这时候去对应开发板厂商的文档里找明确标注的 defconfig 和设备树文件即可，别随意改 kernel 配置。
应用安装方式很简单，不需要每次都重新烧系统。开发板和电脑连上 USB 后，用 hdc 工具安装 app 的 hap 包。hdc 是 OpenHarmony 的调试工具，使用方法和 adb 高度类似。
bash复制hdc list targets
hdc install /path/to/your_app.hap
hdc shell aa start -a MainAbility -b com.example.flutter_algorithm_app
这里有个比较常见的坑：hdc 识别不到设备。除了要检查 USB 线是否支持数据传输、开发板是否开启调试模式以外，还要注意 Linux 下 USB 设备的访问权限。hdc 底层会通过 USB 协议和设备通信，遇到 permission denied 的情况，需要配置 udev 规则，或者直接用 hdc 自带的 usb 配置命令。网上有人提到 USBManager 和 libusb 的使用，本质上就是权限和 USB 设备枚举的问题。先把设备和宿主机的 USB 链路打通，后面的一切都顺了。
4. 开发过程中的高频问题与排查实录
4.1 Flutter 工程侧报错处理
开发过程中我积累了一堆报错记录，部分很有代表性。
第一个是 flutter error resolving plugin [id: 'dev.flutter.flutter-plugin-loader']。这种错误多出现于插件和工程配置不匹配的场景。排查思路是：先删掉 pubspec.lock 重新 pub get，再看插件版本是否对当前 flutter 版本有兼容要求，最后检查工程里是否有手动 apply 插件的旧式配置。我遇到的情况就是某个项目依赖的插件版本太新，与 flutter_flutter 分支不兼容，锁到旧版本后解决。
第二个是依赖下载困难。有时候 flutter pub get 会卡在某个包上下载不下来的问题，根因往往是版本约束冲突或者下载源不稳定。建议先执行 flutter clean，再重新获取依赖。如果您在国内环境，检查环境变量是否指向了可用镜像。另外建议把所有直接依赖的版本号写死，避免传递依赖升级后锁文件混乱。
第三个是热重载失效。经常有朋友说 flutter hot reload 之后页面没更新，我一般分两层排查：先看终端日志是否真的触发了 reload，再看设备端是否断开了连接。在 OpenHarmony 真机上，热重载速度和稳定性比 Android 模拟器略弱，这是分支成熟度的正常表现。开发时多习惯用热重启而不是热重载，状态不一致的问题会少很多。
第四个是主题相关的小问题。比如 Flutter 内置的 showLicensePage 页面，它的背景色默认跟随主题，在暗色模式下如果没做好主题适配，页面可能变成白底白字。处理办法是在调用时包一层 Theme 来指定亮色或暗色样式，让这个页面和整体 App 风格一致。
底部弹窗里放 TextField 导致键盘遮挡的问题前面提过，这里再补充一下解决方案的代码示意。核心是让弹窗在键盘弹出时跟随上移，并给内容区一个底部留白：
dart复制showModalBottomSheet(
isScrollControlled: true,
context: context,
builder: (context) => Padding(
padding: EdgeInsets.only(
bottom: MediaQuery.of(context).viewInsets.bottom,
),
child: YourSheetContent(),
),
);
我还在列表筛选的双选控件上遇到过 CheckboxListTile 文字距离按钮太近的问题。原因是默认的 title 和 ControlAffinity 组合导致间距太小，设置一个自定义的 contentPadding 就能拉开距离。
4.2 OpenHarmony 设备侧问题排查
设备侧的坑和 Android 那套不完全一样，但排查思路有相通之处。
应用启动闪退，是首先会遇到的问题。打开 log 工具看崩溃堆栈，最常见的是 so 库加载失败或 API level 不匹配。Flutter 应用在 OpenHarmony 上以 native 引擎加 dart 虚拟机的方式运行，如果系统镜像版本太老，可能缺某些 lib 库，这时候要么升级系统版本，要么降低 Flutter 分支版本。
权限申请要特别注意。OpenHarmony 的权限体系和 Android 不同，需要用 module.json5 配置默认权限。比如算法练习平台需要访问网络来加载在线题库（虽然最终我做成离线内置），就得显式声明 ohos.permission.INTERNET。如果你要写文件，还需要申请对应的存储权限。权限配置和请求代码的写法，可以查 DevEco Studio 项目里的 module.json5 模板。
字体的显示问题也遇到了。部分开发板的中文字体文件可能缺失，导致中文显示为方框。Flutter 在 OpenHarmony 上的字体回退机制没有 Android 上那么成熟，解决办法是把常用中文字体打包到 assets 里，然后在 MaterialApp 的 theme 里显式指定 fontFamily。这套方案虽然增加了一点包体积，但能保证所有设备上中文显示一致。
图标库这块，OpenHarmony 官方有 lucide 风格的图标库，如果你想让 App 的图标风格和系统统一，可以直接用官方的图标资源，不用自己画。不过要注意，Flutter 的 Icon 组件和 OpenHarmony 的图标体系不是同一套，落地时最简单的做法是导入官方 SVG 用 flutter_svg 渲染，或者直接把需要的那几个图标转成 Flutter 的 IconData。
4.3 性能与体验优化要点
OpenHarmony 开发板的性能跨度很大，代码要按低配设备优化。
首先是列表性能。题目列表如果直接渲染几百个 Card，在低配设备上会有明显掉帧。我把列表项都改成了 const 构造，并用 ListView.builder 做懒加载。复杂度高一点的，使用 itemExtent 固定行高，这样滚动时无需动态测量，能显著减少布局计算。
其次是代码编辑器的输入性能。TextEditingController 的监听器如果处理复杂逻辑，输入高并发时会卡。我在监听回调里只做轻量标记，真正的状态更新用 Timer.run 放到下一帧，避免阻塞输入。
还有执行引擎的超时保护。无论是子进程还是模拟执行，都要设置超时上限。子进程超时直接 kill，模拟执行靠定时器中断。不设超时的话，用户写个 while(true) 可能把整台设备跑死，这在开发板上是灾难性的。
关于资源占用，Flutter 的 GPU 渲染在 OpenHarmony 上比其他平台更容易发热。如果开发板长时间运行，注意观察 CPU 占用，代码编辑器建议限制日志输出频率，减少不必要的重建。
5. 打包发布与后续演进方向
5.1 产物打包与分发
Flutter for OpenHarmony 的构建产物和原生 OpenHarmony 工程一样，是 HAP 包。整体构建命令，在工程根目录执行 hvigor 相关构建，或者直接通过 DevEco Studio 的 Build 菜单完成。
构建产物会生成在 entry 目录下的 build 文件夹里，是一个 .hap 文件。这个文件可以安装到开发板，也可以后续签名后分发。
签名这一块容易被忽略。OpenHarmony 应用默认需要签名才能安装运行，Debug 构建时 DevEco Studio 自动用调试证书签名，Release 构建则需要配置自己的签名证书。如果直接拿 unsigned 的 hap 用 hdc install，大概率会被拒绝安装。
HAP 包的分发目前主要靠 hdc 安装，或者用系统自带的包管理工具。和 Android 的 APK 安装体验还是有一些差距，这也是生态初期阶段的正常现象。如果你要投放到开发者社区让更多人测试，建议附上安装说明和设备要求。
打包的坑主要集中在资源大小上。Flutter 引擎和 dart 虚拟机体积是硬成本，一个简单 HAP 包可能就有几十 MB。建议开启资源压缩和 AOT 编译，尽量减小包体积。AOT 编译在 OpenHarmony 分支上是支持的，但构建耗时会明显增加，我通常选择在 CI 上跑，本地开发用 JIT 模式。
5.2 后续功能扩展思路
算法练习平台做到这里，已经是一个能用的状态。但就从“软件开发助手”的定位来说，它还能继续往深挖。
一个扩展方向是接入在线题库。目前的题库是本地 JSON，后续可以做一个内容同步服务，让用户从服务端拉取最新题目。数据层我预留了 repository 接口，替换实现成本不高。需要考虑的是网络请求的超时、缓存到本地、离线可用这几个点。
第二个方向是支持更多语言运行。Dart 的本地执行只能解析 Dart 题，但如果想刷 C 语言、Python 的题，就需要在设备上集成对应的运行时解释器。这是一个不小的工程，如果只是想尝鲜，可以接一个远程判题服务，把代码传上去跑。
第三个方向是结合 AI 能力做代码助手。比如在编辑器里加入自动补全和错误提示，用本地小模型或者服务端大模型的接口，实现“卡住了可以问一下”。这个已经超出算法练习的范围，但非常契合“软件开发助手”这个产品名。
第四个方向是考试模式。把刷题变成限时的模拟测试，统计正确率和耗时分布，生成能力雷达图。这个功能在校园和面试准备场景里很有吸引力，技术实现上不需要新的引擎，主要是 UI 层和统计逻辑的扩展。
5.3 一点个人总结
项目做到最后，我更清楚地认识到一个事实：Flutter for OpenHarmony 是能用于实战的，但它更适合业务逻辑重、依赖系统能力少的工具型应用。像算法练习平台这种形态，反而是 OpenHarmony 上最舒服的 Flutter 应用场景之一。
最后再分享一个小技巧。如果你在开发过程中遇到构建失败又找不到头绪，别急着删目录重来。先对比一下项目里 ohos 目录下 build-profile.json5 的 compileSdkVersion 和 targetSdkVersion 是否和实际安装的系统匹配，很多时候问题就出在这个小小的版本号上。
我个人在实际操作中的体会是：在 OpenHarmony 上用 Flutter 做开发，心态上要兼容“快”和“慢”——开发效率比原生 ArkUI 快，但遇到平台底层问题时要有耐心去啃 SDK 和分支源吗。这个项目的完整代码和题库资源我已经整理好了，后续有时间会单独写一篇关于题库资源制作和本地执行引擎细节的文章，感兴趣的可以先自己动手搭一遍。