尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
HarmonyOS运动健康——饮食记录页面
饮食记录是运动健康App的能量管理页。用户从首页点击饮食记录或从个人中心菜单跳转到这里查看今天吃了什么、摄入了多少卡路里、还剩多少热量配额。这个页面的任务是让用户对吃了什么有量化的认知——不是感觉吃多了而是今天已经摄入1570千卡还剩630千卡。页面结构分为三部分顶部导航栏、卡路里摘要卡片、饮食记录列表。从总览到明细信息从宏观到微观。完整效果主色的变化这个页面的主色不是红色#FF4757而是橙色#FF9F43const A: string #FF9F43整个App的主色是红色但饮食页面切换到了橙色。这不是随意的——红色代表运动步数、训练橙色代表食物卡路里、饮食。颜色和语义绑定用户看到红色联想到动看到橙色联想到吃。这种颜色分工在首页就有铺垫步数环是红色卡路里环是橙色。导航栏的按钮Row() { Row() { SymbolGlyph($r(sys.symbol.chevron_left)).fontSize(20).fontColor([T1]) }.width(34).height(34).borderRadius(17).backgroundColor(rgba(0,0,0,0.03)) .justifyContent(FlexAlign.Center).onClick(() { router.back() }) Text(饮食记录).fontSize(20).fontWeight(FontWeight.Bold).fontColor(T1) .margin({ left: 10 }).layoutWeight(1) Text().fontSize(24).fontColor(A).fontWeight(FontWeight.Bold) }.width(100%).padding({ left: 16, right: 16, top: 12, bottom: 8 })导航栏右侧是一个橙色的“按钮——暗示添加新记录”。但没有绑定onClick点击不会弹出添加表单。和社区页面的发布按钮、个人中心的编辑按钮一样UI元素存在但交互未实现。卡路里摘要卡片Row() { Column() { Text(this.total.toString()).fontSize(36).fontWeight(FontWeight.Bold).fontColor(A) Text(已摄入/千卡).fontSize(11).fontColor(T3) }.alignItems(HorizontalAlign.Center).layoutWeight(1) Row() {}.width(1).height(40).backgroundColor(#F0EEF4) Column() { Text(630).fontSize(36).fontWeight(FontWeight.Bold).fontColor(#00B894) Text(剩余/千卡).fontSize(11).fontColor(T3) }.alignItems(HorizontalAlign.Center).layoutWeight(1) }.width(100%).padding(20).backgroundColor(#FFFFFF).borderRadius(16) .margin({ left: 16, right: 16, bottom: 16 })摘要卡片是一个白色圆角Row分成左右两部分左边橙色显示已摄入热量右边绿色显示剩余热量。中间用1px宽的灰色竖线分隔。这种已用/剩余的双列设计和首页的数据环异曲同工——首页用三个环展示步数/卡路里/运动时间饮食页用两列展示已摄入/剩余热量。都是让用户一眼看到我做了多少和还差多少。数字的硬编码State total: number 1570已摄入热量1570千卡是State变量但没有动态计算——不是把四条餐饮记录的cal加起来。手动算一下3804502205201570数字刚好对得上。但这是因为手动凑的不是公式算出来的。如果用户新增一条记录total不会自动更新。剩余630千卡是直接写死的字符串不是变量。15706302200——这暗示每日热量目标是2200千卡。但2200这个数字没有在代码中定义藏在硬编码的减法里。实际项目应该定义一个DAILY_TARGET 2200常量然后remaining DAILY_TARGET - total。饮食记录列表数据模型interface Meal { icon: string; name: string; cal: number; time: string }四个字段图标、名称、卡路里、时间。和社区页面的Post接口一样精简——没有餐次分类早/午/晚、没有营养成分明细蛋白质/碳水/脂肪、没有食物图片。原型阶段够用。State meals: Meal[] [ { icon: , name: 燕麦牛奶 鸡蛋, cal: 380, time: 早餐 8:00 }, { icon: , name: 鸡胸肉沙拉, cal: 450, time: 午餐 12:30 }, { icon: , name: 香蕉 蛋白粉, cal: 220, time: 加餐 16:00 }, { icon: , name: 牛排 西兰花, cal: 520, time: 晚餐 19:00 }, ]四条记录覆盖早餐、午餐、加餐、晚餐。时间从8:00到19:00符合正常的饮食节奏。emoji图标和食物类型对应——燕麦、鸡肉、香蕉、牛排。单条记录的结构Row() { Text(m.icon).fontSize(28).width(48).height(48).borderRadius(12) .backgroundColor(#F5F5F7).textAlign(TextAlign.Center) Column() { Text(m.name).fontSize(14).fontWeight(FontWeight.Bold).fontColor(T1) Text(m.time).fontSize(11).fontColor(T3).margin({ top: 2 }) }.alignItems(HorizontalAlign.Start).margin({ left: 12 }).layoutWeight(1) Text(m.cal 千卡).fontSize(14).fontWeight(FontWeight.Bold).fontColor(A) }.width(100%).padding(12).backgroundColor(#FFFFFF).borderRadius(14)每条记录是一个白色圆角Row左边emoji图标48×48浅灰圆角方块、中间食物名称和时间、右边卡路里数值。图标容器用borderRadius(12)——不是圆形24而是圆角方块12。和社区页面的44×44圆形头像不同饮食记录的图标是方形带圆角。这种差异是有意的头像用圆形亲和力食物图标用圆角方块规整感。卡路里数值用橙色加粗——和摘要卡片的已摄入颜色一致。用户看到橙色就联想到热量不管在摘要区还是列表区。ScrollColumnForEachScroll() { Column({ space: 10 }) { ForEach(this.meals, (m: Meal) { // 餐食卡片 }) Blank().height(20) }.width(100%).padding({ left: 16, right: 16 }) }.width(100%).layoutWeight(1)和社区页面、个人中心一样的模式Scroll包裹ColumnColumn用space控制间距ForEach渲染列表最后加Blank底部留白。这个模式在整个App中反复出现——它已经成为ArkUI列表渲染的标准写法。页面间的数据关系饮食记录和首页的卡路里环有数据关联——首页显示今天的卡路里消耗饮食页显示今天的卡路里摄入。消耗-摄入净热量差这是减肥的核心公式。但当前两个页面的数据是独立的首页的卡路里来自WEEKLY_DATA[3].calories运动消耗饮食页的total是硬编码的1570食物摄入。两者没有计算差值。实际项目中应该有一个统一的能量管理服务运动消耗从运动记录获取食物摄入从饮食记录获取净热量差消耗-摄入。首页可以展示这个差值让用户知道今天运动消耗了800千卡吃了1570千卡净摄入770千卡。踩坑记录主色的语义化选择。饮食页用橙色#FF9F43作为主色A而不是App默认的红色#FF4757。这导致A的含义在不同页面不同——在首页A是红色运动在饮食页A是橙色食物。如果以后要抽公共组件不能假设A一定是红色。更好的做法是定义语义化常量COLOR_EXERCISE和COLOR_FOOD而不是用A统一。total和meals的数据不同步。State total 1570是独立变量不从meals数组计算。如果以后加了添加/删除餐食的功能total需要手动更新。应该用getter动态计算get totalCalories(): number { return this.meals.reduce((sum, m) sum m.cal, 0) }。但ArkUI的Component不支持getter语法需要在aboutToAppear中计算或用State配合手动更新。剩余热量的硬编码。630千卡是直接写在build方法里的字符串不是变量。如果每日目标变化比如从2200改成2000需要同时改total的初始值和这里的630。两处修改容易遗漏。应该定义常量const DAILY_TARGET 2200然后remaining DAILY_TARGET - this.total。“”按钮的交互缺失。导航栏右边的“暗示添加”但没有onClick。用户点击后没有反馈。真实项目应该弹出一个添加表单——选择食物、输入卡路里、选择时间。但表单组件的实现复杂度远超当前原型。餐食卡片没有删除/编辑功能。每条记录只能看不能改。如果用户录错了比如把380千卡写成3800没有修正途径。原型阶段够用但真实产品必须有滑动删除或长按编辑。饮食记录是运动健康App中能量管理的另一半——首页展示消耗饮食页展示摄入。两者结合才能回答用户最关心的问题我今天吃多了还是吃少了从技术角度看这个页面的亮点在于颜色语义化——橙色代表食物和红色代表运动形成对比。这种颜色分工让页面在视觉上就有了运动vs饮食的区分用户不需要读文字就能理解页面主题。
RELATED

相关推荐

儿童情绪识别技术:多模态融合与CNN优化实践

儿童情绪识别技术:多模态融合与CNN优化实践

最近在开发一个儿童教育应用时,我遇到了一个棘手的问题:如何准确识别和处理儿童在使用过程中的恐惧情绪。传统的情绪识别模型往往针对成人设计,当面对孩子夸张的表情、不稳定的情绪表达时,识别准确率直线下降。这让我意识到&#…

📅 2026/11/14 7:48:11
GPT-5.6 写代码太烧钱?Agent 场景 3 个能立刻落地的降本点

GPT-5.6 写代码太烧钱?Agent 场景 3 个能立刻落地的降本点

GPT-5.6 发布,但 Agent 场景依旧「烧 token」 2026 年 7 月 9 日,OpenAI 发布 GPT-5.6,命名从过去的 mini / nano 换成 Sol / Terra / Luna 三档。官方 API 定价(每百万输入 / 输出 tokens)大致如下: 档位…

📅 2026/9/18 18:02:08
存储金字塔性能量化:从寄存器到硬盘,速度与容量相差10^9倍的秘密

存储金字塔性能量化:从寄存器到硬盘,速度与容量相差10^9倍的秘密

存储金字塔性能量化:从寄存器到硬盘的十亿倍速度差异解析存储金字塔的层级结构与性能特征计算机系统中的存储设备构成了一个典型的金字塔结构,从顶部的寄存器到底部的机械硬盘,每一层都在速度、容量和成本之间做出不同的权衡。这个存储层次结…

📅 2026/9/18 18:11:22
MORE NEWS

更多资讯

📰

电工证如何投标良心建议

电工证如何投标良心建议 现在找工作,没有特种作业证,连面试资格都拿不到。尤其是电工证,几乎是很多工程类岗位的硬门槛,像开封的应届生,想找电工相关工作,没证根本进不了门。 良心建议…

📰

工地太忙根本没时间复习考试?桂林电工证报考入口保姆级教程来了

工地太忙根本没时间复习考试?桂林电工证报考入口保姆级教程来了 工地太忙根本没时间复习考试?你不是一个人。作为安阳劳务班组的负责人,我知道你们每天都在和时间赛跑,既要赶工期,又要确保安全合规。桂林电工证报考入口是很多一线电工必须面对的流程,但…

📰

合肥电工证报名网址在哪考?外省证能转吗?看完这篇全明白了

合肥电工证报名网址在哪考?外省证能转吗?看完这篇全明白了 之前考的证在外省能不能转过来?这是很多准备在合肥考电工证或者已经在外地考了证的朋友最关心的问题。别急,这篇讲清楚【合肥电工证报名网址在哪考】,帮你避开那些看不见的坑。…

📰

电工证上岗证合格率低怎么考?通过率揭秘让你少走弯路

电工证上岗证合格率低怎么考?通过率揭秘让你少走弯路 怕考不过白交培训费?这年头,电工证上岗证合格率低的问题,让很多人头疼不已。报名前满心期待,结果一考试就被现实打脸,培训费打水漂,时间也白费。今天,我从周口培训机构的实际案例出发,带你搞懂【…

📰

重庆审电工证的电话官方回应:学历不高也能考,关键看这个

重庆审电工证的电话官方回应:学历不高也能考,关键看这个 你是不是也担心学历不高报不了电工证?别急, 重庆审电工证的电话 已经给出官方回应,学历不是门槛,但要选对流程和机构。下面我用实操经验,把报考、考试、避坑这些事说清楚,让你少走弯路。…

📰

电工证危险吗保姆级教程:实操考试心里没底怕挂科怎么破

电工证危险吗保姆级教程:实操考试心里没底怕挂科怎么破 你是不是也这样?每次听说要实操考试,心里就直打鼓,担心自己操作不规范,搞不好就挂科了。尤其是像我们这种干工程的,电工证是刚需,但考试不通过,不仅耽误事,还影响收入。今天这波【电工证危险吗…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬