企业官网建设流程全解析

1. 为什么做这个App：饮食推荐的真正痛点在哪里

1.1 市面上的工具缺了哪一环

做这个安卓健康养生饮食推荐系统App的直接起因，是身边一位长辈体检报告出了几项临界值，拿着单子问我：血压偏高、血脂偏高，一天三顿到底该吃什么。这个问题我当场回答不了，翻了半天应用商店里的工具，也没找到一个能真正回答的。记卡路里的App只告诉你这一顿"吃了多少"，搜菜谱的App只会按关键词吐一堆菜名，能不能吃、为什么合适、搭配是否均衡，全靠用户自己判断。

我要的是这样一个闭环：用户填一次基本信息，系统算出他每天大概需要多少热量和营养素，再结合口味偏好、过敏原、忌口条件，生成未来一周的三餐推荐方案，并且每一道菜都能说清楚"为什么推荐给你"。这才是推荐系统该做的事，而不是把数据库里几百道菜按热度排个序就叫推荐。

市面上缺的恰恰是这一环。卡路里计数器解决的是"记录"问题，菜谱社区解决的是"找菜"问题，而大部分人的真实需求是"明天到底吃什么、怎么吃才对身体友好"。这个需求需要把营养学计算、食物数据库、用户画像和推荐算法串起来，属于典型的轻量级推荐系统，规模不大，但涉及的技术点很全：数据建模、规则引擎、算法调参、Android客户端工程化。

1.2 目标用户到底是谁

我给自己划定的目标用户不是泛泛的"所有人"，因为面向所有人做产品最容易做成没人用的产品。第一版主要覆盖三类人群：

第一类是体重管理人群，以25到40岁的上班族为主，想减脂或控制体重，但不会算热量，也没时间每天精心备餐，需要的是"照着做就行"的周计划。第二类是亚健康调理人群，40岁以上，体检报告里出现血压、血脂、血糖的临界值，想在饮食上做调整，又不信任网上那些互相矛盾的养生文章。第三类是有明确饮食禁忌的人，比如海鲜过敏、乳糖不耐受、痛风需要控制嘌呤摄入等，普通菜谱App根本拦不住这些雷，而系统的推荐必须从源头避开。

这三类人群有一个共同特征：他们缺的不是信息，而是"被筛选过、可直接执行"的方案。用户打开App的第一诉求永远是"今天吃什么"，而不是"我想看看营养学的书"。所以产品的主路径必须极短——填完问卷，立刻给出一周方案，每餐有菜名、有食材、有做法要点。

1.3 第一版我刻意砍掉的功能

做个人项目最容易犯的错是贪多。我第一版明确砍掉了四个东西：拍照识别食物、社交社区、中医体质诊断、以及任何形式的疾病干预建议。拍照识别需要训练模型，数据量和维护成本都不小，这个后面当扩展方向，不影响核心链路。社区功能会诱导用户刷内容，和"吃得健康"这个目标并不一致。中医体质诊断这种模块，如果没有专业资质背书，很容易变成伪科学，第一版绝不碰。

至于疾病干预建议，这是合规红线，一个字都不能越界。App只能基于公开的营养学通用公式做饮食推荐，比如根据身高体重年龄估算基础代谢，再根据活动量给全天热量目标，这属于通用的营养参考方法。App里所有的推荐结果都标注了"仅供参考，不能替代医生或注册营养师的意见"。把边界划清楚，产品才站得住。

明确了要做什么、不做什么，后面所有技术选型就都有了判断标准。

2. 客户端技术栈：Kotlin + Compose + MVVM的实际落地

2.1 为什么选Compose而不是传统XML

客户端框架选型，我基本没有犹豫，直接用了Kotlin + Jetpack Compose。原因很实际：这个App的界面大量依赖"动态状态"——推荐列表要随用户画像变化、营养进度要实时更新、打卡后要立刻刷新，用Compose的声明式UI来写，状态变化驱动界面重建，逻辑会清爽很多。如果继续用传统的XML + ViewBinding，我大概要多写两倍以上的模板代码，尤其在列表项多样、卡片状态多的时候。

当然Compose也有它的脾气。第一个版本我用的是稳定版，但中间经历过一次依赖版本大升级，Compose编译期和运行期版本不一致直接导致界面渲染异常，这种问题在传统View时代是不存在的。所以我的建议是：个人项目用Compose没问题，但务必将compose编译器版本和Kotlin版本绑定好，别混用alpha、beta通道的版本，否则排查问题会非常消耗耐心。

2.2 工程分层：MVVM、Repository与Hilt

项目结构我采用了标准的MVVM分层，包名组织大致是这样的：

data/ local/ // Room数据库、DAO、实体 repository/ // 仓库层，统一暴露数据给ViewModel domain/ // 推荐引擎、营养计算等纯逻辑 ui/ screen/ // Compose页面 viewmodel/ // 各页面的状态容器

ViewModel持有UI状态，通过StateFlow暴露给Compose页面；页面只做展示和事件分发，不直接操作数据库。Repository层把本地数据库和远端配置源都封装起来，这样上层完全不关心数据从哪来。依赖注入用的Hilt，好处是彻底告别手动管理Repository实例的生命周期，测试的时候也能很方便地替换为假数据源。

这个分层一开始可能觉得啰嗦，但等推荐逻辑开始变复杂之后，你会发现它的价值：推荐引擎是纯Kotlin代码，不依赖Android框架，所以在JVM上直接写单元测试，跑完一套测试用例只需要几秒钟，不用启动模拟器。如果当初把推荐逻辑全写在Activity或者ViewModel里，测试成本会成倍增长。

2.3 本地优先与后台任务

饮食记录是非常私人的数据，而且用户经常在食堂、地铁等信号不好的场景使用，所以我定了"本地优先"的架构。Room数据库存所有核心数据：用户画像、食材库、食谱库、打卡记录。第一次联网时从服务端拉取最新的食谱知识库，之后完全离线可用。服务端只负责版本化发布食谱更新和匿名统计数据，不做强制联网要求。

每日提醒用WorkManager实现，Daily提醒在WorkManager里就是PeriodicWorkRequest，最小间隔是15分钟，对"每天提醒一次"这种需求完全够用。但要注意，WorkManager不是精确闹钟，它可能会被系统延迟几分钟甚至更久。如果是"晚上八点半必须弹打卡提醒"，那得用AlarmManager的精确闹钟，配合Android 12以上版本的精确闹钟权限申请。我在第一版用的是WorkManager加系统通知，实测下来绝大多数用户能准时收到，但确实有极端场景会延迟，这个后面在踩坑章节细说。

3. 营养知识库与数据建模：推荐系统的地基

3.1 食材、食谱、用户三张核心表

推荐系统的质量上限由数据质量决定，这句话在饮食领域尤其成立。我先设计了三张核心表：食材表、食谱表、用户画像表。

食材表的核心字段长这样：

CREATE TABLE food ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, category TEXT, -- 谷物、蔬菜、水果、肉蛋奶、豆制品等 calories_per_100g REAL, -- 千卡/100克 protein_per_100g REAL, fat_per_100g REAL, carb_per_100g REAL, fiber_per_100g REAL, sodium_per_100g REAL, -- 毫克/100克 edible_rate REAL, -- 可食部比例，0-1 unit_type TEXT, -- RAW_GRAM 或 COOKED_GRAM source_ver TEXT -- 数据来源版本 );

食谱表存菜品信息和做法步骤，字段包括难度、耗时、适合季节、做法标签（蒸、煮、炒、炖）、口味标签（清淡、少油、少盐、微辣）。食谱和食材通过一张中间表关联，每一行记录"这道菜需要哪种食材多少克"。这样推荐引擎才能根据食谱的食材构成，精确计算出一道菜每份的营养贡献，而不是在食谱表里拍脑袋填一个"每份热量"。

用户画像表存的是推荐系统的输入。除了性别、年龄、身高、体重、活动量等级这些基础项，还要存目标（减脂、增肌、维持、控制三高类指标）、过敏食材ID列表、不喜欢的食材ID列表、偏好标签列表。注意过敏和不喜欢是两回事，前者是硬约束，后者是软偏好，引擎处理逻辑完全不同。

3.2 单位换算与可食部：一个很容易翻车的细节

营养数据建模里最容易翻车的三个细节：千卡和千焦的换算、生重和熟重的区别、可食部比例。

第一个坑：国内很多食物成分数据表习惯用千焦（kJ），而App计算用的是千卡（kcal），两者换算系数是1 kcal = 4.184 kJ。如果数据源混用，同一道菜的热量算出来能差一倍，用户看到一天"消耗了两千多千卡"会觉得App疯了。我的处理是：在数据导入层统一转成千卡，并且把"原始值是什么单位"也记录在数据审计字段里，方便排查。

第二个坑：生重和熟重。100克生大米煮出来大约230克米饭，同样是"100克米饭"，营养差别巨大。我的食材表里给每个食材标注了unit_type，生熟分开建模，食谱配料表里明确写"大米（生重）50克"，这样营养计算才是不含糊的。

第三个坑是可食部比例。买一斤带壳虾，你以为吃进去了500克，实际可食部分只占六成左右。食材表的edible_rate字段就是干这个的：计算一份食谱的总营养之前，先按可食部把食材重量折算成实际摄入重量。这几个细节不处理好，最后推荐给用户的数字全是错的，整个推荐系统就失去了意义。

3.3 过敏原与忌口标签怎么设计才不失控

过敏原和忌口是推荐引擎的硬约束，设计上必须保证"宁可错杀，不可放过"。我用的是标签关联方案：食材表里维护一个allergen_tags字段，取值包括海鲜、花生、大豆、乳制品、麸质、蛋类等常见大类。食谱通过其配料食材自动继承过敏原标签。

用户在问卷里勾选过敏原后，推荐引擎的第一道过滤器就把含对应标签的食谱全部排除，这个逻辑写在规则层的最前面，任何打分公式都无权覆盖。忌口则包含"不喜欢"和"宗教/生活习惯"两类，这种不一定要做物理排除，而是进入软性偏好评分。比如用户说"不爱香菜"，系统不会一刀切屏蔽所有含香菜的菜，但推荐排序时会把这些菜往后压，除非它确实是最匹配的其他条件。

我用一张单独的user_avoid表来存用户的排除项，包含exclude_type字段区分HARD（过敏）和SOFT（不喜欢）。这样后续要加"痛风人群自动避开高嘌呤食材"这类策略时，只需要往HARD排除列表里插入对应的食材标签，不用改推荐引擎核心逻辑。

4. 推荐引擎实现：从BMR计算到每日三餐打分

4.1 身体指标怎么变成营养目标

推荐引擎的第一步，是把用户的身体信息换算成每日营养目标，核心是基础代谢率（BMR）的计算。我采用的是在公共营养领域广泛使用的Mifflin-St Jeor公式：

• 男性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5
• 女性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161

算出BMR之后，乘以活动系数得到每日总能量消耗（TDEE）。我的活动等级选项是：

然后再根据目标调整：减脂目标在TDEE基础上减300到500千卡，增肌目标加200到300千卡，维持目标就用TDEE本身。这个区间是通用的减重建议区间，减得太狠不健康，也容易反弹。

除了热量，还要分配三大营养素比例。我用的参考区间是蛋白质占15%到20%、脂肪占20%到30%、碳水化合物占50%到65%，在区间内再按用户目标微调。比如减脂用户会把蛋白质比例往上抬，因为高蛋白饮食饱腹感更强。每天的目标还包含膳食纤维和钠的参考量，膳食纤维建议每天25克左右，钠的摄入目标是尽量低于2000毫克。

需要强调一句，这些公式和比例都是公开的营养学参考方法，不是医疗处方。App里所有涉及"目标"的页面底部都有一行小字提示：数据仅供参考，个人情况请咨询医生或注册营养师。

4.2 打分公式：硬约束、营养贴合度、偏好与多样性

有了每日营养目标，接下来就是给每道食谱打分排序。我的打分公式是四部分加权，可以概括成：

最终得分 = 硬约束过滤结果 + 0.4 × 营养贴合度 + 0.3 × 偏好匹配度 + 0.2 × 用户口味历史 + 0.1 × 多样性补偿

硬约束过滤在最前面，是一个布尔判断而不是分数：只要这道菜命中过敏原或者用户明确排除的HARD类食材，直接丢弃；一道菜连第一关都过不了，后面算得再漂亮也没用。

营养贴合度的计算逻辑是：把这道菜按推荐份量算出蛋白质、脂肪、碳水、膳食纤维、钠的实际数值，和当天剩余的营养目标做比对，越接近越好。考虑到人不可能每一餐都精确吃满目标，我用的是"偏差距离"的方式——计算当天剩余热量和这道菜热量的差，差值越小的食谱得分越高，同时蛋白质和纤维的贡献做正向加成，钠超标的做负向扣分。

偏好匹配度比较直接：食谱的口味标签和做法标签与用户画像的偏好标签做交集，重合越多分越高。偏好标签来源于问卷和打卡反馈，比如"清淡""少油""蒸菜""快手菜"，这些标签全部由用户自报，不涉及任何医疗判断。

多样性补偿解决的是"连续三天推荐同一道菜"的问题。推荐引擎维护一个最近7天的推荐历史，某道菜在历史里出现过一次，它的多样性补偿分就减半；出现过两次以上，补偿分直接归零。用户再喜欢一道菜，天天吃也会腻，这是饮食推荐系统里非常实际的问题。

4.3 冷启动的兜底方案与反馈修正

冷启动是所有推荐系统都要面对的经典问题：新用户没有任何打卡记录，系统拿什么给他推荐？我的方案分成两层。

第一层是模板兜底。我预置了几套经过营养师逻辑设计的周菜单模板，比如"均衡减脂周""清淡高纤周""高蛋白增肌周"，每套包含早中晚三餐共21个食谱，并且已经算好了大致的营养分布。新用户完成问卷后，先根据他的目标和基础限制匹配最接近的模板，第一天打开就有一周方案可用，不会看到空列表。

第二层是快速启动反馈。用户打卡之后，引擎会记录他对每道菜的实际反馈（吃完了/剩了一半/没吃），这些反馈数据喂给打分公式里的"用户口味历史"权重。数据显示，用户打卡满5天之后，推荐排序的个性化程度就有明显改善了。对于打卡数据稀疏的用户，模板兜底一直有效，这也是"本地优先"架构的好处。

调参也是个磨人的活。我最初把营养贴合度权重定在0.5，结果发现推荐结果偏保守，几乎全是"营养均衡但毫无食欲"的菜。后来调成0.4，偏好权重提到0.3，用户反馈说"推荐的菜终于有点人味了"。这类参数没有标准答案，只能靠测试用户的反馈不断调。

5. 健康类App的界面与交互：让不同年龄的用户都能轻松上手

5.1 首次填写引导：用对话代替表单

健康养生类App的用户年龄跨度很大，首次使用引导如果做成一张又长又密的表单，40岁以上的用户第一反应是关掉。我把问卷设计成"对话式引导"，每一步只问一到两个问题，配上大号图标帮助理解，比如"平时工作坐着多还是站着多""吃饭口味偏清淡还是重口"，每一步都解释为什么要问这个问题，让用户觉得信息被合理使用。

问卷总共8个问题，控制在两分钟内填完。这个长度是平衡过的：太短画不出像样的用户画像，太长会流失用户。问卷完成之后，App立刻展示一套完整的一周食谱方案，首页大卡片显示今天的早中晚餐，每张菜卡都带一个"为什么推荐"的展开入口，点开能看到朴素直白的理由："热量约450千卡，适合减脂期午餐""蛋白质含量高，饱腹感强，做法以蒸为主，少油少盐"。

5.2 营养数据的可视化表达

饮食记录页面的核心是营养进度可视化。我没有引入复杂的折线图，而是用了一个简单的圆环进度条组件，分别展示当日热量、蛋白质、脂肪、碳水化合物已经摄入的比例，超标的数字用警示色标出。因为对大多数用户来说，"今天还差多少蛋白质"比"过去三十天的蛋白趋势曲线"更有行动价值。圆环组件用Compose的Canvas绘制，很轻量，数据变化时动画过渡也比较流畅。

每周报告用简单的柱状图展示七天热量摄入波动，帮助用户发现自己是不是周末容易吃多。图表这块我的原则是克制：能用一个数字说清楚的事绝不上图表，营养类App最容易做得像专业营养师后台，普通用户看着焦虑又看不懂。用户需要的是"今天达标了没有"和"明天怎么调整"，不是一堆标准偏差。

5.3 打卡提醒与系统权限适配

打卡提醒是保证推荐系统越用越准的关键环节。用户每完成一餐，点进餐卡点"吃完了"或"剩了一些"，这个反馈数据直接进入推荐引擎的口味历史。为了提醒用户打卡，我用了WorkManager做每日三餐的定时通知，外加一个晚间总结通知。

这块有一个绕不开的适配问题：Android 13以上版本的通知权限需要在运行时向用户申请。很多用户在第一次打开通知弹窗时点了拒绝，之后收不到任何提醒。我在设置页做了一个"提醒失效自查"入口，引导用户检查三步：通知开关是否开启、系统是否对该App开启了省电限制、日历提醒的详细设置。实测下来，耐心引导用户完成后，打卡率能有明显提升。

6. 踩坑实录：开发中遇到的三类典型问题

6.1 同一道菜的热量为什么差了一倍

开发中期我遇到一个很诡异的问题：同一道"番茄炒蛋"，在A数据源里一份热量是280千卡，在B数据源里是450千卡。排查了很久，发现两个原因叠加在一起。

第一个原因是可食部折算差异。B数据源把整颗番茄连皮计算，又额外算了炒菜用油的15克，A数据源则是去皮番茄加不计算油的热量。两个口径都有道理，但对用户来说，"这道菜到底热不热量"变成了薛定谔的答案。解决方案是统一所有食谱配料的计量口径：所有配料必须填生重、可食部必须折算、所有炒菜类食谱显式添加"食用油10克"这个配料项。这个口径写进了数据录入规范，后续导入任何新食谱都按这个规则执行。

第二个原因是数据源混用导致的单位错乱，部分条目是千焦，部分条目是千卡。这个前面说过了，我在导入层统一换算的基础上，还加了一个数据完整性校验任务：每天扫描一次食材库，凡是热量值低于100或高于900的异常条目自动标记待审核，避免脏数据流到推荐结果里。

6.2 列表图片加载导致的内存暴涨

食谱卡片带菜品图片，列表页要一次性渲染十几张图，前几个版本用加载原图的方式，滑动一快内存立刻吃紧，低端机上直接OOM退出。后来我把图片加载统一换成Coil，并做了三件事：显示尺寸裁剪（按卡片实际尺寸加载缩略图，而不是全尺寸原图）、磁盘缓存、列表Item的稳定key绑定食谱ID。

这套组合下来，内存占用下降非常明显，低端机的卡顿也基本消失。我的体会是：图片问题在个人项目里很容易被拖到最后才处理，但等到崩溃报告上出现OOM时再改，已经没有用户留存可言了。这类基础体验问题应该在第一个版本就解决。

6.3 Room迁移与厂商后台限制

还有一个和用户数据安全直接相关的坑。早期版本我图省事，数据库升级时直接用了fallbackToDestructiveMigration()，结果一次测试升级后所有打卡记录全部清空，那一刻是真的后怕。这种方案等于告诉Room"版本对不上就直接删表重建"，在开发期可以加速迭代，但绝不该带进生产。后来我老老实实为每次表结构变更写了Migration对象：

val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(db: SupportSQLiteDatabase) { db.execSQL("ALTER TABLE meal_log ADD COLUMN meal_type TEXT NOT NULL DEFAULT 'LUNCH'") } }

后台提醒失效是另一个磨人的问题。部分厂商系统对后台服务的限制非常激进，WorkManager的任务可能被延迟几小时，用户直接投诉"提醒怎么不响"。这不是App代码能完全解决的，我的应对方案是双通道：在应用内做兜底——用户打开App时，如果发现当天还有未打卡的餐次，首页会直接显示补卡入口，即便通知因系统限制没送达，用户至少不会丢失打卡习惯。

7. 测试效果、方案局限与下一步计划

7.1 我做了哪些测试

这套系统我分了三层做测试。第一层是单元测试，覆盖营养计算核心函数：BMR算例、食谱营养汇总、打分公式的排序稳定性、过敏原过滤的边界情况。测试用例用了固定的输入输出对，比如一个身高170厘米、体重70公斤、30岁男性的BMR值在一定误差范围内必须等于预期值，这样以后任何人动推荐引擎代码，一跑测试就知道有没有改坏。

第二层是设备适配测试，覆盖不同分辨率和Android版本的模拟器加真机。重点验证的是Compose布局在老旧系统版本上是否会渲染异常、通知权限在不同版本上的行为是否一致。第三层是邀请约10位目标用户做了为期两周的试用，每周收集他们对推荐方案的采纳率和主观评分。一轮迭代下来，推荐方案的"采纳率"（用户真的按推荐吃了一餐并打卡）从42%提升到61%，这个数据让我确定了后续的优化方向。

7.2 当前版本承认的局限

实话实说，这个App目前离"聪明"还有距离。第一，食物数据库是静态的，内置了大约200种常见食材和80道家常菜，覆盖上班族的日常需求，但当用户想记录地方菜、外卖菜品时会发现库里没有。第二，推荐引擎本质上是规则加加权打分，不是真正意义上的机器学习模型，它的上限取决于打分公式的设计质量，做不到像推荐系统那样自动学习用户的隐性偏好。第三，营养数据来自公开的食物成分参考值，同一道菜不同做法的实际营养成分可能偏差很大。

这些局限我在产品里做了诚实的设计：食谱详情页标注了"营养数据为估算值"，还提供了"食材替换"入口，用户可以手动调整一道菜的配料，调整后的营养计算结果会重新计算。这个功能本质上也是在做数据修正，对实用性的提升比想象中大得多。

7.3 下一步要做的事

如果继续迭代，我的计划是三件事。第一，做智能购物清单：根据一周食谱自动汇总所需食材和份量，用户周末照着清单采购；这个功能在现有数据结构上实现成本很低，但能实实在在提升用户对食谱方案的执行力。第二，把推荐引擎升级为半自适应：根据用户连续的打卡数据和实际摄入偏差，动态调节用户的热量目标和宏观营养比例，而不是固定不变。第三，如果用户量能有起色，再考虑把食谱知识库和用户反馈放到服务端做类目协同过滤，让"大家喜欢什么"参与排序。

至于拍照识别食物、对接可穿戴设备这类方向，我仍然保持克制，先把推荐准确率和数据质量做扎实再说。

最后说一点个人体会：做这类健康饮食App，最难的不是写代码，而是不断提醒自己"不要越界"。营养推荐是一个和用户身体健康直接相关的领域，任何一句不负责任的表述都可能造成误导。把数据做准确、把边界划清楚、把"仅供参考"写实，反而成了这个项目里最有价值的工程实践。希望这篇分享能给想自己做健康类App的朋友一点参考。