Flutter+OpenHarmony实战：家具预算App从数据设计到实机部署

我家去年装修的时候买家具的花费完全失控了。今天翻记账软件明天刷到好看的书桌那几个月钱像流水一样出去到年底一算光硬装之后补充的家具和软装就超了预算快一倍。我那时候就特别想要一个属于自己的、能按改造空间单独记账的小工具——设定一个卧室改造预算每记一笔床、柜子、灯的钱就实时告诉我还剩多少。当时正好在折腾Flutter跨端开发看到OpenHarmony的Flutter支持已经能跑Hello World级别了干脆就把这个需求做成了一个能装到OpenHarmony设备上的App。这篇文章就是这次实战的记录核心是家具购买记录App里添加预算这个功能的完整实现思路从数据库设计、状态管理、UI联动到最终打包到OpenHarmony实机的整个链路。如果你手头正好也想做类似的东西——不管是Flutter跨平台加鸿蒙适配还是想做一个家庭支出记录类的小工具这篇文章应该能帮你少走不少弯路。我不写那种Hello World式的空架子而是直接把真实的业务场景和代码结构摆出来一个预算功能要怎么拆字段、怎么设计更新逻辑、怎么在OpenHarmony上处理那些看起来一样但其实不一样的平台差异。1. 为什么我选 Flutter 而不是 ArkTS 来写 OpenHarmony 应用先聊一个绕不开的问题既然目标是OpenHarmony平台为什么不用官方主推的ArkTS ArkUI非要用Flutter绕一圈坦白说我当时纠结过这个问题。OpenHarmony 的原生开发栈是ArkTS语法长得像TypeScriptUI写法类似声明式布局学习曲线不算陡。但问题是如果你不是第一次接触跨平台开发而是像我一样已经有不少Flutter项目积累那答案就很明显了——我不想为了一个目标平台把通用业务逻辑再写一遍。Flutter for OpenHarmony 的历史说长不长说短不短。OpenHarmony 的 Flutter SIG 团队维护了独立的flutter_flutter仓库把 Flutter 引擎移植到了 OpenHarmony 上另外还有配套的flutter_packages里面是各种常用插件的移植版。到目前为止官方适配版本已经能覆盖相当多日常开发场景Dart代码层面基本能做到同一套代码多端运行。一个人选择Flutter写OpenHarmony应用最大的价值在于如果你团队里已经有 Flutter 技术栈新项目直接复用不需要再养一支 ArkTS 团队。Flutter 的完善状态管理体系和丰富第三方包能大幅提效ArkTS 生态还在成长期很多组件需要自己造轮子。一套代码可以同时出 Android、iOS、Web、Windows、OpenHarmony 多端包。家具购买记录这种轻量工具我以后还能跑在手机和桌面上用。当然ArkTS 不是没有优势。它跟 OpenHarmony 系统能力绑定更深调用系统 API 更直接性能在复杂场景下也更占优。但对家具记录这种中轻度交互应用来说Flutter 的性能绰绰有余开发效率和代码复用率反而是决定成败的。2. 预算功能的需求拆解先想清楚数据怎么走再动手写界面很多新手写添加预算功能上来就画界面画完才发现——预算金额存哪每次记录家具购买之后剩余预算怎么更新超支怎么办这些问题没想清楚代码写一半必然推翻重来。我的习惯是做任何功能前先把数据流在白纸上画一遍。2.1 家具购买记录和预算之间的关系这个App本质上是一个记录-对比模型用户先设定一个总预算比如卧室改造预算 15000 元。之后每买一件家具就录入一条记录名称、分类、价格、购买日期、备注。每录入一条记录已用金额就增加首页的剩余预算跟着减少。当累计支出超过预算时界面要做视觉警示。这个模型很简单数据表只需要两张一张存预算一张存家具记录。预算表字段设计CREATE TABLE budgets ( id INTEGER PRIMARY KEY AUTOINCREMENT, total_budget REAL NOT NULL, created_at TEXT NOT NULL );家具记录表字段设计CREATE TABLE furniture_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, category TEXT NOT NULL, price REAL NOT NULL, purchase_date TEXT NOT NULL, remark TEXT );这里有个细节预算表为什么保存total_budget一个金额就够很多人会习惯性地再加一个remaining_amount字段每次购买时同步减掉。这个设计在底层逻辑上没错但我建议在小项目里不要这么做。原因很简单冗余字段意味着你需要保证每次记录写入时remaining_amount也要同步更新。一旦某次写入崩溃、事务没提交成功或者后来删除了某条家具记录剩余金额就会对不上这时候你就要写对账逻辑。家具购买属于低频操作数据量小每次展示时直接用SUM(price)实时和预算对比走一次索引查询性能毫无压力却换来了逻辑的绝对可靠。注意低频写入场景下实时聚合计算永远比冗余字段缓存更可靠、更省心。如果你的场景是每秒钟几十次流水的高频账本再考虑用缓存字段。2.2 更新预算的三种策略以及我为什么选了第二种预算数据的更新实际操作中无非三种策略策略做法优点缺点A. 实时全局聚合每次展示时SUM所有记录绝对一致无脏数据大数据量下查询略慢B. 查询后内存计算从数据库读总支出在Dart层和预算字段计算差值简单逻辑集中在Provider层需要查库两次预算支出C. 冗余字段缓存预算表存remaining展示快一次查询更新链路复杂易脏数据我在这个项目里选的是B。理由是我需要把剩余预算作为一个暴露给界面的状态值同时也想保留预算总额这个原始数据展示给用户。用一个Provider来做状态管理把计算逻辑收拢到一处界面只消费结果后续想改成策略A只需要改Provider内部实现。如果你未来想做更复杂的分类预算比如客厅3万、卧室1万只需要在furniture_records表里通过category字段做分组聚合预算表结构也不用动太多这是把逻辑集中到Provider里的最大好处。3. “添加预算”功能的实现从状态管理到界面联调这节是整个项目的主菜。我会把核心代码拆开讲包括Provider状态管理、预算设置页面、家具记录录入和剩余预算的联动逻辑。3.1 用 Provider 统一管理预算状态这个App的状态管理我用了provider包理由很简单它足够简单没有Riverpod那一大堆代码生成和编译期检查的门槛而且贴近Flutter原生的InheritedWidget机制新手理解起来不费劲。对于家具记录这种规模的项目ChangeNotifier完全够用。BudgetProvider类承担的数据责任加载预算总额。加载已用金额SUM所有家具记录。计算剩余金额。提供新增记录后刷新数据的方法。class BudgetProvider extends ChangeNotifier { final DatabaseHelper _dbHelper DatabaseHelper.instance; double _totalBudget 0; double _usedAmount 0; bool _isBudgetSet false; double get totalBudget _totalBudget; double get usedAmount _usedAmount; double get remainingAmount _totalBudget - _usedAmount; bool get isBudgetSet _isBudgetSet; Futurevoid loadBudget() async { final budgetRows await _dbHelper.queryAll(budgets); if (budgetRows.isNotEmpty) { _totalBudget budgetRows.first[total_budget] as double; _isBudgetSet true; } await _loadUsedAmount(); notifyListeners(); } Futurevoid _loadUsedAmount() async { final sum await _dbHelper.rawQuery( SELECT SUM(price) AS total FROM furniture_records ); _usedAmount (sum.first[total] as num?)?.toDouble() ?? 0; } Futurevoid saveBudget(double amount) async { await _dbHelper.clearTable(budgets); await _dbHelper.insert(budgets, { total_budget: amount, created_at: DateTime.now().toIso8601String(), }); _totalBudget amount; _isBudgetSet true; notifyListeners(); } Futurevoid onRecordAdded() async { await _loadUsedAmount(); notifyListeners(); } }这段代码的核心是把预算总额和已用金额分开维护在remainingAmount这个getter里算出差值。这样做的好处是UI无需关心计算细节只知道拿remainingAmount去展示就行。3.2 预算设置页数字输入、校验和存储设置预算的页面交互上就两个要素一个输入框用于填金额一个保存按钮。但真正写起来你会发现有几个坑要提前堵住。3.2.1 只能输数字且不允许负数我用TextInputFormatter做输入限制。这是Flutter原生的方案不用引入额外依赖只允许输入小数和数字同时限制小数位不超过两位class BudgetInputFormatter extends TextInputFormatter { override TextEditingValue formatEditUpdate( TextEditingValue oldValue, TextEditingValue newValue, ) { final text newValue.text; if (text.isEmpty) return newValue; final regex RegExp(r^\d{0,7}(\.\d{0,2})?$); if (regex.hasMatch(text)) { return newValue; } return oldValue; } }这个正则的意思是最多7位整数小数点后最多2位。限制7位整数是因为一般家庭装修预算不太可能超过千万级没必要让用户在九宫格键盘上瞎按。3.2.2 保存时实时刷新首页保存按钮点击后调用BudgetProvider.saveBudget()然后弹出成功提示返回到首页时首页通过Consumer自动重建。由于Provider里已经notifyListeners()UI不感知数据加载过程这一步省掉了不少胶水代码。class BudgetSettingPage extends StatefulWidget { override _BudgetSettingPageState createState() _BudgetSettingPageState(); } class _BudgetSettingPageState extends StateBudgetSettingPage { final _controller TextEditingController(); override void dispose() { _controller.dispose(); super.dispose(); } Futurevoid _save(BuildContext context) async { final amount double.tryParse(_controller.text); if (amount null || amount 0) { ScaffoldMessenger.of(context).showSnackBar( const SnackBar(content: Text(请输入有效的预算金额)), ); return; } final provider context.readBudgetProvider(); await provider.saveBudget(amount); if (context.mounted) { Navigator.pop(context, true); } } override Widget build(BuildContext context) { return Scaffold( appBar: AppBar(title: const Text(设置预算)), body: Padding( padding: const EdgeInsets.all(16), child: TextField( controller: _controller, keyboardType: TextInputType.numberWithOptions(decimal: true), inputFormatters: [BudgetInputFormatter()], decoration: const InputDecoration( labelText: 预算金额, hintText: 例如15000.00, prefixText: ¥ , ), ), ), bottomNavigationBar: Padding( padding: const EdgeInsets.all(16), child: ElevatedButton( onPressed: () _save(context), child: const Text(保存预算), ), ), ); } }这个页面的重点在于校验时机——不是在TextInputFormatter里放过一切也不是只在按钮点击时校验而是两者配合输入阶段用正则把畸形输入挡在门外保存阶段再做语义校验负数、0、空值。这样用户体验最平滑。3.3 首页仪表盘剩余预算的可视化展示首页是整个App的门面。我的布局分三块顶部总预算、已支出、剩余金额三个数字并排中部一个进度条显示预算使用百分比下方最近几条家具记录。剩余预算这里我做了一个变色逻辑非常推荐你抄作业Color getBudgetColor(BuildContext context) { if (_remainingPercent 0.6) return Colors.green; if (_remainingPercent 0.3) return Colors.orange; return Colors.red; }进度条用的是Flutter自带的LinearProgressIndicator通过value参数控制比例。要注意LinearProgressIndicator的value必须在0到1之间所以超支场景下要做一个截断转换final double percent provider.totalBudget 0 ? (provider.usedAmount / provider.totalBudget).clamp(0.0, 1.0) : 0.0;超支状态我用文字来额外提示当remainingAmount 0时顶部剩余金额显示为红色并在边上加一个小标签已超支。别用Emoji也不建议用闪光动画这种低频工具需要的是干净直白的反馈。3.4 录入家具记录后自动联动预算家具记录录入完成后要触发首页的预算刷新。我在录入页保存成功后调用await provider.onRecordAdded(); Navigator.pop(context, true);onRecordAdded会重新SUM所有记录。这里有个细节如果我每次添加记录后都通知Provider刷新但用户停留在录入页没回到首页首页其实已经 rebuild 过一次了。这个损耗很小不值得为了优化增加逻辑复杂度。但真正值得注意的是如果你用Navigator.pop(context, true)的返回值来通知首页刷新而不是由Provider自己驱动那你要保证Provider的生命周期在整App内唯一。我用的是ChangeNotifierProvider包住MaterialApp而不是在某个页面内部创建Provider这样即使页面销毁了预算状态还活着。提示在Flutter里用Provider管理全局状态时Provider的挂载位置一定在MaterialApp上层否则你在Navigator跳转后会拿不到同一个Provider实例或者创建出多个数据副本。4. 跑在 OpenHarmony 上Flutter环境配置与工程适配到这里代码逻辑已经在Android模拟器上完全跑通接下来进入最折腾的部分——把它真的打包到OpenHarmony设备上。这个过程本身就是一个踩坑集锦我详细说一下具体步骤。4.1 准备 OpenHarmony 的 Flutter SDK普通Flutter SDK是不认识OpenHarmony的你需要去拉OpenHarmony SIG维护的flutter_flutter仓库。OpenHarmony的Flutter支持基于几个分支我这次用的是适配Flutter 3.22的分支。具体操作git clone https://gitee.com/openharmony-sig/flutter_flutter.git cd flutter_flutter git checkout v3.22.0-chips打开仓库里的flutter --version确认能跑起来同时记得把flutter_flutter/bin配进PATH。这个仓库和主流的Flutter SDK在命令上与使用习惯上基本一致只是底层引擎换成OpenHarmony的实现。另外还要装OpenHarmony的开发工具DevEco Studio它用来打开和管理工程里的轻量级容器相关配置以及最终上传哈包到设备。4.2 用--platformsohos生成/适配工程项目最开始创建的时候我用的命令是flutter create --platformsandroid,ios,ohos ./如果你的项目之前只创建了Android目录想补上OHOS支持也可以手工在工程根目录执行同样的命令它会自动生成ohos目录。这个目录是OpenHarmony工程的主目录负责配置应用权限、包名、签名信息等二进制应用元数据。工程生成之后实际的跨平台业务代码都在lib/目录完全不用动。这也是Flutter for OpenHarmony方案的一大爽点Dart代码基本做到一次编写所有平台共享。4.3 打包哈包HAP并安装到设备编译OpenHarmony安装包的命令跟Android形态类似flutter build hap --debug构建完成后生成的HAP文件在build/ohos/app/outputs目录下。把它装到设备上有两种方式用DevEco Studio的Run按钮直接部署到已连接的开发板或模拟器命令行用hdc工具HDC是OpenHarmony的命令行调试工具类似ADBhdc list targets hdc install path-to.hap如果你的设备没连接成功先检查开发者模式有没有开以及HDC的驱动问题——这点和Android很像很多莫名的设备连接问题靠重插线和切换USB模式就能解决。4.4 插件适配sqflite 换成了 sqflite_common_ffi项目中最离不开的插件是SQLite。标准sqflite在OpenHarmony上还没有官方完整的原生实现如果你直接pub get大概率会因为缺少对应平台的插件而编译失败。我当时的做法是改用sqflite_common_ffi。这个包通过FFIForeign Function Interface直接调SQLite的C API不依赖Android/iOS原生层天然适合OpenHarmony这种新平台。迁移成本非常低只需要在数据库初始化时替换一行import package:sqflite_common_ffi/sqflite_ffi.dart; void main() { // 检测当前平台为OpenHarmony时使用FFI版本 if (Platform.operatingSystem ohos) { sqfliteFfiInit(); databaseFactory databaseFactoryFfi; } runApp(const FurnitureApp()); }Platform.operatingSystem的值我查了一下在OpenHarmony设备上会返回字符串ohos。如果这里的判断不生效也可以换用defaultTargetPlatform但那个返回的类型枚举不包括OpenHarmony所以还是判断operatingSystem字符串最可靠。除了sqflitepath_provider也需要留意。OpenHarmony下有移植版但首次运行有概率拿不到文档目录我的解决办法是在初始化时做一个本地路径兜底String getDatabasePath() { try { final dir await getDatabasesPath(); return dir; } catch (e) { return /data/app/el2/100/base/com.example.furniture/database; } }这个过程里你可能会发现不少 pub.dev 的包在OpenHarmony上的适配状态参差不齐如果插件作者没做平台注册大概率编译不过。一个务实的判断标准是优先选纯Dart实现的包其次选有OHOS适配文档的包最后才考虑自己写Channel桥接原生代码。5. 实机调试中的兼容性问题三个让我印象深刻的坑整个适配过程中说没有坑是假的。这里挑三个最有代表性的问题如果你准备把Flutter App搬到OpenHarmony上这几个坑大概率也会遇到。5.1 底部安全区算不对页面被系统手势条挡住第一个问题是首页仪表盘下面那条记录列表在OpenHarmony设备上跑起来之后最后一条记录会被底部的系统手势指示条挡住点击不到。这个问题在Android上通常用SafeArea或者MediaQuery.of(context).padding.bottom就能解决但OpenHarmony上返回的值明显偏小。我排查的过程是这样的先在真机上打印MediaQuery.of(context).padding.bottom的数值发现是0但视觉上明显有非零的安全区域。这说明OpenHarmony在Flutter引擎这一侧的ViewPadding上报有差异。调试后采用的是双保险方案在Scaffold底部用bottomNavigationBar放一个普通容器同时给列表区域主动填充SafeArea并在需要精细控制的地方手动加一个bottom: 20的固定间距兜底。虽然这个方案不够优雅但在新平台适配初期设计上多做一层冗余反而稳定。注意遇到新平台上的系统UI适配问题时不要完全依赖MediaQuery的默认值自己打印一遍真实返回值再补一层手动间距兜底是快速见效的做法。5.2 输入法弹出后页面被顶乱键盘显示区域高度异常预算设置页面里有一个金额输入框。在OpenHarmony真机测试时我点输入框弹键盘整个页面在键盘弹出时出现了两个问题一是背景顶上去输入框看不见二是键盘关闭后布局没能弹回来像卡住了一样。这里归根到底是resizeToAvoidBottomInset这个属性在新引擎上有兼容性问题。Flutter的默认设置是当键盘弹出时会自动调整Scaffold的高度但OpenHarmony的引擎部分场景上报的高度值和实际不符导致布局计算错乱。我的解决方案是把输入类页面的Scaffold单独设置Scaffold( resizeToAvoidBottomInset: Platform.operatingSystem ohos ? false : true, ... )然后在OpenHarmony上通过AnimatedPadding手动监听MediaQuery.viewInsets.bottom来垫高页面底部内容。代码大约是这样AnimatedPadding( duration: const Duration(milliseconds: 200), padding: EdgeInsets.only(bottom: MediaQuery.of(context).viewInsets.bottom), child: ... )这个方案在Android上不起作用但能保证OpenHarmony下的交互基本正常至少不会再出现键盘顶乱页面的情况。5.3 字体渲染和中文绕排的小差异最后一个坑很细节同样的Text组件同样的字号和行高OpenHarmony上中文文字的行高明显比Android更紧凑导致两行文字贴得过紧甚至某些字符稍微被截断了一点点。排查后确定不是代码问题而是OpenHarmony默认字体和Flutter文本引擎的line-height计算差异造成的。我做了一个全局处理在MaterialApp主题里显式指定中文字体族和行高倍率ThemeData( fontFamily: sans-serif, textTheme: const TextTheme( bodyMedium: TextStyle(fontSize: 14, height: 1.5), bodyLarge: TextStyle(fontSize: 16, height: 1.5), ), )这样至少能保证列表页和仪表盘的排版不死板再配合maxLines和overflow: TextOverflow.ellipsis的常规处理家具名称长一点也不会把布局撑破。6. 这个App的后续扩展方向分类预算与数据导出最终版跑通之后我自己用了大概一个月记了十来笔家具购买记录体验下来比原来的记账软件顺手很多。不过在使用中我也发现了一些可以继续扩展的点如果你要抄作业这几个方向值得考虑。一是分类预算。我现在记录的家具其实分餐厅、卧室、书房几个空间场景但预算只有一个总金额。如果想要每个空间单独设上限SQL层面上只要把家具表的category字段利用起来SUM时按分类做GROUP BY即可。Provider里分别维护一个MapString, double就能承载。这个改动不算大但实用价值提升非常明显。二是数据导出。没有导出的记录工具等于数据黑洞。OpenHarmony上可以用share插件调起系统分享生成CSV文件发送给自己。CSV格式用Excel直接打开毫无压力每个月导出一份和预算复盘搭配起来非常好用。要注意的是OpenHarmony的分享插件适配不如Android完美部分设备的系统分享面板只支持部分文件类型导出前先真机验证一下。如果有时间做成多设备同步其实更爽——手机端记录平板端看报表。但这就涉及后端数据同步、离线缓存、冲突合并一系列复杂问题对家具购买这种低频场景来说性价比不高我暂时没有做。我在实机调试里最深的一个体会是跨平台开发最麻烦的从来不是Dart语法或者Provider怎么用而是每个平台在系统UI细节、文件路径、字体渲染上那些看似相同实则不同的地方。好在你一旦把这些差异抽象到独立的工具层后续再适配其他平台就都是填表格的活儿了。最后分享一个我这套项目里最满意的小技巧所有平台相关的判断代码我全部收在一个platform_adapter.dart文件里暴露出来的接口只有isOHOS、getDatabasePath、bottomSafeHeight这几个参数。以后哪怕要加Windows、加macOS我的业务层代码一行都不用改只需要往这个adapter文件里补适配逻辑。强烈推荐你也养成这个习惯能让多端维护省出大把时间。