《灵犀厨房》接入HarmonyOS 6.1通知系统实现延时烹饪提醒功能，通过NotificationKit的deliveryTime机制，系统级调度确保提醒准时送达。用户在菜谱步骤页设置延时后，通知将在指定时间自动弹出，点击通知通过WantAgent直接返回应用。方案采用SOCIAL_COMMUNICATION级别通知渠道，支持横幅和浮动图标提醒，无需应用保活，严格遵循API 23规范实现可靠提醒

摘要：本文介绍了如何在《灵犀厨房》应用中实现烹饪计时器从手机流转至智能手表的功能。通过HarmonyOS 6.1.0的分布式设备协同能力，用户可在手机端一键发送计时任务至手表，实现手腕感知倒计时。手表端提供三段式震动反馈（安静期、预警期、完成期），确保用户无需紧盯屏幕即可掌握烹饪节奏。架构设计采用四层分离模式，确保业务逻辑与UI解耦，同时支持后续无缝接入真实手表设备。该功能解决了烹饪过程中频繁查看

这不仅仅是一次 UI 的换皮，而是一场从“能用就行”到“极致体验”的系统性重构。在 UI 层，我们学会了敬畏用户的心智模型——不要自作聪明地创造布局，微信花了十年验证的分组卡片、细线分割、独立危险区，就是最好的教科书。在架构层，我们学会了顺应 API 23 的严苛规则——当AppStorage倒下，不要试图复活它，用最原始的存数据，用参数精准对齐的emitter吹哨子，这种看似“笨拙”的双轨机制，

本文基于HarmonyOS 6.1.0（API 23）演示《灵犀厨房》服务卡片开发方案，解决传统烹饪场景需频繁打开App查看进度的痛点。通过"主进程强推+本地数据库跨进程桥接"架构，实现桌面卡片秒级刷新烹饪状态（菜谱步骤/倒计时）。重点剖析API 23下失效的旧方案（卡片自驱动/FormAbility回调），提出三层隔离架构：①FormAbility仅登记ID至Preferences；②主进程轮询

本文介绍了如何将《灵犀厨房》的主应用、元服务和共享库整合到同一工程中，构建三模块一体化架构。关键点包括： 采用bundleType:app而非atomicService，因为应用同时包含主应用和元服务模块 元服务模块通过type:"feature"+installationFree:true实现原子化能力 通过HSP共享包(shared)实现代码复用，避免跨模块直接引用 设计了三模块分层架构：主应

HarmonyOS 6.1 元服务跳转主应用参数传递问题全解析 本文详细记录了《灵犀厨房》应用中元服务跳转主应用时遇到的五个关键陷阱及解决方案。主要问题包括： 冷启动被登录页拦截：原始代码硬编码跳转登录页，导致参数丢失，通过检测Want参数实现动态路由。 UIAbility生命周期中路由API不可用：发现router.pushUrl在onNewWant中报错，改用loadContent直接加载页面

华为HarmonyOS 6.1推出原子化服务功能，《灵犀厨房》利用该技术实现了免安装的一键烹饪推荐服务。用户通过全局搜索"今天吃什么"即可3秒内获取AI推荐菜谱，无需下载完整应用。该元服务采用HSP共享包复用现有推荐引擎逻辑，仅包含1个Ability和1个页面，严格遵循API 23规范。相比传统应用7秒的启动流程，原子化服务通过免安装、预加载等机制极大提升了用户体验。服务支持全局搜索、桌面卡片和N

HarmonyOS 服务卡片跳转的页面栈修复指南 问题现象：点击服务卡片进入App特定页面后，返回和再次启动时出现页面栈混乱，无法回到主页。 根因分析：服务卡片直接加载独立页面导致页面栈被截断，MainContainer未入栈。 解决方案： 统一跳转入口到MainContainer，通过startTab参数指定目标Tab 使用静态变量EntryBridge传递冷启动参数 通过emitter事件处理

这 24 小时，我们仿佛在和鸿蒙底层的幽灵战斗。从最初对“为什么没日志”的疑惑，到扒开 API 23 类型系统的外衣，再到识破模拟器“右键添加”的视觉欺骗，最后揪出这个隐藏极深的 C++ 杀手。在严苛的新版本 API 面前，不要迷信网上的“奇技淫巧”（如卡片端死循环自驱动），最朴素的“基础 API 原子操作”（读写字符串的 Preferences）+“清晰的状态机隔离”（主进程全权负责），才是最扛

参数选择如果更大如果更小位移 40vp屏幕高度约 5%动画太“跳”，用户注意力被分散几乎感觉不到滑入时长 500ms刚好感知，不等待用户觉得 App 慢动画一闪而过足够让用户感知到“滑入”，但不至于让他们等待。的减速收尾让卡片像“轻轻落下”而非“匀速滑入”，这是物理直觉在 UI 中的投射。本篇是《灵犀厨房》系列中“投入最少、感知最强”的一篇。转场动画：Hero 卡片和推荐瀑布流有了“呼吸感”——不