← 返回作品集
IN-DEPTH CASE STUDY / APPROX. 5 MIN READ

WHIP 个人健康 OS

围绕每天的记录,设计一个本地优先的健康空间。复盘从空白状态到 IndexedDB,再到 PWA 离线与数据恢复的完整路径。

项目性质
个人健康管理应用
我的工作
产品页面 / AI 辅助开发
实现方式
AI 辅助开发与代码核验
阅读路径
背景 → 交互 → 架构 → 验证
WHIP 实际移动端界面,合成 QA 示例记录,原色展示
LOCAL-FIRST / PERSONAL RECORDS
记录,
留在本地。

一次录入、按日回看,
明确保存与恢复的边界。

实际移动端界面,原色呈现;合成 QA 示例记录。

01

项目背景与挑战Context

WHIP 围绕日常健康记录展开:饮食、饮水、运动、身体状态与睡眠频率不同,却需要在同一天被查看。目标用户设定为希望自己保管记录、愿意持续输入日常信息的个人用户。

设计假设是:降低每次录入的步骤,比在首屏堆积更多指标更有价值。因此先把入口安排成今日、饮食、运动、趋势与我的五个模块,再让今日页承担记录入口和当天摘要。

01 / CAPTURE随手录入
02 / STORE保存在设备
03 / REVIEW按日期回看
04 / RECOVER备份与恢复

把空白状态也当作正式界面

新用户的健康空间不预置示例记录。没有录入时显示“等待第一条记录”与明确的行动入口;未知营养数据保留为空值。这样既避免虚构用户状态,也使第一次操作的下一步足够清楚。

我的工作是借助 AI 工具完成产品页面与功能开发,并核对关键计算和保存逻辑。这里呈现的是个人项目实现,不将设计假设写成已经完成的用户研究。
02

设计系统与规范Design system

健康记录的阅读顺序由任务决定:日期和当天摘要先于明细,记录动作靠近相关指标。组件以页面分区、卡片、字段、进度与空白状态复用,避免每类数据形成一套不同的操作语言。

COMPONENT LANGUAGE / STRUCTURE BEFORE DECORATION
今日饮食能量单位 / 目标 / 录入说明
等待第一条记录

没有数据时,给出下一步操作。

已记录 / 每日目标38%
记录一餐
字段标签 / 单位 / 提示
Section · Card · Field · Empty · Progress

上图为原项目组件关系的组件说明。38% 为排版示意,不是任何用户的健康数据。

主动作保持靠近数据

饮食卡片连接“记录一餐”,饮水组件提供固定容量快捷操作,运动状态独立显示开始、暂停与结束。表单通过标签和单位降低歧义,未知值与零值使用不同表达。

原应用提供主题切换,并使用系统字体与语义控件;这份案例以白色透明表面展示结构,不宣称已经获得 Apple HIG 或无障碍认证。

03

核心交互与状态Key interactions

与财富 Pro 的 Canvas 扇区不同,WHIP 的饮水圆盘使用 SVG。这个组件只需要表达一个记录值与目标值的比例,SVG 能用更少的状态保持图形与可访问文本一致。

从比例到弧长

设记录饮水量为 a,目标为 t,比例 p = a / t。圆周长为 2πr;采用 pathLength="100" 后,可以直接把弧长写成百分比。绘制值封顶 100%,文字仍可保留实际比例。

p = t > 0 ? a / t : 0
L = 2πr
pathLength = 100
strokeDasharray = min(100, p × 100) + " 100"
WaterDisc.tsx 的图形半径为 50,内部次级圆为 39。圆盘使用 progressbar 语义,向辅助技术提供实际毫升数与目标。
PROGRESS PRINCIPLE / 交互示意
13%
250 / 2,000 ml

这是圆盘计算的独立演示,不写入健康应用。

把“保存成功”放在反馈之前

记录数据先进入 repository,再写入 IndexedDB。界面通过 useLiveQuery 订阅变化,使今日摘要与记录列表从同一份保存结果更新。启动时若本地数据库不可访问,应用显示重试信息,不把失败包装成成功。

中断后的状态要能够解释

初始化会把仍标记为 active 的运动记录转换为 paused,并保留可用的更新时间。这样,重新打开后不会把关闭页面期间的时间悄悄算成持续运动。

04

架构决策与权衡Architecture

记录属于用户自己的设备,因此项目把 Dexie / IndexedDB 作为主要存储。四张表分别容纳 entries、foods、preferences 与 templates;日期与记录类型的索引承接回看与查询。

REACT / VIEW页面与录入表单

useLiveQuery 订阅保存结果

⇄
REPOSITORY / STORAGEDexie / IndexedDB

记录、食物、偏好、模板

APP SHELLService Worker

缓存页面与必要静态资源

+
RECOVERY PATHJSON 备份与恢复

校验 → 事务写入 → 按 ID 去重

先解决断网记录,再界定同步边界

离线写入直接发生在本地数据库,不需要排队上传。Service Worker 负责应用壳缓存;它解决“页面能否打开”,不负责多端数据冲突。当前项目没有自动跨设备同步。更换设备需要导出与恢复,不能把这条路径描述为“断网重连后自动同步”。

选择解决的任务权衡与边界
IndexedDB结构化记录、索引与事务数据跟随浏览器来源,需考虑容量、清理与备份
JSON 恢复记录迁移与误操作后的恢复路径合并按 ID 跳过已存在记录,不等于双向冲突合并
应用壳缓存缓存就绪后离线打开核心页面首次访问仍需联网;天气与可选模型有独立网络依赖

恢复是一组原子操作

导入先校验数据结构,再用跨表读写事务进行替换或合并。合并时通过 bulkGet 查重,只写入不存在的 ID;替换由界面要求明确确认。非法导入不会作为部分成功写入数据库。

本地优先减少了默认上传健康记录的需求,但不等同于端到端加密。设备丢失、站点数据清理与浏览器存储策略仍是需要面对的风险,因此备份入口属于核心能力。

05

交付成果与验证Impact

交付物包括五个主要模块、结构化本地记录、JSON 备份与恢复,以及 PWA Manifest 和 Service Worker 配置。下面区分项目原有的验证记录与本轮能够直接确认的实现。

已交付

页面、存储与安装配置

React / TypeScript 页面,Dexie 四张表,数据恢复事务;Manifest 设置 standalone,缓存使用更新提示,覆盖必要静态资源。

历史记录

58 项自动测试与多尺寸渲染

项目 TEST_RESULTS.md 的 2026-10-23 记录记载 58/58 测试通过,并记录 380、1280、1440、1920 像素宽度的浏览器渲染。此处引用已有证据,本轮未重新执行应用测试。

历史记录

缓存后的离线保存与重新打开

2026-10-22 记录记载停服后重新打开、保存 250 ml 饮水并浏览五个页面。该记录支持离线使用路径,不能推导所有网络功能都能离线。

尚待实测

真机安装与长期使用指标

iPhone Safari 安装生命周期、存储回收、首次安装完成率与长期留存没有本轮实测结果;因此不展示“安装率”“秒开率”等未经测量的指标。

下一轮验证应围绕实际任务

优先验证三条路径:首次记录是否能独立完成;已有记录能否在断网与重启后保留;更换设备时,备份文件是否能完整恢复。每条路径记录测试环境和失败条件,再形成可比较的基线。

查看实现依据与历史验证记录
继续查看另一项深度案例极简财富 Pro →