Flutter for OpenHarmony开发油耗追踪器：跨端移植与CSV导出实战

最近用 Flutter for OpenHarmony 做了一款油耗追踪器 App，名字叫 FillUp，核心功能就三件事：快速记录每次加油数据、自动算百公里油耗、一键导出 CSV 文件。项目做完以后回头梳理，发现这套组合踩的坑远比想象中多，尤其是 OpenHarmony 工程接入、真机联调和 CSV 中文乱码这几个环节，每一处都足够单独写一篇复盘。这篇文章就把完整过程拆开讲，从技术选型到落地细节都有，适合正在试 Flutter for OpenHarmony 开发、或者想给自己的小工具 App 加导出功能的开发者参考。

1. 项目背景与技术选型思路

1.1 加油记录这个需求，到底在记录什么

油耗追踪器这类工具看起来简单，实际一细想就知道坑不少。车主真正需要的是每次加油时记下三个核心数值：当前里程表读数、加油升数、加油金额，然后由 App 算出两次加油之间的百公里油耗。如果加油时顺手记了单价，还能顺便统计每公里通勤成本。这些数据最好是长期累积的，因为单次油耗受路况、空调、油价影响波动很大，只有跑够几千公里以后，平均油耗才有参考价值。

市面上的油耗记录 App 不是不好，而是数据封闭在厂商服务器里，想导出来做二次分析非常麻烦。有的甚至强制登录、天天推广告。自己做 FillUp 的理由就两条：数据完全在自己手里，导出 CSV 后能用 Excel、Python 等任何工具分析。另外一个私心是正好赶上 OpenHarmony 生态起来了，想试试 Flutter 在非 Android 系统上的跨端表现。

这个项目的目标用户画像也清晰：有一定动手能力、对数据有掌控欲的车主，以及正在研究 OpenHarmony 应用开发的开发者。对前者来说，FillUp 是一个完全本地化、可导出数据的记录工具；对后者来说，它是一个跨端移植的参考样例。

1.2 为什么选 Flutter for OpenHarmony 这套组合

先说结论：如果只给 OpenHarmony 设备做应用，用 ArkUI 当然最省事，但如果你手头已经有一个 Flutter 项目，或者想一套代码同时覆盖 Android、iOS、OpenHarmony，那 Flutter for OpenHarmony 就是当前最值得尝试的路线。

OpenHarmony 的 ArkUI 声明式开发风格其实学习成本不高，但它跟 Flutter 最大的区别在于生态。Flutter 拥有全球范围内庞大的第三方包生态，OpenHarmony 这块还在早期。而 flutter_for_openharmony 这个项目，本质上是把 Flutter 引擎移植到了 OpenHarmony 系统上，让 Dart 代码可以直接跑在鸿蒙内核之上，同时复用的是 Flutter 的渲染引擎和 Widget 体系，意味着你之前写的 Flutter UI 代码基本不用改。

我这次选型的核心判断有三点：

• 团队技术沉淀复用：如果团队之前用 Flutter 写过 App，迁移到 OpenHarmony 时不需要重新学一套 UI 框架，业务逻辑、状态管理、数据层都可以照搬。
• 生态依赖支持度：Flutter 常用的 json_annotation、path_provider、shared_preferences 等包大多有对应的 OpenHarmony 适配版本，社区也在持续跟进。相比原生鸿蒙生态，Flutter 侧的可选方案更多。
• 避免厂商锁定：ArkUI 的应用基本只能在 OpenHarmony 系设备上跑，而 Flutter 代码可以随时反向编译到 Android、iOS、Web 等多个平台，数据层和 UI 层的代码资产都不浪费。

当然也有代价。最大的代价是 flutter_for_openharmony 目前主要支持 OpenHarmony 标准系统设备（RK3568、RK3588 开发板，以及部分已适配的手机和平板），轻量系统设备基本不用考虑。另外，个别 Flutter 插件在 OpenHarmony 上的实现还不完整，需要自己补平台通道。这是生态早期不可回避的问题，后面会详细讲。

1.3 整体设计思路和页面规划

FillUp 的整体设计遵循“够用就好”的原则，没必要为了炫技堆页面。最终确定的信息架构是三个页面：

• 记录列表页：按时间倒序展示所有加油记录，直接显示本次油耗和花费，列表顶部展示累计里程、平均油耗、总花费三个统计卡片。
• 添加/编辑页：表单形式，必填项为当前里程、加油升数、加油金额，选填项为日期和备注。里程和金额输入框在失去焦点后自动计算油耗。
• 导出页：实际上是一个半屏底部弹窗，展示可导出的数据范围（全部记录/近一年）、文件编码选项，点击导出后显示结果路径。

状态管理方面，这种小工具类的 App 完全不需要引入 Bloc 或 Riverpod 这种重量级方案，ChangeNotifier 加 setState 就够用了。我倾向于把数据层单独拆出来，用 Repository 模式封装本地数据库操作，这样以后想加云同步、定时提醒，都不需要动 UI 层代码。

2. 开发环境搭建与 OpenHarmony 工程接入

2.1 环境组件清单与版本匹配

环境配置这一步最容易翻车，因为 flutter_for_openharmony 的版本分支和 OpenHarmony SDK 版本是强绑定的，用错版本会有各种奇怪报错。我这里列出的是实测可行的组合：