独立开发实战:用 ArkUI 做了一个鸿蒙原生的慢性病记录 App「健康手账」
·
起因:我妈的血压数据全靠"感觉"
早上七点,我妈量完血压,把袖带一扔就去厨房忙了。数据?没记。到了月底复诊,医生问"最近血压怎么样",她只能说"还行吧,偶尔高一点"。这个"偶尔"到底是几次、高到多少、吃药有没有漏——全凭感觉。
我之前在 iOS 端做了一个叫「健康手账」的 App 来解决这个问题:让记录足够快,让趋势一目了然,让用药别再靠记忆。今年我决定把它做成 HarmonyOS 原生版本,这篇文章记录一下技术选型、ArkUI 实现以及从 iOS 迁移过来的真实体验。
为什么选择鸿蒙原生而不是套壳
家里长辈用华为手机的比例远超我预期。后台反馈里"什么时候出安卓版"的留言排第一,而这些用户大多数拿的是 Mate 60、nova 系列。既然鸿蒙生态已经跑起来了,与其套壳不如做原生,把分布式能力和原子化服务用上,体验会完全不一样。
一个具体的例子:iOS 版依赖 Apple Watch 做血压趋势通知,迁移到鸿蒙后我用了分布式数据管理配合华为穿戴设备,数据在手机、平板、手表之间自动同步,不用手动导入导出。这比 iOS 上 HealthKit 的单向同步链路灵活得多。
ArkUI 声明式实现:血压分级卡片
记录页的核心交互是"输入数字 → 立刻看到分级色块"。在 ArkUI 里用声明式 UI 写这个逻辑很自然,状态驱动视图刷新不需要手动 reload。下面是血压自动分级卡片的核心实现:
@Component
struct BPGradeCard {
@State systolic: number = 0
@State diastolic: number = 0
get gradeColor(): ResourceColor {
if (this.systolic >= 180 || this.diastolic >= 110) return '#FF3B30'
if (this.systolic >= 140 || this.diastolic >= 90) return '#FF9500'
if (this.systolic >= 130 || this.diastolic >= 85) return '#FFCC00'
return '#34C759'
}
build() {
Column() {
Text(`${this.systolic}/${this.diastolic} mmHg`)
.fontSize(28)
.fontColor(this.gradeColor)
Text(this.getGradeLabel())
.fontSize(14)
.margin({ top: 4 })
}
.padding(16)
.backgroundColor('#1A' + this.gradeColor.toString().slice(1))
.borderRadius(12)
}
}
```
对比 iOS 端 SwiftUI 的实现,ArkTS 的声明式写法上手很快。区别在于布局单位和资源引用方式,但思维模型几乎一致,迁移成本比我预想的低。
## 用药提醒:后台代理提醒 + 依从率统计
用药提醒用了 HarmonyOS 的后台代理提醒(reminderAgentManager),好处是 App 被杀掉后提醒依然准时触发,不像 iOS 本地通知那样在某些机型上被系统节能策略吞掉。
依从率的计算逻辑是:实际服药打卡次数 / 应服药次数 × 100%。我把统计周期做成了 7 天、30 天、90 天三档,长辈复诊时直接给医生看截图就够了。首页用一个环形进度卡片展示这个数据,家属一眼就能看到老人这周吃药是否规律:
```arkts
@Component
struct AdherenceRing {
@Prop rate: number // 0-100
build() {
Stack() {
Circle()
.width(80).height(80)
.stroke('#E0E0E0')
.strokeWidth(8)
Circle()
.width(80).height(80)
.stroke(this.rate >= 80 ? '#34C759' : '#FF9500')
.strokeWidth(8)
.strokeDashArray([this.rate * 2.51, 251])
Text(`${this.rate}%`)
.fontSize(18)
.fontWeight(FontWeight.Medium)
}
}
}
```
## 原子化服务卡片:比 iOS Widget 更适合健康记录
鸿蒙的原子化服务卡片(Service Widget)是我觉得这个项目里最值得聊的能力。iOS 的 WidgetKit 本质是只读展示,交互极其有限;而鸿蒙的服务卡片支持点击区域直接跳转到对应的录入页面,还能在卡片上显示今天的最新一条血压数据和分级状态。
对于我妈这种"量完就想赶紧记一下"的用户,桌面长按 → 看到当前血压状态 → 点一下就进录入页,三秒搞定,不用翻 App 列表。这个交互路径的缩短在健康记录场景里价值很大。
## 家庭多档案与 PDF 报告导出
一个家庭里通常不止一个人需要监测。我做了多档案切换,数据完全隔离。PDF 报告导出功能在鸿蒙端用了系统的文件分享能力,生成后可以直接通过畅连、微信分享给远在外地的子女,或者复诊时用华为分享投到医生的平板上。
## 从 SwiftUI 到 ArkUI:迁移体验实话实说
**上手速度**:有 SwiftUI 经验的话,ArkUI 的声明式写法大概一周能写出完整页面。状态管理的 @State/@Prop/@Link 三件套和 SwiftUI 的 @State/@Binding/@ObservedObject 思路相似。
**布局差异**:ArkUI 没有 GeometryReader 这种灵活但容易写乱的东西,Row/Column/Stack 的嵌套逻辑更直白。我个人觉得在复杂列表页上 ArkUI 比 SwiftUI 的 LazyVStack 更好调试。
**生态能力**:分布式数据、后台代理提醒、服务卡片这三项在健康管理场景里确实好用。iOS 要实现类似功能得组合 CloudKit + UNNotification + WidgetKit,链路更长,限制更多。
**不足**:第三方库生态还在建设中,图表组件我最终自己画的,没有找到成熟度对标 iOS Charts 的库。不过 ArkUI 的 Canvas API 够用,自己画反而更可控。
## 当前状态和后续计划
「健康手账」鸿蒙版目前已经在我家里三台设备上跑了两个月,数据同步稳定,提醒没漏过。接下来计划适配华为健康穿戴数据的自动导入。
项目里还有一些细节,比如趋势图的异常点标注算法、标签关联洞察(吃了某种药后血压变化趋势)的实现思路,后续可以单独写一篇。
如果你也在做鸿蒙开发,特别是 Health Kit 对接相关的,欢迎评论区交流。也可以搜「健康手账」体验一下。
#HarmonyOS开发 #ArkUI实战 #鸿蒙原生应用 #健康管理 #独立开发
更多推荐




所有评论(0)