大文件千万别走 DDO 在截图整理工具的分享模块里，我想实现一个“把截图瞬间同步到平板”的功能。因为之前做状态同步用过分布式数据对象（DDO），觉得还挺好用，就顺手把图片转成了 Uint8Array 塞进 DDO 的字段里。 结果两台设备一碰，手机端直接闪退，或者平板上一直转圈卡死。我查日志发现，底层发生了严重的 OOM 以及序列化异常。 分布式数据对象是为

用户睡觉时应用在干什么 我们的截图整理工具有一个“全量深度整理”功能：把过去半年的截图全部重新跑一遍 OCR、人脸检测和智能分类。这个操作极度消耗算力，如果用户一边刷抖音，应用在后台偷偷跑模型，手机早就烫得降频了。 解决这种后台重任务的唯一正解是 WorkScheduler。它的逻辑是“我不规定你几点跑，我只规定条件，系统觉得条件合适了，自然会叫醒你”。最典型的条件就是：设备在充电、连着

100KB 的硬指标卡住了多少开发者 我们在截图整理工具里接入了跨端接续功能：用户在手机上浏览截图，走到哪，拿起平板，画面无缝流转到平板继续看。听起来很酷，但调试时发现，只要当前截图的高清缩略图稍微大一点，流转到平板后就是一张白纸。 翻开 HarmonyOS 的接续文档，有一行字非常醒目：onContinue 中通过 wantParam 传输的数据需要控制在 100K

卡片不是迷你版的应用 在智能截图整理工具的开发复盘里，我们发现用户最大的诉求是“不用打开应用，扫一眼就知道今天截了什么图”。于是我们顺理成章地把应用的核心功能封装成元服务，并做了一个桌面卡片。 第一版上线，用户抱怨桌面滑动不跟手。我们查后台日志，发现每分钟卡片刷新两次，每次都把整个数据库扫一遍。要明白一个硬核概念：FormExtensionAbility 的生命周期极短，系统随时会把它干

音乐播放器接入了 AVSession，锁屏面板能显示歌名和封面，看起来一切正常。用户按了播控中心的暂停按钮，音乐没停；切歌按钮按了，播放器也没反应。日志里 AVSession 创建成功、activate 也调了，问题出在你只把状态“写上去”了，没有把控制命令“接回来”。setAVMetadata 和 setAVPlaybackState 

“启动慢”拆开看，大头在首帧之前 截图整理工具加了一个首页，展示最近导入的截图和分类概览。冷启动计时从点击图标到首页可交互，实测 2.8 秒。第一反应是系统慢，用 SmartPerf 拆开时间线，进程创建和系统初始化只占了 0.4 秒，剩下 2.4 秒里，首帧渲染和数据加载占了大头。 首页的 aboutToAppear 里做了三件事：同步读了两百条截图摘要、初始化了 OCR 和

内存泄漏不一定是“忘了释放” 截图整理工具的详情页，打开一张截图，展示大图、OCR 全文、分类置信度。开发阶段没人在意内存，直到测试同学拿着 DevEco Profiler 跑了一遍：反复打开关闭详情页十次，ArkTS Heap 从 120MB 涨到 200MB，手动触发 GC 之后仍然有 80MB 没有被回收。 增长不一定就是泄漏，但反复走同一条路径、每次增长且 GC 后不回落，就是泄漏的典型特

长列表卡顿的根因只有一句话 截图整理工具的分类结果页，五百条截图卡片，每张卡片带缩略图、OCR 摘要和分类标签。用 ForEach 直接渲染，滑到第三屏就开始明显掉帧。换成 LazyForEach 之后好了一些，但快速滑动仍然会白块，偶尔还卡住。 LazyForEach 只解决了“按需创建”，离屏的组件滑出去就销毁，上屏的重新 build。复杂卡片

“持久化”不等于“原样存回来” 截图整理工具的设置页有几个用户偏好：默认分类、是否开启自动打码、特征向量模型版本、上次导入的游标位置。用 PersistenceV2.connect 存进去，开发阶段一切正常，杀掉进程重进，一半字段是 undefined，甚至整个 connect 返回了 undefined。 两个独立的问题撞在一起了。co

截图整理工具的命门在数据库 做智能截图整理工具，最绕不开的一步是把 OCR 识别出的文字、分类标签、特征向量全部存进本地数据库。开发阶段拿几十张图测试，一切正常。用户相册里导进来两万张截图，点击“开始整理”，界面直接冻住，十几秒后应用闪退。 日志里没有崩溃堆栈，但 onCreate 里串行的初始化逻辑和后续的批量写入把主线程堵死了。relationalStore 是本