简介HarmonyOS应用开发入门常因缺乏完整练手项目而止步而记账类应用恰好覆盖了前端UI、状态管理、数据持久化到后端联调的全链路技术栈。本文以个人记账应用为实践载体解析基于ArkTS的界面搭建、本地数据库设计以及AppGallery ConnectAGC的Serverless后端集成方案包括用户认证、云数据库、云函数等核心能力。通过自定义键盘、金额精度处理、聚合统计与Canvas自绘图表等工程细节帮助开发者掌握鸿蒙小应用从编码调试到签名上架的完整闭环。文章还深入探讨了HarmonyOS NEXT版本适配、服务层抽象与本地缓存策略为后续扩展其他应用场景提供了可复用的架构思路。无论您是刚接触鸿蒙开发还是正在寻找实战项目都能从中获得从需求分析到持续维护的全方位参考。 先泼一盆冷水HarmonyOS 开发入门最难的不是 ArkTS 语法也不是 ArkUI 布局而是大多数人根本找不到一个“值得做、做得到、做完有用”的练手项目。市面上教程不是“Hello World”就是“仿某某 App 首页”看着热闹实际跑通后你会发现连数据存储都没碰过更别说后端联调。我自己在 DevEco Studio 里从零写完一个包含用户认证、账单记录、分类管理、统计分析、预算管理的个人记账应用后最大的感受是这个项目几乎覆盖了鸿蒙小应用开发全链路从前端 UI 到后端 AGCAppGallery Connect服务从本地调试到上架打包每一条坑我都替你踩了一遍。这篇文章就把完整的思路、关键代码逻辑、以及那些官方文档里不会写清楚的细节全部拆开讲。1. 记账应用为什么是鸿蒙小应用的最佳练手项目先说结论如果你想在 HarmonyOS 上做一个“小但完整”的应用记账类 App 的性价比是最高的。很多人一开始想做的项目是商城、社交、视频类但这些项目对后端要求极高前端页面动辄几十个一个新手很容易在做到第三个页面时放弃。记账应用的需求边界非常清晰核心就是一个“增删改查”闭环但又不只是简单的增删改查。记账应用覆盖了鸿蒙开发中最常遇到的几个技术点UI 布局账单列表、统计图表、表单页面基本涵盖了 List、Grid、Tabs、Chart 等常用组件的使用场景。状态管理账单数据在列表页、详情页、统计页之间共享需要处理 AppStorage、LocalStorage 或者简单的全局单例。数据持久化本地数据库用关系型库RDB还是首选项Preferences多表关联怎么设计。网络请求与后端联调用户登录态怎么保持、Token 过期怎么办、云函数如何调用。图表可视化统计模块里饼图、折线图、柱状图要么用第三方库要么自己画 Canvas。这个组合意味着你做完一个记账应用基本就掌握了鸿蒙应用开发 80% 的日常工作量。后续再想做任何其他类型的应用骨架都是现成的无非是换一套 UI 和后端数据模型而已。另一个实际原因是需求明确。记账应用的业务逻辑异常清晰不会出现需求边做边变的尴尬。账单的增删改查、分类的维护、统计的聚合查询、预算的对比预警这些功能普通用户都懂不用你费劲脑补产品逻辑可以把全部精力放在技术实现上。2. 开发环境准备与 HarmonyOS 版本矩阵的坑2.1 DevEco Studio 版本选择不要追求最新版开发鸿蒙应用第一道坎就是环境搭建。现在 DevEco Studio 已经出到 5.x 版本对应 HarmonyOS NEXT 5.0 及以上的 API。但这里我建议新手不要一上来就追最新版而是根据你手头设备的系统版本来选择。我自己在项目初期同时接触过两套环境设备/模拟器系统版本推荐 DevEco StudioAPI 级别说明HarmonyOS 4.x兼容 Android 生态4.0 或 4.1API 9 - 10支持 ArkTS 与部分兼容 Android 的第三方库HarmonyOS NEXT 5.0纯血鸿蒙5.0API 12仅支持鸿蒙原生应用不再兼容 Android APK华为电脑自带的 HarmonyOS 系统根据官方兼容列表选-注意华为笔记本的 HarmonyOS 并非移动端系统开发环境参考官方文档确认这里有一个网上很多人问的问题“华为电脑搭载的 HarmonyOS 系统可以安装 Windows 系统吗”答案是部分机型支持但跟本篇文章无直接关系。如果你想把华为电脑用作鸿蒙开发主力机建议直接查官方支持列表不要轻信第三方刷机教程以免变砖。2.2 node-gyp 编译报错最容易被卡住的环节我在开发过程中遇到的最头疼的问题是引入某些依赖时触发 node-gyp 编译报错。虽然 HarmonyOS 应用本身主要用 ArkTS 编写但 DevEco Studio 的构建工具链依赖 Node.js 环境部分原生模块在安装时需要本地编译。具体报错通常是这样的gyp ERR! build error gyp ERR! stack Error: not found: make或者gyp ERR! stack Error: Cant find Python executable python这类问题的根因是 node-gyp 需要本机安装 Python、C/C 编译工具链Windows 下是 Visual Studio Build Tools而很多开发者电脑上并没有完整安装。我的解决建议是优先避免引入需要 node-gyp 编译的依赖。鸿蒙生态里很多库都是纯 ArkTS 或 JS 实现这类库直接通过 ohpm 安装即可。如果确实需要引入Windows 下先安装 Python 3.8并勾选“Add Python to PATH”。安装 Visual Studio Build Tools工作负载勾选“使用 C 的桌面开发”。配置 npm 镜像源避免网络问题导致编译中断。3. 前后端整体架构为什么后端选择 AGC 而不是自建服务器3.1 AGC 提供了什么记账应用的前端架构相对简单ArkTS 编写 UI通过 AGC 提供的 SDK 实现认证、云数据库、云函数。后端我没有自建服务器而是全量使用了 AppGallery Connect 的 Serverless 能力原因很现实零运维成本不用买服务器、配 Nginx、做负载均衡AGC 全部托管。与华为账号体系天然打通用户认证可以使用华为账号一键登录大幅降低注册门槛。免费额度充足个人开发者和学习用途完全够用账单量不大的场景下几乎不会触发计费。前后端同平台管理云数据库、云函数、认证服务在 AGC 控制台统一配置对小程序这种轻量级应用来说效率极高。3.2 数据模型设计记账应用的核心数据模型有三个用户、账单、分类。预算数据我单独建了一张表但查询逻辑上仍然以账单数据为主。用户表结构由 AGC Auth 自动管理我们不需要手动建表。云数据库里需要自己建的是以下几张表账单表bill字段类型说明idString主键自动生成userIdString关联用户 IDtypeInteger0 支出 / 1 收入amountDouble金额单位元categoryIdString关联分类 IDnoteString备注billTimeDate消费时间createTimeDate创建时间分类表category字段类型说明idString主键userIdString归属用户区分自定义分类nameString分类名称iconString图标标识typeInteger0 支出 / 1 收入预算表budget字段类型说明idString主键userIdString归属用户monthString月份格式 yyyy-MMamountDouble预算金额3.3 前后端接口的抽象层设计我并没有在每个页面里直接调用 AGC SDK而是封装了一个 Request 工具类和 BillService / CategoryService / BudgetService 三个服务类统一管理网络请求和本地缓存。这样做的好处是如果后续想把后端从 AGC 换成自建服务器只需要改 Service 层的实现UI 代码完全不用动。// 伪代码示例非完整实现 export class BillService { static async addBill(bill: Bill): Promiseboolean { // 调用 AGC 云数据库插入数据 // 更新本地缓存 } static async getBillsByMonth(month: string): PromiseBill[] { // 优先读本地缓存再请求云端 } }4. 用户认证模块从匿名登录到华为一键登录用户认证是个人记账应用的门面我在这块的方案选型上花了不少时间。4.1 三种登录方式的取舍目前 AGC 认证服务支持多种登录方式我实际测试下来最推荐前两种组合匿名登录用户打开 App 即可使用不需要任何注册流程后端自动生成一个匿名 UID。这个对个人记账应用来说很重要因为绝大多数用户不会为了记账先去注册一个账号。华为一键登录用户在设置里可以“绑定华为账号”绑定后数据就能跨设备同步。这个体验成本最低用户几乎无感知。手机号/邮箱密码登录适合需要跨平台用户的场景但考虑到我们只做鸿蒙小应用华为账号覆盖已经足够。4.2 登录状态管理的关键细节我在开发中踩过的一个坑是匿名登录用户升级为华为账号用户后匿名 UID 会失效导致本地已有数据无法关联到新账号。正确的做法是在升级前先取出匿名用户的本地缓存数据绑定成功后写入新 UID 的账号下然后清理匿名数据。这个逻辑务必在用户绑定账号的流程里做掉不然后续用户数据丢失会非常影响体验。登录状态的持久化我使用了 AGC 提供的 Auth 会话管理SDK 会自动保存 Token 并管理刷新。但需要注意 ArkTS 侧不能直接访问设备 Token 存储必须通过 AGC SDK 提供的接口获取当前登录用户避免自己手写 Token 存储导致的安全隐患。5. 账单记录模块数字输入框、分类选择与金额计算5.1 记账页面的交互设计记账页是整个应用使用频率最高的页面我最终采用了底部弹窗 自定义九宫格键盘的方案。原因很简单系统键盘在输入金额后还需要手动收起然后去点分类多一步操作而记账场景用户就希望“双击打开、选完即走”。自定义键盘的布局就是一个 3x4 的 Grid包含数字 0-9、小数点、删除键和完成键。删除键长按时连续删除这里需要处理定时器避免长按事件重复触发。// 自定义键盘组件部分逻辑伪代码 Entry Component struct NumericKeyboard { onKeyPress: (key: string) void () {} onDelete: () void () {} onConfirm: () void () {} build() { Grid() { // 数字 1-9 // 0、小数点、删除、完成 } } }5.2 金额输入防抖与精度处理金额输入涉及两个关键问题精度问题JS 的浮点数运算会存在精度丢失0.1 0.2 0.30000000000000004记账应用绝对不能直接做浮点加减。我的做法是把金额乘以 100 转换成整数单位分所有逻辑都用整数运算仅展示时除以 100。输入防抖在键盘点击事件里余额、预算、统计三个页面都会实时刷新如果不做防抖频繁点击键盘会导致画面掉帧。我的方案是每次按键后通过 debounce300ms触发账单汇总刷新只有连续停止输入后才计算。5.3 分类管理的实现内置分类 用户自定义分类模块我设计了两种数据来源内置分类首次启动时初始化包括餐饮、交通、购物、居住、娱乐等常见项这部分分类没有 userId 字段值为空字符串所有用户共享。自定义分类用户创建的分类带有 userId查询时按“当前用户 ID 空用户 ID”过滤。分类的图标处理上有一个容易忽略的点内置分类的图标如果使用本地资源图片HarmonyOS 的 resource 目录资源引用是静态的不能根据字符串动态映射。我需要先在代码里建立一个 iconKey 到 resource 的映射表然后通过组件方法获取资源实例。const iconMap: Recordstring, Resource { food: $r(app.media.ic_food), transport: $r(app.media.ic_transport), shopping: $r(app.media.ic_shopping), }6. 统计分析与预算管理从 SQL 聚合到图表渲染6.1 月度统计的聚合查询设计与性能优化统计页需要展示的数据包括月度总支出、总收入、结余、分类占比饼图、近 6 个月收支趋势折线图。整体数据量小的时候直接全量拉取当前用户所有账单在前端做聚合是最简单的。但当账单数据达到几千条以后频繁拉取全量数据就会出现明显的卡顿。我的做法是云数据库端用聚合查询按月份和类型分组只返回统计结果不返回明细。本地加缓存统计结果缓存 5 分钟首次查询后展示用缓存。每月首次打开统计页时先拉一次全量账单用于生成分类占比饼图后续切换月份时直接走云侧聚合。前端拿到聚合结果后构造成图表组件的 series。HarmonyOS 的图表组件有专门的 Chart 组件也可以使用第三方库。我最终选用了轻量级的 Canvas 自绘方案因为在饼图和折线图这两个场景下自绘代码量不大而且可以完全控制交互样式。6.2 预算超支提醒云函数 本地通知预算管理我做了两个功能月度预算设置用户设置当月总预算金额保存到 budget 表。超支预警统计当前月支出金额超过预算的 80% 时在记账页顶部显示黄色横幅超过 100% 时显示红色横幅。超支检测没必要实时监听我的实现是在每次账单新增/修改后前端本地主动检查一次达到阈值就弹本地通知。本地通知需要申请通知权限HarmonyOS 的通知权限弹窗要注意在用户首次使用记账功能时触发不要在启动时触发否则容易被用户拒绝。6.3 统计分析页自绘图表的核心思路折线图的核心计算逻辑是坐标映射// 伪代码 function drawLineChart(values: number[], canvasWidth: number, canvasHeight: number) { const max Math.max(...values) const min Math.min(...values) const stepX canvasWidth / (values.length - 1) // 每个点的 y canvasHeight - (value - min) / (max - min) * canvasHeight }饼图需要把分类金额转成角度百分比注意颜色要预先定义好色板避免相邻分类颜色太接近。7. 兼容性适配、打包与上架经验7.1 HarmonyOS NEXT 5.0 与多端适配前文提到HarmonyOS NEXT 5.0 是一个不兼容 Android APK 的纯血鸿蒙系统这让我在开发时反而更省心——不用考虑 Fragment 迁移之类的历史包袱。但多端适配仍然存在手机、平板、折叠屏的屏幕尺寸不同ArkUI 的响应式布局能力虽然强但页面代码必须有意识地设计。我这边踩到的具体问题是记账页的底部弹窗在平板上宽度过大左右两边留白严重。解决方案是给弹窗内容设置了maxWidth当屏幕宽度超过 600vp 时自动居中并限制宽度为 480vp。7.2 打包签名与上架 AGC 的注意点上架华为应用市场前必须走 AGC 的发布流程其中有几个细节容易踩坑签名证书AGC 后台需要上传.cer证书文件和.p12密钥库跟 Android 的签名机制类似但不完全相同。DevEco Studio 里有专门的“Build Generate Key Store”向导生成的密钥库要严格保存。隐私政策记账应用涉及用户数据收集上架时必须在 AGC 后台填写隐私政策链接否则审核会被拒。版本号版本号不会自动跟随时间戳需要手动修改app.json5里的versionCode和versionName这点我一开始忽略了导致升级测试版本时总是装不上新包。7.3 发版后的持续维护思考这个项目做完后我又回头做了一轮优化把网络请求失败时的本地离线写入机制补上保证用户在无网络环境下记账不丢数据同时增加了账单导出功能可以把自己的记账数据导成 JSON 文件并通过分享组件发送到其他设备。这些小功能对个人应用来说非常实用也让我对整个开发链路理解得更深。8. 写在最后复盘一些值得反复看的设计决策如果你也打算照着这个思路做一个鸿蒙记账应用我个人建议先不用急着照抄代码而是把我前面讲的几个设计决策重新过一遍第一为什么后端用 AGC 而不是自建对个人开发者来说Serverless 能把你从运维中解放出来让你把时间花在业务逻辑上。等你业务量真的大到需要私有化部署时再迁移也不迟因为核心数据模型和服务层接口是通用的。第二为什么从一开始就封装 Service 层鸿蒙生态迭代非常快API 版本变动频繁如果所有页面直接调用 AGC SDK后续升级 SDK 版本时代码改动量会非常大。我封装以后AGC 升级只改了 Service 层的几行代码页面零改动。第三为什么本地缓存和云数据库并存记账类应用的体验核心就是“快”每次打开都去云端拉数据是不可接受的。我采用了本地 RDB 保存最近 3 个月的数据查询时优先走本地只同步增量数据体验上接近本地应用又保留云同步备份的能力。第四为什么要花时间自绘图表鸿蒙生态的第三方图表库选择不多而且适配版本常出问题。我在二维 Canvas 上的自绘方案虽然初期多花了点时间但后续想加什么交互效果都能自己控制不受第三方库限制。最后再分享一个小技巧统计页的自动刷新机制我采用了LocalStorage属性 事件总线的方式记账页每次新增账单后只广播一个「数据变更」事件统计页收到事件后延迟 300ms 重新拉取数据。这个方案比我一开始尝试的AppStorage双向绑定要简单得多也避免了兄弟组件之间传参的繁琐。鸿蒙小应用的数据通信方案选择有时候真的不是越高级越好而是越简单越不容易踩坑。本文还有配套的精品资源点击获取 HarmonyOS开发实战：从零构建鸿蒙记账应用，覆盖AGC、数据存储与上架全流程
简介HarmonyOS应用开发入门常因缺乏完整练手项目而止步而记账类应用恰好覆盖了前端UI、状态管理、数据持久化到后端联调的全链路技术栈。本文以个人记账应用为实践载体解析基于ArkTS的界面搭建、本地数据库设计以及AppGallery ConnectAGC的Serverless后端集成方案包括用户认证、云数据库、云函数等核心能力。通过自定义键盘、金额精度处理、聚合统计与Canvas自绘图表等工程细节帮助开发者掌握鸿蒙小应用从编码调试到签名上架的完整闭环。文章还深入探讨了HarmonyOS NEXT版本适配、服务层抽象与本地缓存策略为后续扩展其他应用场景提供了可复用的架构思路。无论您是刚接触鸿蒙开发还是正在寻找实战项目都能从中获得从需求分析到持续维护的全方位参考。 先泼一盆冷水HarmonyOS 开发入门最难的不是 ArkTS 语法也不是 ArkUI 布局而是大多数人根本找不到一个“值得做、做得到、做完有用”的练手项目。市面上教程不是“Hello World”就是“仿某某 App 首页”看着热闹实际跑通后你会发现连数据存储都没碰过更别说后端联调。我自己在 DevEco Studio 里从零写完一个包含用户认证、账单记录、分类管理、统计分析、预算管理的个人记账应用后最大的感受是这个项目几乎覆盖了鸿蒙小应用开发全链路从前端 UI 到后端 AGCAppGallery Connect服务从本地调试到上架打包每一条坑我都替你踩了一遍。这篇文章就把完整的思路、关键代码逻辑、以及那些官方文档里不会写清楚的细节全部拆开讲。1. 记账应用为什么是鸿蒙小应用的最佳练手项目先说结论如果你想在 HarmonyOS 上做一个“小但完整”的应用记账类 App 的性价比是最高的。很多人一开始想做的项目是商城、社交、视频类但这些项目对后端要求极高前端页面动辄几十个一个新手很容易在做到第三个页面时放弃。记账应用的需求边界非常清晰核心就是一个“增删改查”闭环但又不只是简单的增删改查。记账应用覆盖了鸿蒙开发中最常遇到的几个技术点UI 布局账单列表、统计图表、表单页面基本涵盖了 List、Grid、Tabs、Chart 等常用组件的使用场景。状态管理账单数据在列表页、详情页、统计页之间共享需要处理 AppStorage、LocalStorage 或者简单的全局单例。数据持久化本地数据库用关系型库RDB还是首选项Preferences多表关联怎么设计。网络请求与后端联调用户登录态怎么保持、Token 过期怎么办、云函数如何调用。图表可视化统计模块里饼图、折线图、柱状图要么用第三方库要么自己画 Canvas。这个组合意味着你做完一个记账应用基本就掌握了鸿蒙应用开发 80% 的日常工作量。后续再想做任何其他类型的应用骨架都是现成的无非是换一套 UI 和后端数据模型而已。另一个实际原因是需求明确。记账应用的业务逻辑异常清晰不会出现需求边做边变的尴尬。账单的增删改查、分类的维护、统计的聚合查询、预算的对比预警这些功能普通用户都懂不用你费劲脑补产品逻辑可以把全部精力放在技术实现上。2. 开发环境准备与 HarmonyOS 版本矩阵的坑2.1 DevEco Studio 版本选择不要追求最新版开发鸿蒙应用第一道坎就是环境搭建。现在 DevEco Studio 已经出到 5.x 版本对应 HarmonyOS NEXT 5.0 及以上的 API。但这里我建议新手不要一上来就追最新版而是根据你手头设备的系统版本来选择。我自己在项目初期同时接触过两套环境设备/模拟器系统版本推荐 DevEco StudioAPI 级别说明HarmonyOS 4.x兼容 Android 生态4.0 或 4.1API 9 - 10支持 ArkTS 与部分兼容 Android 的第三方库HarmonyOS NEXT 5.0纯血鸿蒙5.0API 12仅支持鸿蒙原生应用不再兼容 Android APK华为电脑自带的 HarmonyOS 系统根据官方兼容列表选-注意华为笔记本的 HarmonyOS 并非移动端系统开发环境参考官方文档确认这里有一个网上很多人问的问题“华为电脑搭载的 HarmonyOS 系统可以安装 Windows 系统吗”答案是部分机型支持但跟本篇文章无直接关系。如果你想把华为电脑用作鸿蒙开发主力机建议直接查官方支持列表不要轻信第三方刷机教程以免变砖。2.2 node-gyp 编译报错最容易被卡住的环节我在开发过程中遇到的最头疼的问题是引入某些依赖时触发 node-gyp 编译报错。虽然 HarmonyOS 应用本身主要用 ArkTS 编写但 DevEco Studio 的构建工具链依赖 Node.js 环境部分原生模块在安装时需要本地编译。具体报错通常是这样的gyp ERR! build error gyp ERR! stack Error: not found: make或者gyp ERR! stack Error: Cant find Python executable python这类问题的根因是 node-gyp 需要本机安装 Python、C/C 编译工具链Windows 下是 Visual Studio Build Tools而很多开发者电脑上并没有完整安装。我的解决建议是优先避免引入需要 node-gyp 编译的依赖。鸿蒙生态里很多库都是纯 ArkTS 或 JS 实现这类库直接通过 ohpm 安装即可。如果确实需要引入Windows 下先安装 Python 3.8并勾选“Add Python to PATH”。安装 Visual Studio Build Tools工作负载勾选“使用 C 的桌面开发”。配置 npm 镜像源避免网络问题导致编译中断。3. 前后端整体架构为什么后端选择 AGC 而不是自建服务器3.1 AGC 提供了什么记账应用的前端架构相对简单ArkTS 编写 UI通过 AGC 提供的 SDK 实现认证、云数据库、云函数。后端我没有自建服务器而是全量使用了 AppGallery Connect 的 Serverless 能力原因很现实零运维成本不用买服务器、配 Nginx、做负载均衡AGC 全部托管。与华为账号体系天然打通用户认证可以使用华为账号一键登录大幅降低注册门槛。免费额度充足个人开发者和学习用途完全够用账单量不大的场景下几乎不会触发计费。前后端同平台管理云数据库、云函数、认证服务在 AGC 控制台统一配置对小程序这种轻量级应用来说效率极高。3.2 数据模型设计记账应用的核心数据模型有三个用户、账单、分类。预算数据我单独建了一张表但查询逻辑上仍然以账单数据为主。用户表结构由 AGC Auth 自动管理我们不需要手动建表。云数据库里需要自己建的是以下几张表账单表bill字段类型说明idString主键自动生成userIdString关联用户 IDtypeInteger0 支出 / 1 收入amountDouble金额单位元categoryIdString关联分类 IDnoteString备注billTimeDate消费时间createTimeDate创建时间分类表category字段类型说明idString主键userIdString归属用户区分自定义分类nameString分类名称iconString图标标识typeInteger0 支出 / 1 收入预算表budget字段类型说明idString主键userIdString归属用户monthString月份格式 yyyy-MMamountDouble预算金额3.3 前后端接口的抽象层设计我并没有在每个页面里直接调用 AGC SDK而是封装了一个 Request 工具类和 BillService / CategoryService / BudgetService 三个服务类统一管理网络请求和本地缓存。这样做的好处是如果后续想把后端从 AGC 换成自建服务器只需要改 Service 层的实现UI 代码完全不用动。// 伪代码示例非完整实现 export class BillService { static async addBill(bill: Bill): Promiseboolean { // 调用 AGC 云数据库插入数据 // 更新本地缓存 } static async getBillsByMonth(month: string): PromiseBill[] { // 优先读本地缓存再请求云端 } }4. 用户认证模块从匿名登录到华为一键登录用户认证是个人记账应用的门面我在这块的方案选型上花了不少时间。4.1 三种登录方式的取舍目前 AGC 认证服务支持多种登录方式我实际测试下来最推荐前两种组合匿名登录用户打开 App 即可使用不需要任何注册流程后端自动生成一个匿名 UID。这个对个人记账应用来说很重要因为绝大多数用户不会为了记账先去注册一个账号。华为一键登录用户在设置里可以“绑定华为账号”绑定后数据就能跨设备同步。这个体验成本最低用户几乎无感知。手机号/邮箱密码登录适合需要跨平台用户的场景但考虑到我们只做鸿蒙小应用华为账号覆盖已经足够。4.2 登录状态管理的关键细节我在开发中踩过的一个坑是匿名登录用户升级为华为账号用户后匿名 UID 会失效导致本地已有数据无法关联到新账号。正确的做法是在升级前先取出匿名用户的本地缓存数据绑定成功后写入新 UID 的账号下然后清理匿名数据。这个逻辑务必在用户绑定账号的流程里做掉不然后续用户数据丢失会非常影响体验。登录状态的持久化我使用了 AGC 提供的 Auth 会话管理SDK 会自动保存 Token 并管理刷新。但需要注意 ArkTS 侧不能直接访问设备 Token 存储必须通过 AGC SDK 提供的接口获取当前登录用户避免自己手写 Token 存储导致的安全隐患。5. 账单记录模块数字输入框、分类选择与金额计算5.1 记账页面的交互设计记账页是整个应用使用频率最高的页面我最终采用了底部弹窗 自定义九宫格键盘的方案。原因很简单系统键盘在输入金额后还需要手动收起然后去点分类多一步操作而记账场景用户就希望“双击打开、选完即走”。自定义键盘的布局就是一个 3x4 的 Grid包含数字 0-9、小数点、删除键和完成键。删除键长按时连续删除这里需要处理定时器避免长按事件重复触发。// 自定义键盘组件部分逻辑伪代码 Entry Component struct NumericKeyboard { onKeyPress: (key: string) void () {} onDelete: () void () {} onConfirm: () void () {} build() { Grid() { // 数字 1-9 // 0、小数点、删除、完成 } } }5.2 金额输入防抖与精度处理金额输入涉及两个关键问题精度问题JS 的浮点数运算会存在精度丢失0.1 0.2 0.30000000000000004记账应用绝对不能直接做浮点加减。我的做法是把金额乘以 100 转换成整数单位分所有逻辑都用整数运算仅展示时除以 100。输入防抖在键盘点击事件里余额、预算、统计三个页面都会实时刷新如果不做防抖频繁点击键盘会导致画面掉帧。我的方案是每次按键后通过 debounce300ms触发账单汇总刷新只有连续停止输入后才计算。5.3 分类管理的实现内置分类 用户自定义分类模块我设计了两种数据来源内置分类首次启动时初始化包括餐饮、交通、购物、居住、娱乐等常见项这部分分类没有 userId 字段值为空字符串所有用户共享。自定义分类用户创建的分类带有 userId查询时按“当前用户 ID 空用户 ID”过滤。分类的图标处理上有一个容易忽略的点内置分类的图标如果使用本地资源图片HarmonyOS 的 resource 目录资源引用是静态的不能根据字符串动态映射。我需要先在代码里建立一个 iconKey 到 resource 的映射表然后通过组件方法获取资源实例。const iconMap: Recordstring, Resource { food: $r(app.media.ic_food), transport: $r(app.media.ic_transport), shopping: $r(app.media.ic_shopping), }6. 统计分析与预算管理从 SQL 聚合到图表渲染6.1 月度统计的聚合查询设计与性能优化统计页需要展示的数据包括月度总支出、总收入、结余、分类占比饼图、近 6 个月收支趋势折线图。整体数据量小的时候直接全量拉取当前用户所有账单在前端做聚合是最简单的。但当账单数据达到几千条以后频繁拉取全量数据就会出现明显的卡顿。我的做法是云数据库端用聚合查询按月份和类型分组只返回统计结果不返回明细。本地加缓存统计结果缓存 5 分钟首次查询后展示用缓存。每月首次打开统计页时先拉一次全量账单用于生成分类占比饼图后续切换月份时直接走云侧聚合。前端拿到聚合结果后构造成图表组件的 series。HarmonyOS 的图表组件有专门的 Chart 组件也可以使用第三方库。我最终选用了轻量级的 Canvas 自绘方案因为在饼图和折线图这两个场景下自绘代码量不大而且可以完全控制交互样式。6.2 预算超支提醒云函数 本地通知预算管理我做了两个功能月度预算设置用户设置当月总预算金额保存到 budget 表。超支预警统计当前月支出金额超过预算的 80% 时在记账页顶部显示黄色横幅超过 100% 时显示红色横幅。超支检测没必要实时监听我的实现是在每次账单新增/修改后前端本地主动检查一次达到阈值就弹本地通知。本地通知需要申请通知权限HarmonyOS 的通知权限弹窗要注意在用户首次使用记账功能时触发不要在启动时触发否则容易被用户拒绝。6.3 统计分析页自绘图表的核心思路折线图的核心计算逻辑是坐标映射// 伪代码 function drawLineChart(values: number[], canvasWidth: number, canvasHeight: number) { const max Math.max(...values) const min Math.min(...values) const stepX canvasWidth / (values.length - 1) // 每个点的 y canvasHeight - (value - min) / (max - min) * canvasHeight }饼图需要把分类金额转成角度百分比注意颜色要预先定义好色板避免相邻分类颜色太接近。7. 兼容性适配、打包与上架经验7.1 HarmonyOS NEXT 5.0 与多端适配前文提到HarmonyOS NEXT 5.0 是一个不兼容 Android APK 的纯血鸿蒙系统这让我在开发时反而更省心——不用考虑 Fragment 迁移之类的历史包袱。但多端适配仍然存在手机、平板、折叠屏的屏幕尺寸不同ArkUI 的响应式布局能力虽然强但页面代码必须有意识地设计。我这边踩到的具体问题是记账页的底部弹窗在平板上宽度过大左右两边留白严重。解决方案是给弹窗内容设置了maxWidth当屏幕宽度超过 600vp 时自动居中并限制宽度为 480vp。7.2 打包签名与上架 AGC 的注意点上架华为应用市场前必须走 AGC 的发布流程其中有几个细节容易踩坑签名证书AGC 后台需要上传.cer证书文件和.p12密钥库跟 Android 的签名机制类似但不完全相同。DevEco Studio 里有专门的“Build Generate Key Store”向导生成的密钥库要严格保存。隐私政策记账应用涉及用户数据收集上架时必须在 AGC 后台填写隐私政策链接否则审核会被拒。版本号版本号不会自动跟随时间戳需要手动修改app.json5里的versionCode和versionName这点我一开始忽略了导致升级测试版本时总是装不上新包。7.3 发版后的持续维护思考这个项目做完后我又回头做了一轮优化把网络请求失败时的本地离线写入机制补上保证用户在无网络环境下记账不丢数据同时增加了账单导出功能可以把自己的记账数据导成 JSON 文件并通过分享组件发送到其他设备。这些小功能对个人应用来说非常实用也让我对整个开发链路理解得更深。8. 写在最后复盘一些值得反复看的设计决策如果你也打算照着这个思路做一个鸿蒙记账应用我个人建议先不用急着照抄代码而是把我前面讲的几个设计决策重新过一遍第一为什么后端用 AGC 而不是自建对个人开发者来说Serverless 能把你从运维中解放出来让你把时间花在业务逻辑上。等你业务量真的大到需要私有化部署时再迁移也不迟因为核心数据模型和服务层接口是通用的。第二为什么从一开始就封装 Service 层鸿蒙生态迭代非常快API 版本变动频繁如果所有页面直接调用 AGC SDK后续升级 SDK 版本时代码改动量会非常大。我封装以后AGC 升级只改了 Service 层的几行代码页面零改动。第三为什么本地缓存和云数据库并存记账类应用的体验核心就是“快”每次打开都去云端拉数据是不可接受的。我采用了本地 RDB 保存最近 3 个月的数据查询时优先走本地只同步增量数据体验上接近本地应用又保留云同步备份的能力。第四为什么要花时间自绘图表鸿蒙生态的第三方图表库选择不多而且适配版本常出问题。我在二维 Canvas 上的自绘方案虽然初期多花了点时间但后续想加什么交互效果都能自己控制不受第三方库限制。最后再分享一个小技巧统计页的自动刷新机制我采用了LocalStorage属性 事件总线的方式记账页每次新增账单后只广播一个「数据变更」事件统计页收到事件后延迟 300ms 重新拉取数据。这个方案比我一开始尝试的AppStorage双向绑定要简单得多也避免了兄弟组件之间传参的繁琐。鸿蒙小应用的数据通信方案选择有时候真的不是越高级越好而是越简单越不容易踩坑。本文还有配套的精品资源点击获取