只要涉及到用户数据，就一定会面临版本升级的考验。应用发版，数据库新增了一个字段，或者加了一个索引。如果你在处理 onUpgrade 的逻辑时简单粗暴地来一句 DROP TABLE，那么恭喜你，下次发版大概率会因为用户数据清零而被打一星差评。 关系型数据库（RDB）的版本迁移，是一场没有回头路的走钢丝。今天这讲，我们把数据迁移的安全垫铺好，聊聊怎么做到无损升级。 事务是

分布式文件系统（Distributed File System）是鸿蒙跨端协同的杀手锏。手机和平板组网之后，手机拍的高清视频，平板上的应用可以直接读取。听起来很爽对吧？ 我曾经做过一个跨设备传图编辑的功能。用手机选了一张 50MB 的原图，发送给平板端的应用。平板这边弹出一个进度条，结果进度条直接卡死在 99%，等了一分钟都没动静，最后报了个超时。用户以为死机了，直接把 App 划掉了。 当我去查

刚接手一个项目做性能优化，发现一个特别诡异的现象：用户在一个二级页面的搜索框里敲字，结果底层列表的整个列表项都在疯狂重绘；或者用户点击了底部的点赞按钮，整个页面像是闪了一下，全都刷新了一遍。 打开 ArkUI Inspector，看谁在频繁重建，发现很多根本没有用到的组件，也跟着凑热闹。排查到最后，问题全指向了一个地方：AppStorage 的滥用。 很多开发者习惯了把什么状态都往&nb

用鸿蒙做一个带下载功能的应用，或者是需要后台播放音频的 App，很多人的第一反应是：在主线程写个异步函数，或者开个 Worker，然后把 App 切到后台，以为它能一直在那跑。 现实是骨感的。App 切到后台不出几秒钟，你打开 HiLog 一看，整个进程都被系统挂起（Suspend）甚至杀死了。下载进度条卡住不动，音乐也停了。用户觉得这 App 是个半成品，你还在那里纳闷：“代码明明没报错，为什么

应用迭代，给本地 RDB 数据库加个字段或者新建个表再正常不过。我见过一个极其惨烈的线上事故，某个版本的更新之后，大批用户反馈“我的收藏全没了”、“笔记全清空了”。 排查下来，发现开发同学在 onUpgrade 里为了图省事，直接写了 DROP TABLE，然后重新 CREATE TABLE。测试阶段因为都是干净的安装包，没人发现问题；一上线，存量用户一升级

做资讯类或者电商类的应用，WebView 是个绕不开的组件。商品详情是 H5 的，活动页是 H5 的，连用户协议都是 H5 的。我之前做活动模块，测试跑了一下午，手机烫得能煎鸡蛋，最后直接闪退，抓日志一看，又是经典的 OutOfMemoryError。 检查了一圈代码，Web 组件在页面销毁的时候确实跟着生命周期销毁了，看起来毫无破绽。但打开 DevEco Profiler 看

一个商品详情页，状态里挂着一个大对象：商品信息、库存、价格、规格、用户优惠券。用户点一下“选中红色款”，只改了 selectedSku.color 这一个字段，整个页面的标题、价格、评价、推荐列表全部重新构建了一遍。 V1 的状态观察是对象级的：@State 挂了一个对象，对象内部的任何字段变化，依赖这个对象的组件全部刷新。V2 的核心改进是把观察粒度从“对象”降到“

应用上架前的包体积检查，90MB 的 HAP 摆在面前。你打开分析工具一看，libs 目录下 arm64-v8a 和 armeabi-v7a 各躺着一套 so，resources 里一堆重复的图片，多个 HAR 模块里同一份工具库被拷贝了好几遍。 HarmonyOS 应用的包体积优化不是“压缩一下”这么简单，它是一条从架构筛选到 Nati

做设备协同或者多进程传感器采集时，数据频率一旦上去，普通 IPC 就会暴露短板。每一帧传感器读数通过 rpc.MessageSequence 从服务进程传到消费进程，都要做一次序列化和反序列化。100Hz 意味着每秒一百次拷贝，数据量再大一点，消费进程的主线程光处理 IPC 回调就占满了。 鸿蒙的 IPC 设计里有一个关键机制被很多人忽略了：Ashmem（匿名共享内存）。它允许

信息流页面接入了 RCP 的 HTTP 缓存，第一版跑得很舒服：内存缓存加磁盘缓存，重复请求直接命中，流量和加载时间都降下来了。然后测试提了一个问题：A 用户退出登录，B 用户登录，B 在首页看到的第一条内容是 A 刚才浏览过的。 去看缓存键，只有 URL。A 和 B 请求同一个接口地址，缓存键完全一样，系统按服务端的 Cache-Control 判定缓存有效，直接把 A 的响