华为鸿蒙系统

HarmonyOS 6.1 开发者实战 | 《灵犀厨房》多设备烹饪并发：从反复踩坑到架构重构摘要：在《灵犀厨房》App的开发过程中，我遇到了一个看似简单却反复折腾了数日的问题——多道菜同时烹饪时，任务会被意外终止、服务卡片数据紊乱、设备状态不一致。这篇文章将完整复盘这次从"头痛医头"到"全局重构"的排查历程，分享我在并发状态管理、定时器设计、服务卡片推送等方面的思考与最终方案。如果你也在做HarmonyOS应用的状态管理，相信这篇文章能帮你少走一些弯路。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（番外篇）：【打包上架】三模块一体化工程的 Release 包构建与元服务独立分发摘要：经过几十篇的迭代，《灵犀厨房》从一行代码成长为包含主应用、元服务和 HSP 共享库的完整项目。但在通往 AppGallery 的最后一步——打包 Release 包时，我们遭遇了一场“配置风暴”：同一个工程如何分别打出主应用和元服务的包？为什么 entry 和 atomicservice 会冲突？元服务上架为什么要求 type 必须是 entry？本文将完整复盘从工程配置到构建产物的全流程，提炼出“一个工程、两个产品、两条命令”的打包法则。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（三十三）：权限管理——用一套“安检系统”告别散装代码摘要：从第1篇到第30篇，《灵犀厨房》已经集成了相机（拍照识别食材）、麦克风（声控指令）、通知（烹饪提醒）等系统能力。每一处都需要运行时权限——但之前的写法就像是每家每户自己挖井：RecipeDetailPage 里写一段权限检查，IngredientCamera 里又写一段几乎一模一样的代码……重复、散乱、改一处漏三处。今天，我们新建一个 PermissionHelper 工具类，把权限检查、请求、引导设置三项操作封装成三个静态方法，用一套“统一安检系统”管住所有敏感权限。从此，你的代码行数减少75%，

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（三十二）：【数据一致性】个人档案的“三重持久化”修复——让偏好、健康与头像真正同步摘要：你的 App 在“我的”Tab 修改了身高体重，切换到健康 Tab 也确实刷新了营养数据。但当你完全关掉 App 再重启——所有档案恢复默认，头像回到灰色占位。你怀疑是 Preferences 没存上，或数据库没写进去。但真正的根源更隐蔽：数据不是没存，而是存错了地方——ProfileViewModel 和 AuthViewModel 各有一套独立的“事实版本”，ProfileViewModel 启动时从未从 AuthViewModel 加载数据，导致 UI 始终展示默认值。本文将复盘这场数据一致性

HarmonyOS 6.1 开发者盛宴｜《灵犀厨房》实战（三十）：【社区分享】本地社区功能——让菜谱从“独享”走向“共享”摘要：一个人做饭是生活，一群人分享是社区。前面 29 篇中，《灵犀厨房》的菜谱从推荐、收藏到烹饪，都围绕着“我一个人”。但烹饪的乐趣有一半在于分享——把自己拿手的番茄牛腩煲分享出去，看看别人做了什么。本篇为《灵犀厨房》新增“社区广场”——用户可在菜谱详情页一键分享菜谱到社区，其他用户可浏览所有分享，无需后端服务器，纯本地数据库实现。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十九）：【偏好持久化】偏好设置与推荐引擎联动——让 App 越用越“懂你”摘要：前面 28 篇中，用户在个人中心设置了口味偏好和过敏源，但 App 重启后全部丢失——因为这些数据只存在内存里。推荐引擎虽然已经写好了过敏源过滤逻辑（isSafe()），但从未与偏好设置真正联动。本篇利用 HarmonyOS 的 preferences API 实现偏好持久化，并打通偏好→推荐的数据链路——用户设置一次偏好，App 永久记住，推荐结果自动规避过敏源、响应口味变化。全程不改推荐引擎核心代码，仅新增约 30 行持久化逻辑。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十七）：告别 UI 冻结——使用 TaskPool 实现高性能并发图像分析专栏：HarmonyOS 6.1.0 开发者盛宴｜手把手带你打造《灵犀厨房》AI 厨艺助手摘要：在《灵犀厨房》首页，点击“拍照识别”后，图像分析逻辑（编码、模型推理）在主线程执行会耗时数百毫秒，导致 UI 完全冻结。本篇将分析逻辑从主线程剥离，借助 HarmonyOS 的 TaskPool（并发任务池）将其抛入后台线程执行，主线程通过 Promise 接收结果，确保 UI 交互始终流畅。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十八）：【数据持久化】收藏与浏览历史——让数据在 App 重启后依然“活着”摘要：收藏一道菜谱、回顾之前看过什么菜——这些功能在前 27 篇中只能活在内存里。App 重启后，所有收藏和历史全部消失。本篇利用已有的 RelationalStoreHelper（完整 CRUD 封装），新增三张持久化表，让收藏和历史在 App 重启后依然存在。你还会学到：为什么收藏用主键约束而历史用追加写入？为什么浏览历史的写入失败不阻塞页面跳转？以及，如何用约 45 行代码完成从建表到 UI 联动的完整持久化闭环。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（二十六）：【响应式布局】折叠屏与平板完美适配——一套代码，多端呈现摘要：《灵犀厨房》从第1篇到现在，一直以手机竖屏为基准设计。但随着折叠屏手机的普及、平板用户的增长，单一布局已无法满足多设备场景。本篇利用现有的 Breakpoint.ets 断点系统（SM/MD/LG）和 ArkUI 的响应式能力，让首页瀑布流和菜谱详情页在折叠屏和平板上自动切换为更高效的多列/双栏布局——无需为每个设备单独写页面，只需在现有布局中添加断点分支。

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（二十五）：【深色模式】一键切换暗色主题——让 App 在深夜也温柔摘要：从第1篇到现在，我们写了上万行代码，但有一个细节一直被忽略——用户可能在深夜打开 App，白色背景的刺眼光线会让体验大打折扣。本篇将利用 HarmonyOS 6.1.0 的资源限定符（Resource Qualifier）和 setColorMode() API，为《灵犀厨房》构建深色模式——只需在 resources/dark/ 目录添加一组颜色覆盖值，配合一个 Toggle 开关，App 就能在浅色和深色之间无感切换。

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（二十二） | 多媒体 | AVPlayer嵌入教学视频——让智慧屏真正“活”起来摘要：在《分布式流转让菜谱“飞”：手机选、平板看、智慧屏播的全场景秘诀》篇章中，我们实现了「手机选菜谱→平板看步骤→智慧屏播视频」的分布式流转，但智慧屏上的视频播放还是静态的「模拟区」——点击只会显示一个 LoadingProgress，没有实际的视频内容。本篇将利用 HarmonyOS 6.1.0 的 AVPlayer（@kit.MediaKit），替换模拟区域为真实的视频播放器，让流转到智慧屏后能真正播放烹饪教学视频，把《灵犀厨房》的全场景体验推上一个新台阶。

HarmonyOS 6.1 开发者盛宴｜《灵犀厨房》实战（二十三）：【交互动效】转场、列表动画与趣味反馈——让每一次点击都有温度摘要：前面 22 篇我们完成了《灵犀厨房》的核心功能——推荐、菜谱、流转、语音、视频。但功能齐全 ≠ 体验优秀。用户在第一秒就会用「眼睛」和「手指」投票：页面切换卡不卡？列表加载生不生硬？按钮有没有反馈？本篇将用 HarmonyOS 6.1.0 的 **属性动画（.animation）**和变换（.scale / .translate / .opacity），为《灵犀厨房》注入「灵气」——让页面有呼吸感、让列表有节奏感、让每一次点击都有温度。我们不增加任何新功能，只改动约 80 行动效代码，让 App

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（二十一）：【服务卡片】在桌面查看烹饪进度——主进程强推与跨进程桥接摘要：上一篇我们为《灵犀厨房》接入了原子化服务，用户搜“今天吃什么”即可直达推荐页。但烹饪开始后呢？用户每次都要点开 App 才能看“烤箱还剩几分钟”“电磁炉到第几步了”——这体验就像你煎牛排时每隔 30 秒跑回客厅看电视，累不累？本篇，我们将基于 HarmonyOS 6.1.0（API 23）的 FormExtensionAbility 服务卡片能力，在手机桌面创建一张“烹饪进度卡”。特别警示：API 23 对卡片底层框架进行了大规模重构，传统网传的“卡片自驱动”或“FormAbility 回调桥接”方

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（排错指南）：【服务卡片跳转】页面栈“迷航”——从“回不去的主页”到精准 Tab 唤醒的全链路修复摘要：上一篇我们为《灵犀厨房》装上了服务卡片——抬手就能看到烤箱倒计时。但卡片点击后，一个幽灵般的 Bug 悄然出现：点击服务卡片进入厨电页，再点桌面图标，App 直接打开了厨电页，返回键一按就退出，再也回不到首页。经过排查，这不是代码写错了，而是页面栈被“截断”了。本文将复盘从现象定位、根因分析、方案设计到代码修复的全过程：服务卡片通过 postCardAction 跳转，在 EntryAbility 中原本被直接加载为独立的 KitchenDevicePage，导致 MainContainer 从未进

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（番外篇）：【深度排查】24小时死磕服务卡片不刷新，我踩平了 API 23 的所有底坑摘要：你按照网上的教程，为应用写了一个 2×2 的动态服务卡片。在旧版本系统上跑得好好的，到了 HarmonyOS 6.1（API 23）上，卡片就像一块“墓碑”——添加到桌面后死活不刷新。你怀疑是业务逻辑写错了，怀疑是生命周期没走通，甚至怀疑是系统 Bug。但真相远比这残酷：API 23 在底层对卡片框架进行了一场“静默大清洗”。本文将全景复盘一次长达 24 小时的硬核 Debug 过程：从自驱动死循环被系统掐断、到 formHost 彻底改名换姓、再到模拟器的“视觉欺骗”和卡片进程的 C++ 级闪退。

【HarmonyOS 6.1 全场景实战】《灵犀厨房》实战（二十）扩展：【工程集成】主应用 + 元服务 + HSP 共享库——三模块一体化架构摘要：第 19 篇我们为《灵犀厨房》装上了通知系统——延时提醒 + WantAgent 回到应用。第 20 篇我们构建了一键推荐原子化服务。但这两个模块目前还各居一隅——主应用的登录页、首页、详情页在一个工程，元服务的推荐页在另一个工程。用户从元服务点击菜谱卡片，主应用需要正确接收 Want 参数并直接打开 RecipeDetailPage——这要求两个模块必须在同一工程、同一 bundleName 下运行。本篇，我们将把 entry（主应用）、atomicservice（元服务）、shared（HSP

HarmonyOS 6.1 开发者盛宴｜《灵犀厨房》实战（二十点五）：【排错指南】元服务跳转主应用——Want 参数传递的五个陷阱与架构修复摘要：第 20 篇我们为《灵犀厨房》搭建了一键推荐原子化服务——用户搜索直达推荐页，3 秒出结果。点击菜谱卡片应通过 Want 拉起主应用并直接进入 RecipeDetailPage。但在实际联调中，这个"点击跳转"触发了四个连续 Bug：① 冷启动被 LoginPage 拦截；② router.pushUrl 在 UIAbility 生命周期中报 Uri error；③ router.replaceUrl 导致页面二次挂载数据覆盖；④ LocalStorage 在 API 23 不可用引发 9 个编译错

HarmonyOS 6.1 开发者盛宴｜《灵犀厨房》实战（二十）：【元服务】一键烹饪推荐原子化服务——免安装直达美味摘要：前面的篇章《HarmonyOS 6.1 开发者盛宴｜灵犀厨房APP【通知系统】延时烹饪提醒——让通知不再错过关键步骤》中，我们已为《灵犀厨房》装上了通知系统——延时提醒 + WantAgent 回到应用。但这里有一个产品层面的断层：用户只是想“看看今天吃什么”，却必须打开完整 App——加载登录、加载首页、等待推荐引擎计算。能不能更轻？本篇，我们将深入 HarmonyOS 6.1.0（API 23）的原子化服务（Atomic Service）能力，为《灵犀厨房》构建一个免安装的一键烹饪推荐元服务：用

HarmonyOS 6.1 开发者盛宴｜《灵犀厨房》实战（十九）：【通知系统】延时烹饪提醒——让通知不再错过关键步骤摘要：上一篇我们为厨电控制页装上了"手腕大脑"——将计时器从手机流转至手表，实现了手腕掌控烹饪节奏。但烹饪中的提醒远不止计时：蒸鱼该关火了但你在阳台晾衣服？炖肉可以加盐了但正在客厅看电视？本篇，我们将接入 HarmonyOS 6.1.0（API 23）的 @kit.NotificationKit，为《灵犀厨房》实现烹饪延时通知的全链路：用户在菜谱步骤页一键设置延时提醒→系统到点自动弹出通知→点击通知通过 WantAgent 直接回到菜谱步骤。严格遵循 API 23 规范，代码即文档。

HarmonyOS 6.1 全场景实战｜《灵犀厨房》实战（十八）：【手表协同】烹饪计时器流转至智能手表——手腕掌控烹饪节奏摘要：上一篇我们为菜谱详情页装上了"耳朵"——接入 CoreSpeechKit 语音识别实现了免提声控启动播报。但烹饪中还有一个高频痛点：计时。炖牛肉要 40 分钟，蒸鱼要 8 分钟，你不可能一直盯着手机。如果计时器能流转到手表上——手腕一抬就看到倒计时，到点了轻震提醒——那才是真正的"云端厨房"。本篇，我们将接入 HarmonyOS 6.1.0（API 23）的分布式设备协同能力，为《灵犀厨房》的厨电控制页实现计时器从手机流转至智能手表的全链路：手机端一键发送→手表端接管倒计时→倒计时最后 10 秒渐强