登录社区云，与社区用户共同成长
邀请您加入社区
同一张明信片，白天想用浅色天空，夜间想换成深色山景；放到二合一设备上，还想多留一点横向风景。第一反应可能是在页面里加几个判断，再给 Image 传不同路径。图少时还能记住，页面一多，条件就容易散到各个角落。这次把选择交给资源目录。页面只引用，标题只引用。名字不变，不同限定符目录提供不同内容，让资源管理器根据运行设备和外观配置匹配。最后回到最初那一行 Image：它始终只认识 postcard。需要
给商品图片制作贴纸时，用户经常希望留下杯子或者商品本身，再把它放到另一张背景图上。如果直接裁剪出一个矩形，原图中的桌面和墙面也会跟着保留下来。到了新画面中，这些背景就会挡住原有内容，贴纸看起来仍然像一张方形照片。要解决这个问题，页面需要知道主体的轮廓，还要让轮廓以外的位置变成透明。HarmonyOS 的提供主体分割能力，可以从输入图片中识别显著主体，并返回包含前景的像素图。我们将把这个结果显示在页
会议通知、纸质表格或课堂资料需要放进应用时，用户通常会先拍一张照片。照片里可能带有桌面，纸张边缘也可能倾斜。等到需要把它作为附件发送或保存时，用户还得回到图库裁剪，再决定使用图片还是文档格式。VisionKit的可以提供拍摄、选择图片和文档编辑界面。用户完成裁剪或调整后，应用再接收扫描结果，把文件保存到自己的目录。接入时需要把界面中的保存选择和回调中的文件类型对应起来，这样图片预览和 PDF 附件
开会时，用户常把纸质资料拍成照片，放进自己的笔记。照片保留了现场内容，但需要引用其中一句话或搜索某个日期时，用户还得对着图片重新输入。如果笔记页面能够提取图片里的文字，用户就可以直接复制或搜索，再对照原图检查识别结果。从图片中提取文字通常称为光学字符识别，也就是 OCR。HarmonyOS 的 Core Vision Kit 提供通用文字识别能力，接收图片后可以返回文字内容和文字所在的区域。应用需
HarmonyOS 7.0 Badge角标：从接入到生产验证：真实工程复盘，附代码与验证方法。
HarmonyOS 7.0 Tooltips气泡提示：从接入到生产验证：真实工程复盘，附代码与验证方法。
HarmonyOS 7.0 Menu菜单与上下文：从接入到生产验证：真实工程复盘，附代码与验证方法。
HarmonyOS 7.0 BindContentCover全屏模态：从接入到生产验证：真实工程复盘，附代码与验证方法。
HarmonyOS 7.0 BindSheet半模态浮层：从接入到生产验证：真实工程复盘，附代码与验证方法。
一个待办事项在视觉上看起来非常简单：左侧一行标题，右侧一个“完成”按钮，下面再放一行说明。可把屏幕阅读功能打开以后，用户听到的可能是“按钮、按钮、文本”，却听不出来哪个按钮对应哪条任务。再把系统字体调大，标题挤成三行，按钮被挤出屏幕；页面原本展示得越紧凑，问题反而越容易暴露。设计一个看起来整洁的列表，跟设计一个可以被不同用户稳定操作的列表，是两项需要分别核查的工作。 这次选择一个完全独立的 Har
一项动效功能已经能展示，并不意味着第三方库的升级可以直接进入发布分支。内容卡片页面看上去只有“开始播放”和“停止播放”两个动作，实际交付时却可能受到传递依赖变化、资源打包方式调整、停止操作语义变化等因素影响。特别是旧版正常、新版偶发失败的场景，如果只留下新版安装包而没有可复现的旧版构建，所谓“紧急回退”就会变成重新猜测依赖关系。 前面三篇已经建立了一条稳定工程主线：依赖准入表包含 approved
一个工单在宽屏上打开时，左侧是列表，右侧是详情；将窗口收窄后，同一工单应该如何呈现？如果只用“手机显示单列、平板显示双列”回答，真实项目往往还会遇到第二个问题：折叠屏展开时正在编辑的工单没有变，界面却可能重新建立了详情导航，结果出现重复详情页、返回路径混乱，甚至把选中高亮跳到了另一条记录。这不是屏幕不够宽，而是窗口形态变化被误当成业务状态变化。 本系列前四篇逐步完成了工单模型、断点回调、筛选与导航
离线巡检做到第四篇时，写入链路已经有了事务、同实例写队列以及 request_key 去重凭据。再往前走，新的瓶颈不一定是写不进去，而是恢复某条历史记录时，需要从几万条草稿里翻出正确的一条。如果每次进入列表都调用 all()，把整张表读入内存，再使用 JavaScript 的 sort()、slice() 做翻页，确实容易得到一个能滚动的页面，但随着记录增加，数据库本可以做的过滤排序被转移到了 U
改完一段 ArkTS 代码，编辑器里没有红线，就可以说“问题已经解决”了吗？未必。静态检查擅长发现特定规则能表达的代码问题，运行日志则回答程序在某次操作中走到了哪一步。两者各有盲区：一个只能分析写在代码里的结构与约束，另一个只有在对应执行路径真正被触发时才会留下线索。把它们当成两个互不相关的按钮，排障时就容易出现“修了格式，却还在崩溃”或“日志很多，却找不到应修的代码”的情况。 这里以一款完全独立
同样是点击内容卡片后没有动效，为什么有的故障要查 oh-package-lock.json5，有的要查 ArkTS 类型报错，还有的必须回到 CardEffectController 的异步状态？如果把三个阶段混在一起，最常见的结果就是：明明是依赖没有解析成功，却在页面里改了一圈 try/catch；明明是驱动初始化失败，却反复删除安装目录，最后让锁文件也跟着改变了。 上一阶段，内容卡片工程已经固
工单从三条增加到三千条，通常先暴露的不是数据库问题，而是列表管理方式的问题。上一阶段的响应式工单台用 ForEach(this.visibleOrders()) 显示筛选结果；数据量少时，这种写法直观，视图与业务选择也容易对应。一旦叠加搜索、频繁状态变化和窄宽屏切换，就需要认真回答：哪些列表项有必要参与当前绘制？筛选后的索引是否还能表示原来的工单？选中的详情究竟依赖“第几项”，还是依赖稳定业务 I
离线巡检最让人犹豫的提示，往往不是“保存失败”，而是“提交后页面没有收到成功反馈”。例如巡检员在地下机房保存一组检查记录，系统恰好在提交完成后退出。重新进入页面，这一组记录究竟已经存进数据库，还是仍停留在编辑状态？如果直接再点一次，前一篇的串行写队列虽然能把两次调用排好队，却不能阻止两组内容被依次插入。单次事务原子性已经解决了“只保存半组”，但重复提交的身份识别仍是一道独立的工程题。 前三篇沿用同
准备提交一个 HarmonyOS 应用时，最令人头疼的情况并不是“构建失败”本身，而是构建包已经生成，到了发布环节才发现版本号没有递增、包名与平台登记不一致，或者某个 product 根本没有关联预期签名。这三类问题通常散落在不同配置文件里，单靠最后点一次 Release 按钮，发现得太晚。 这一问题可以做成一个独立的小工程：给发布流程增加一道可重复执行的静态预检。它不申请账户权限，不向应用市场提
内容卡片上的一个动效，真正难维护的地方往往不是“播放”按钮，而是它被快速切换、页面退出或资源加载失败之后还能不能收住。假设用户先打开卡片 A，又立即切换到卡片 B，A 的资源加载却晚于 B 返回。直接把库调用写在页面点击事件里，就可能看到 B 标题下面还在播放 A 动效。更麻烦的是，一次初始化失败会不会让下一次重试陷入不可用状态？这些问题要在接入第三方库之前说清楚。 上一阶段已经确定内容卡片工程的
工单台里的“当前选择”很容易被三个东西搅乱：搜索框缩小了可见列表，手机打开了独立详情，宽屏又把详情放回同一页面。假设已选工单 id=2，随后用户筛选“待处理”，列表里只剩 1 与 3。这时详情应该显示 2、跳到 1，还是显示“选中项不在筛选结果中”？如果不先明确这个问题，开发时往往会在筛选回调、路由回退和断点变化里分别修改 selectedId，最后出现列表高亮与详情标题对不上的现象。 前两篇已固
巡检员在没有网络的机房里连续录入五条记录，点击“保存本组”。如果前四条写入成功、第五条因为字段问题失败，页面却弹出“本组完成”，数据库里就留下了一批看似完整、实际上少一条的记录。麻烦还不止于此：用户可能连点两次按钮，后台自动保存也可能同时触发。如果两条写入链路共用同一个 RdbStore 并且交错开启事务，批量边界就更难推断。 前两篇已经给离线巡检建立了 DraftRepository，将 ins
巡检草稿已经能落盘，下一次升级却未必能顺利打开。设想旧版本保存了一百条 inspection_draft，新版本要为每条记录新增“处理优先级”。如果直接把建表语句改成五列，安装升级包的老用户仍保留四列表结构；程序再去读取 priority，查询就会失败。更危险的是，迁移 SQL 执行了一半，代码却先把版本标成新版本，下次启动再也不会补跑应有的结构调整。 上一阶段确定的 inspection_dra
“只改了一个工具包版本，为什么打出来的包在另一台开发机上表现不一样？”三方库集成的问题经常不从业务代码开始，而是从依赖如何被声明、解析、安装和更新开始。把一个库加入 oh-package.json5，确实只需要改几行配置；但让它在多名开发者、多个构建节点之间稳定使用，需要给版本、来源、许可证和业务接口都划清界限。 这套连载围绕一个小型巡检应用之外的独立项目——内容卡片应用的三方依赖治理。它关注 o
工单台从窄窗口拖到宽窗口，左侧仍然高亮第二条工单，右侧详情却跳回第一条——这样的错位比单纯“页面挤变形”更难发现。第一篇已经用 GridRow、GridCol 建好列表和详情共用的主从布局，并统一用 selectedId 表达当前工单。本篇不再重复介绍栅格怎么分列，而是解决两个新的问题：布局断点切换时不更改业务选择；页面被重新创建时，如何在合适范围内恢复选择。 需要先说清楚“恢复”到底指什么。这里
鸿蒙「共创季·征文稿事节」第2期聚焦HarmonyOS 7（API26）的「空间×AI新视界」，评选出12位开发者获奖。涵盖3D模型交互、文搜图、端侧图像超分、人脸表情识别等创新实践，展现AI与空间能力在智能音箱、相册、文档等场景的应用。大雷神、一键难忘等作者以系列实战案例推动技术落地，彰显开发者社区创造力。活动共收250+投稿，持续激发鸿蒙生态创新活力。
一款设置页原本只有开关、滑杆和下拉选择。升级目标 SDK 后，控件的高光、通透材质与动效似乎发生了变化。第一反应往往是去逐个修改颜色和背景模糊，但这未必是根本原因：HarmonyOS 7（API 26）的 ArkUI 已提供沉浸光感能力，受支持的系统组件可能随配置策略呈现新的材质反馈。这个特性既不是所有组件无条件通用，也不是把一个“玻璃质感”图片贴到页面上。 最值得研究的问题，是它的启用范围、配置
一份工单列表，在手机上通常是一列内容；换到平板或折叠屏展开态，如果仍然只把手机页面居中放大，空白会变多，来回查看详情的成本却没有下降。真正需要解决的问题不是“屏幕宽了以后把按钮放大”，而是同一份业务数据如何自然地从单列阅读过渡为主从分栏，同时让当前选中项保持一致。 本篇围绕一个小型工单台建立最小可维护的布局骨架：左侧展示待处理工单，右侧展示当前详情；窄窗口中两块内容依次上下排列，中、大窗口中并列。
巡检人员填写一条设备记录，刚写完故障描述就切到了其他应用。回来时页面重新创建，输入框空了。这个场景很常见，但真正的技术问题并不是“输入框为什么没记住文字”，而是：业务记录究竟在什么时候拥有了可靠的持久化身份？如果数据只活在页面 @State 里，组件和应用进程的生命周期就成了业务保存的边界，这是一个不应该发生的耦合。 离线巡检不要求刚创建记录就能立即联网，它首先要求本地能保存、能重新加载、保存失败
一个页面在正常字体下看起来很清楚：左边是任务名称，右边是红色的“待处理”，下面还有个只有图标的“更多”按钮。可一旦开启屏幕朗读，用户可能只听见“按钮”“待处理”，却不知道是哪个任务，更不知道点击后会执行什么操作。开发者看到的是视觉层级，辅助技术依赖的却是另一套可被理解、可被操作的语义结构。两者不应该靠运气碰巧一致。 拿一个很普通的巡检任务卡片来说，页面功能只有展示状态、打开详情、切换完成状态三件事
构建按钮点过了，工程目录里也出现了新文件，为什么发布前评审仍然会问“这个包究竟是哪个模式打出来的”？因为构建成功、能够安装和可以提交分发，是三件需要分别证明的事情。前两篇已经为设备点检助手确定了 com.example.fieldinspector 这个示例应用身份，约定了 versionCode 的递增规则，也把证书、Profile 与签名配置之间的责任关系理清。本篇把目光移到真正产生文件的阶段
窗口展开时，任务列表和详情并排；窗口收窄时，详情被移动到独立页面。这一切看上去只是 ArkUI 的布局工作，真正容易丢掉的却是用户正在输入的备注：点了几个字、折叠屏幕，输入框又回到上一次保存的内容。这里的问题不是 TextArea 不会保存文字，而是我们让一个随布局反复创建的子组件独自承担了业务草稿。 前三阶段已经把工作台的 selectedId、NavPathStack 与列表刷新分开了。第四阶
巡检记录刚开始只有几十条，列表进入页面就把整个 inspection 表查出来，通常不会立刻暴露问题。等机房、楼层和设备的巡检历史积累到成千上万条后，滚动列表会越来越难管理。更讨厌的是，用户翻到第二页时，后台新增了一条最新巡检记录；如果仍按 LIMIT ... OFFSET ... 查询，第二页的第一条可能刚好是上一页最后一条。这不是数据库把排序搞乱了，而是查询的“位置”随数据插入而移动。 此前已
一个 H5 页面嵌进 HarmonyOS 应用后，页面上可以正常点击、滚动，却在调用 ArkTS 方法时报“对象不存在”，有时刷新一次又好了。这类问题通常不是 JavaScript 语法错了，而是 Web 组件初始化、桥接对象注册和页面执行脚本的顺序没有对齐。另一个经常被忽略的风险是：桥接一旦暴露了过多原生方法，加载页面的范围发生变化时，调用入口也会随之扩大。 本篇用一个“本地帮助中心”作为独立场
发版当天才发现构建签名不可用，是一种代价很高的工程失误。产品可能已经完成回归、测试已冻结版本，最终却因为证书不属于当前应用、Profile 与包名不一致，或签名材料只留在某位开发者电脑上，导致候选发布包无法形成。签名问题难以靠多点几次“重新构建”解决，关键是把材料关系、人员权限和构建环境整理清楚。 上一篇已经为设备点检助手固定 com.example.fieldinspector 这一演示包名，以
同一条任务在详情页里还是 T-102，列表刷新之后却跳到了 T-101。只要任务数据来自异步接口，这种看起来像“选中态乱了”的问题就不稀奇。上一阶段我们把业务选择 selectedId、导航历史 NavPathStack 和布局断点分成三种独立状态，已经解决了宽窄窗口切换和返回栈互相干扰的情况。但接口带来的新难题是：旧请求可能比新请求更晚返回，列表顺序可能变化，已选中的任务甚至会被删除。路由依旧正
