HarmonyOS智慧农业成本核算系统开发实战

刚把第十二篇的代码合进主分支，我坐在电脑前对着屏幕缓了口气。做这个 HarmonyOS 智慧农业系列到第十二篇，从环境搭建写到设备管理、农事记录、生长监控，说实话前几篇更多是在搭骨架、铺流程，写起来相对“顺”。但这篇成本核算系统不一样，它真正要处理的是一个让我自己都觉得有点棘手的问题：怎么在手机端把农业生产里那些琐碎、零散、没规律的开销管理起来，让用户能看清每一笔钱花在了哪里。

开头先交代一下背景。这个系列叫“高高种地”，是我在业余时间维护的一个 HarmonyOS 应用开发项目，核心思路是把农业生产场景搬进手机，让种植户、小型农场主不用天天拿纸笔记账，也不用对着 Excel 发愁。成本核算系统是这套管理应用里非常关键的一个模块——毕竟无论种什么、养什么，最终都要落到“赚不赚钱”。但真打开代码去写的时候才发现，成本核算并不是“录入一笔钱、加个总数”那么简单，它牵扯到分类体系、数据持久化、统计口径、图表展示，以及大量的交互细节。

这篇文章算是这个模块的实战开发记录。我会从业务设计、数据模型、数据库操作、核心页面实现到统计图表，把整个成本核算系统的开发过程拆开讲，顺便把踩过的坑和优化思路一并放出来。适合正在做 HarmonyOS 应用开发、但又不太确定业务模块怎么落地的朋友，也适合那些已经在做农业信息化、想参考移动端交互设计的同行。

1. 成本核算的业务设计与技术选型

1.1 需求拆分：农业成本到底要核算什么

在动笔写代码之前，我先把需求翻来覆去地捋了一遍。农业生产成本不像工厂物料清单那样固定，它的特点是：分类杂、波动大、周期性长、跟地块和作物强绑定。一个普通大棚种植户，一年下来可能涉及种子种苗、化肥、农药、地膜、人工、水电、机械作业、运输等十几个类别的开销，而且同一笔支出往往还要关联到具体的地块或大棚。

所以我在设计这版成本核算系统时，没有直接套用通用记账软件的“收入—支出”大分类，而是围绕农业场景做了定制。第一版规划的核心功能包括：

• 成本录入：记录每一笔开销，包括类型、金额、日期、关联地块、备注；
• 成本分类：预设农业常用的大类和小类，同时允许用户自定义；
• 成本统计：按时间段、按分类、按地块进行汇总，能算清某一茬作物累计投入；
• 数据展示：通过列表和图表让用户直观看到成本构成与变化趋势。

还有一个很重要的隐含需求：离线可用。田间地头网络不稳定是常态，所以成本记录的增删改查必须全部走本地数据库，不上云也能用。

1.2 存储选型：为什么不用首选项而是关系型数据库

HarmonyOS 应用开发里，轻量级数据存储有两个常见选择：首选项（Preferences）和关系型数据库（RelationalStore）。首选项适合存配置类的键值对，比如“是否开启通知”“上次选中的地块编号”，但如果拿它来存成本记录，很快就发现问题：没法按条件查询、没法聚合汇总、数据量大了性能扛不住。成本记录天然是结构化数据，每一笔都有类型、金额、时间等多维属性，必须用数据库管理。

我选的是 HarmonyOS 的关系型数据库（RDB），理由也很实在：

• 支持 SQL 语法，可以方便地做 WHERE 过滤、GROUP BY 分组、SUM 汇总；
• 数据容量和查询性能完全够用，几千条成本记录毫无压力；
• 事务机制保证了批量操作的安全性；
• API 设计相对清晰，文档也比较全。

1.3 整体架构：单模块还是独立分包

考虑到应用还在持续迭代，我最终把成本核算相关代码放到了一个独立的 feature 模块里，和农事记录、设备管理等项目保持同级的包结构。这样做的好处是后续如果把它拆成独立工程或者移植到别的项目，代码可以直接搬走。整个模块的代码路径大概是这样的：

entry/src/main/ets/ ├── feature/ │ └── cost/ │ ├── model/ │ │ ├── CostRecord.ets │ │ └── CostCategory.ets │ ├── database/ │ │ └── CostDbHelper.ets │ ├── view/ │ │ ├── CostListPage.ets │ │ ├── CostAddPage.ets │ │ ├── CostStatsPage.ets │ │ └── components/ │ └── viewmodel/ │ └── CostViewModel.ets

这种分层不是瞎分的。model 层管纯数据结构，database 层管数据库读写，viewmodel 层在中间做数据加工和状态管理，view 层只负责 UI 渲染和用户交互。每个文件职责单一，出了 BUG 也好定位。

2. 数据模型与数据库层实现

2.1 成本记录表设计：字段怎么定才够用

表结构是整个系统的基础，我调整了三版才最终定稿。第一版只设计了类型、金额、日期三个字段，写了一半发现根本不够用——统计时需要知道钱花在了哪个地块，种的是什么作物，是直接买的东西还是人工费用。最终确定的数据表如下：

这里有两个设计细节值得说一下。第一，cost_date 存的是时间戳而不是“2025-06-18”这样的字符串，因为时间戳在区间过滤（比如查“6月到8月”的记录）和排序时都更高效，也更不容易格式出错。第二，amount 用的是 REAL 浮点类型，这在正式账务系统里会被喷“不严谨”，但对于农业生产记账场景是够用的，而且 HarmonyOS RDB 的 REAL 类型在 API 使用上很顺手。后面我会单独讲金额精度的问题。

2.2 数据库初始化与建表脚本

HarmonyOS 关系型数据库的使用，第一步是配置 StoreConfig 并拿到 RdbStore 实例。我在 CostDbHelper 里封装了完整的初始化和建表逻辑，防止多个页面重复创建连接。

import { relationalStore } from '@kit.ArkData'; import { common } from '@kit.AbilityKit'; const DATABASE_NAME = 'high_farm.db'; const TABLE_COST = 'cost_record'; export class CostDbHelper { private static rdbStore: relationalStore.RdbStore | null = null; // 获取单例 store，避免每次操作都重新建立连接 static async getStore(context: common.Context): Promise<relationalStore.RdbStore> { if (this.rdbStore) { return this.rdbStore; } const config: relationalStore.StoreConfig = { name: DATABASE_NAME, securityLevel: relationalStore.SecurityLevel.S1 }; this.rdbStore = await relationalStore.getRdbStore(context, config); await this.initTables(); return this.rdbStore; } private static async initTables(): Promise<void> { const sql = `CREATE TABLE IF NOT EXISTS ${TABLE_COST} ( id INTEGER PRIMARY KEY AUTOINCREMENT, cost_type TEXT NOT NULL, cost_name TEXT NOT NULL, amount REAL NOT NULL, land_id TEXT, crop_type TEXT, cost_date INTEGER NOT NULL, remark TEXT, create_time INTEGER )`; await this.rdbStore?.executeSql(sql); } }

这里有个容易被新手忽略的点：getRdbStore 是异步接口，而且同一个数据文件重复调用会复用连接，但文档里并没有明确说“全局只需要调一次”。如果每个页面都自己调一次，在高频切换页面时容易出现连接竞争。所以我直接把 store 做成静态单例，整个应用生命周期里只初始化一次。另外建表用了IF NOT EXISTS，这样即使重复调用也不会报错。

2.3 增删改查的封装思路

数据库操作是高频调用点，我选择把常用的增删改查全部封装成异步方法，对外暴露简洁的接口。插入一条成本记录的代码大致如下：

export interface CostRecord { id?: number; costType: string; costName: string; amount: number; landId?: string; cropType?: string; costDate: number; remark?: string; createTime: number; } export async function insertCost(context: common.Context, record: CostRecord): Promise<number> { const store = await CostDbHelper.getStore(context); const values: relationalStore.ValuesBucket = { 'cost_type': record.costType, 'cost_name': record.costName, 'amount': record.amount, 'land_id': record.landId ?? '', 'crop_type': record.cropType ?? '', 'cost_date': record.costDate, 'remark': record.remark ?? '', 'create_time': record.createTime }; const rowId = await store.insert(TABLE_COST, values); return rowId; }

查询方面，我用得最多的是按日期范围分组统计，SQL 写法是：

SELECT cost_type, COALESCE(SUM(amount), 0) AS total FROM cost_record WHERE cost_date BETWEEN ? AND ? GROUP BY cost_type ORDER BY total DESC

这个查询直接返回按成本大类汇总的结果，配合折线图、饼图使用非常方便。RDB 的查询接口支持executeQuery和querySql，我通常用querySql写原生 SQL，因为它更直观、更容易排查问题。

3. 核心功能模块实现：从列表到录入页

3.1 成本列表页：日期分组与卡片化展示

成本列表页是整个模块的门面，用户一进来看到的就是它。我的设计思路是：按月份分组展示，同一个月内的记录聚合到一组，组内按日期倒序排列。每一条记录用卡片形式展示，左上角是成本图标，中间显示项目名称和分类，右侧是金额，底部可以显示地块和备注。

页面数据流用的是 ViewModel 模式。ViewModel 负责从数据库拉数据，再加工成 UI 需要的结构。我定义了一个MonthGroup结构体来承载分组数据：

export interface MonthGroup { monthLabel: string; dateRange: string; totalAmount: number; records: CostRecord[]; }

加载列表的核心逻辑是这样的：先查出全部记录（按日期倒序），再在内存里做分组。虽然也可以直接在 SQL 里按月份分组，但那样后续做展开收起动画时还要再补数据，反而不如全量加载后在内存分组灵活。成本记录的数据量级是几千条，全量加载在真机上测试过，耗时基本可以忽略。

3.2 成本录入页：表单交互与数据校验

录入页是用户操作最多的界面，交互设计上要尽量减少输入成本。我用的是“顶部选择分类 + 中部填金额 + 底部选日期和地块”的布局。分类选择用了横向滚动的胶囊按钮，用户点一下即可切换，减少下拉选择层级。

页面里最核心的状态管理是这样组织的：

@Component struct CostAddPage { @State selectedType: string = '农资'; @State costName: string = ''; @State amountText: string = ''; @State selectedDate: number = Date.now(); @State selectedLandId: string = ''; @State remark: string = ''; // ... }

别人看到这段代码可能觉得平平无奇，但这里其实藏着一个坑：@State修饰的变量所有变化都会触发 UI 刷新，如果costName每敲一个字符就刷新整页，输入框可能因焦点丢失而变得非常难用。我一开始直接在TextInput的onChange里做this.costName = value，实测发现多行输入时会偶发卡顿和焦点跳动。后来优化了结构，把表单区域拆成独立的子组件，让输入框只在自己组件内部刷新，问题就解决了。

提交时要做三层校验：金额必填且大于 0；项目名称不能为空；日期不能晚于今天（否则会出现“能记录未来支出”这种逻辑错误）。校验通过后调插入方法，成功则返回列表页并自动刷新。

3.3 日期选择：用 DatePickerDialog 还是自定义弹窗

日期选择组件我踩了一次坑。最初用的是DatePickerDialog，在 API 9 上跑得好好的，但升级到 API 11 后发现一个边界问题：如果用户从今天开始往前翻到几年前，月历视图的联动偶尔会卡顿。排查后发现是onDateAccept回调里更新日期状态时，又触发了列表页面刷新，导致两边的状态互相挤压。

最终做法是：DatePickerDialog 只负责选日期，选完后单独写入一个状态，同时把日期转成“yyyy-MM-dd”格式展示在按钮上，不触发列表刷新。这样从录入页跳回列表页时，列表只在 onPageShow 时刷新一次。

日期格式化的代码我单独抽了个公共函数：

export function formatDate(timestamp: number): string { const date = new Date(timestamp); const year = date.getFullYear(); const month = (date.getMonth() + 1).toString().padStart(2, '0'); const day = date.getDate().toString().padStart(2, '0'); return `${year}-${month}-${day}`; }

3.4 统计报表页：从 SQL 到可视化的完整链路

统计页是整个系统最体现“核算”价值的地方。我做了一个三 Tab 的布局：合计概览、分类占比、月度趋势。合计概览展示选定时间范围内的总投入、总笔数、日均支出；分类占比用饼图展示成本构成；月度趋势用柱状图展示逐月变化。

这些图表我最初想引入第三方图表库，后来发现 HarmonyOS 生态里可选的图表库并不多，与其纠结引入，不如先用 Canvas 自绘。自绘的好处是彻底避免依赖冲突，而且可以完全按设计稿来调颜色和布局。我做的第一版饼图是用CanvasRenderingContext2D的arc方法画扇区，每一块用不同颜色填充，中间留出空白放文字标签。

private drawPieChart(context: CanvasRenderingContext2D, items: CostStatItem[]): void { const total = items.reduce((sum, item) => sum + item.totalAmount, 0); let startAngle = -Math.PI / 2; const centerX = this.chartWidth / 2; const centerY = this.chartHeight / 2; const radius = Math.min(this.chartWidth, this.chartHeight) / 2 - 20; items.forEach((item) => { const angle = (item.totalAmount / total) * 2 * Math.PI; context.beginPath(); context.moveTo(centerX, centerY); context.arc(centerX, centerY, radius, startAngle, startAngle + angle); context.closePath(); context.fillStyle = item.color; context.fill(); startAngle += angle; }); }

柱状图的自绘逻辑类似，主要是算好坐标轴和每根柱子的矩形位置。这一块工作需要细心，因为 Canvas 的坐标系和日常的页面布局坐标系不太一样，Y 轴方向是向下的，坐标换算错了，柱子的位置就全乱了。

4. UI 状态管理与页面联动的几个细节

4.1 列表页与录入页的数据联动

成本核算系统里最容易出问题的地方是数据联动：用户新增了一笔成本返回列表页，列表必须立刻显示新数据；用户在统计页切换了时间范围再切回来，数据也要同步刷新。

我用的方案是页面生命周期刷新。列表页在onPageShow里重新加载数据，而不是依赖上一个页面传值或全局事件。这样做的好处是简单可靠，坏处是如果数据量大，每次返回都全量刷新会影响性能。实测下来，几千条数据在本地 RDB 里的查询耗时只有几十毫秒，全量刷新完全可接受。

onPageShow(): void { this.reloadData(); }

这里我想强调一个实践原则：在移动端本地数据库场景中，简单直接的刷新策略往往比复杂的增量更新更稳。除非列表数据上了万条，否则没必要为了省那几十毫秒牺牲架构的简洁性。

4.2 状态管理的分层：哪些用 @State，哪些只做本地变量

HarmonyOS 的 ArkUI 状态管理有一套自己的规则，用熟了很顺手，但一开始容易用错。我的经验是：影响 UI 渲染的变量才用@State修饰，比如列表数据、选中的分类索引、加载状态；不直接影响 UI 的临时变量，比如某个计算中间值，就老老实实放在普通成员变量里，不要过度状态化。

还有一种场景是子组件需要修改父组件的状态。比如统计页里每个图表卡片是一个子组件，用户切换图表时间范围时，需要通知父组件重新查数据。我用的是@Link双向绑定，或者通过回调函数onRangeChange抛给父组件。两种方式都可行，具体选择取决于数据流的复杂度。当前项目里回调函数的方式更直观，我在代码里也是这么用的。

4.3 列表滚动与吸顶标题的体验优化

成本列表按月分组后，月份标题如果能吸在顶部，用户浏览起来会轻松很多。HarmonyOS 的List组件本身提供了sticky属性支持粘性标题，默认是List.StickyStyle.None，改成List.StickyStyle.Header就可以让分组标题固定在顶部。

这个属性一开始我完全没注意到，直到真机测试时发现标题跟着内容一起滚走了，才回头查文档。所以说多看官方 API 文档真的能少走弯路，特别是 ArkUI 这种快速迭代的框架，很多好用的能力都在文档里躺着，没用到就是浪费。

5. 统计口径与金额计算：别让数字骗了你

5.1 成本归集逻辑：一次性投入和长期摊销怎么区分

农业成本和其他行业的成本最大的不同在于：有大量“一次性投入但受益期很长”的项目。比如一栋大棚的棚膜，可能用三年；一套滴灌设备，能用五年。如果把这些钱全部算进当年成本，当年的利润就被严重低估了，而后续年份的报表又会显得成本过低。

在我这个第一版成本核算系统里，采用了相对朴素的方案：不做严格的折旧摊销，而是通过“成本大类”来区分。一次性消耗品（种子、化肥、农药）直接计入当月；长期资产类（设备购置、棚体建设）单独建一个分类“基础设施”，在统计时单独展示，不参与当期的成本利润率计算。这样虽然不够会计学严谨，但对用户来说直观易懂，不会误导决策。

5.2 浮点数精度：REAL 类型到底安不安全

这是成本核算系统绕不开的问题。用 REAL 存金额，理论上会出现 0.1 + 0.2 ≠ 0.3 的经典尴尬。但在实际业务中有多严重？我测试过：如果只是单笔记录，显示个位数小数点基本没问题；但如果是累计求和，比如算“上半年化肥总支出”，几千笔记录累加后误差可能积累到几分钱。

对于农业记账场景，几分钱的误差在界面上可能会引起用户的质疑。我采取的缓解方案是：所有涉及金额汇总的计算，先乘以 100 转成整数进行累加，最后再除以 100 转回。

export function sumAmount(records: CostRecord[]): number { let totalCents = 0; for (const record of records) { totalCents += Math.round(record.amount * 100); } return totalCents / 100; }

这样处理后，汇总结果在分这一位上就是精确的，不会出现 0.30000000000000004 这种让人摸不着头脑的显示值。

5.3 统计口径的坑：空值字段要不要参与分组

成本记录里的 crop_type 和 land_id 是可选字段。统计时如果按地块分组，没有关联地块的记录怎么处理？我一开始没处理，导致统计页出现了一个“空”分组，数字还特别大，用户看到一脸懵。

后来我在 SQL 查询里专门处理了空值：

SELECT CASE WHEN land_id = '' THEN '未关联地块' ELSE land_id END AS land_label, COALESCE(SUM(amount), 0) AS total FROM cost_record WHERE cost_date BETWEEN ? AND ? GROUP BY land_label

这种细节如果不做，真机测试时可能都发现不了，因为测试数据往往填得很完整。但只要一交给真实用户，空值就冒出来了。做统计功能的通用法则：先想好空值、重复值、极值怎么处理，再写 SQL。

6. 常见问题与排查技巧实录

6.1 数据库连接失效：为什么页面 A 拿到的 store 是空的

有段时间我遇到一个诡异的问题：从列表页跳转到添加页，添加页里调用插入方法时报错“database is no longer open”。排查了半天，发现是添加页里又调了一次getRdbStore，而这次调用是在页面销毁后的回调里发起的，RdbStore 已经关闭了。

解决方案就是前文提到的单例模式。只要全应用只维护一个 store 实例，并且统一通过 Helper 类访问，就不存在不同页面各自持有连接的问题。

6.2 列表刷新后滚动位置丢失

列表数据刷新后，滚动条总是跳回顶部。如果用户正在看 5 月份的记录，添加一笔 3 月份的成本返回后列表刷新，滚动位置被重置到最新月份，体验很割裂。

我用的解决办法是记录当前滚动位置，刷新后恢复。List组件的scroller对象提供了currentOffset()和scrollToIndex(targetIndex)两个方法。在刷新前记录第一个可见分组的索引，刷新后调用scrollToIndex跳回去。代码逻辑不复杂，但很能提升实际使用体验。

6.3 图标和颜色怎么处理才不显得廉价

成本分类的图标和配色，看起来是视觉问题，其实直接影响统计页的可读性。我给每个大类固定了一套颜色和图标：农资用绿色，人工用橙色，机械用蓝色，运输用紫色。这样在饼图里，用户只要记住颜色，就能快速对应分类，不需要每个扇区都去读文字标签。这个决策来自我观察真实用户使用测试版时的反馈——给分类做颜色记忆关联后，统计图的解读效率提升很明显。

HarmonyOS 里使用系统资源图标很方便，SymbolGlyph组件配合资源符号，可以快速指定图标名称和颜色，不占包体积。这也是比较推荐的做法，比用本地图片资源更灵活。

6.4 真机调试时数据库文件怎么导出检查

成本核算系统的数据对不对，光看界面有时候不够，我通常会把数据库文件从真机导出来，用 SQLite 工具直接检查表结构和数据。HarmonyOS 应用沙箱里的数据库文件路径一般在/data/storage/el2/database/entry/rdb/下。

真机调试时，通过 DevEco Studio 的 “File Manager” 视图可以直接拉到沙箱文件。如果拉了但没权限，就需要设备开开发者模式之后，用 hdc 命令行工具拷贝：

hdc shell run-as com.example.highfarm cat /data/storage/el2/database/entry/rdb/high_farm.db > local_high_farm.db

这个技巧在我排查“金额为什么对不上”的问题时发挥了关键作用——面包屑排查法里，最底层的数据永远是最可信的。

7. 一些真实的使用反馈和迭代方向

7.1 种菜的大爷说“我要看每亩花了多少”

成本核算系统发给几个真实用户测试后，收到一个特别有代表性的反馈：一位大棚种植户问我，“你这个统计只能看总共花了多少钱，但我想知道我的西红柿一亩地花了多少”。这个需求本质上是“单位面积成本”，也就是把成本总额除以面积，得到亩均成本。不同地块面积不一样，只有算成亩均成本，才能横向比较哪个大棚的投入更合理。

这个功能我准备在下一版里实现。实现本身不难：在地块表里加一个 area 字段，统计时把对应地块的成本汇总除以面积即可。难点在于部分成本是多个地块共用的，比如一车肥料施给了两个棚，怎么分摊？这个业务规则需要产品层面先定义清楚，代码反而简单。

7.2 预算对比：从记账到控制

成本核算系统做到后面，记账只是基础能力，更值钱的是“预算对比”。用户年初给某块地设定一个预算上限，比如 5000 元，系统实时显示已经花了多少，剩余多少，在接近预算上限时给出提醒。这样成本系统从一个被动记录工具，变成了主动的管理工具，价值感知会强很多。

HarmonyOS 侧要实现这个能力，只需要在现有表结构上加一个 budget 表和一张成本汇总视图。但交互上需要注意：预算提醒不能做成弹窗轰炸，否则用户会烦。比较温和的做法是在列表页顶部用一条进度条展示预算占用情况，进度条变红表示超支，绿色表示健康。

7.3 多端协同的可能性

因为我用的是 HarmonyOS 应用，后续有考虑做平板端的适配。成本录入在手机上做，但月度成本分析报表在大屏上看会舒服很多。平板端主要改布局：列表页改成双栏，左侧是分组列表，右侧是选中月份的成本构成详情。这种布局改动在 ArkUI 里用GridRow组件就能实现，平板和手机共用一套代码，根据断点切换排列方式。

不过这些都属于“以后再说”的部分，当前这版先把手机端的成本核算链路彻底跑扎实，后面扩展才有地基。写代码这事儿就是这样，不能老想着一步到位，把当前模块做深做透，才是对后续迭代最大的帮助。

我现在合上这段代码，脑子里其实还转着几个问题：成本分摊规则怎么定才能既科学又不让小农户算糊涂账？图表组件要不要在后续版本里换成性能更好的轻量方案？统计分析页的加载速度还能不能再优化？这些问题大概率会在第十三篇里给出答案。如果你也在做 HarmonyOS 应用开发，或者对智慧农业软件设计有兴趣，欢迎拿这篇里的字段设计和统计口径做参考，有问题评论区聊。