雷霆牛逼克拉斯-优快云博客

原创密钥别名一改，旧密文就成了孤儿

重装后，本地留存的密文或云端备份的旧密文，在本地找不到对应的密钥，解密直接失败。云端备份的加密数据需要配合账号级密钥或用户密码派生密钥做二次保护，本地 HUKS 密钥只是其中一层，不是唯一一层。如果只维护一个全局的“已迁移”标志，中途崩溃时标志可能已经置位，但一部分记录仍然是旧密文，后续启动直接跳过它们。，生成新密钥，新数据用新别名加密，然后认为迁移完成。、迁移的逐条状态、旧密钥在确认清理之前的保留，这三件事决定了轮换是可逆的工程操作，还是一次不可逆的数据事故。本地加密存储的密钥轮换，最危险的写法是把。

2026-11-08 22:00:00 66

原创分布式设备列表拿到了，数据通道选错照样传不过去

分布式协作的设计顺序应该是：先确定数据的一致性语义（状态最终一致 vs 操作恰好一次），再选通道（DDO / KV / RPC / 文件），最后把标识和内容分开。离线期间手机加了三个附件，平板重连后 DDO 会把最终的字段列表对齐，中间某一条“附件关联”的副作用如果涉及独立写入，不会因为 DDO 对齐而自动补执行。的 RPC 通道，这四条路解决的是不同的问题。的场景（扣库存、审批、附件关联），DDO 只能承载最终状态，操作序列需要应用层自己的 outbox 和确认水位来兜底。

2026-11-08 21:15:00 337

原创 ArkUI V2 的嵌套观测不是“加个装饰器”，每一层都得自己扛

监听整个数组时，修改数组某一项的属性同样不会触发，需要监听具体项的路径，或者使用 API 26 起支持的通配符。混用，两套观察系统各看各的，修改一个 V2 字段，V1 的组件不会响应，反过来也一样。的路径写到叶子，这三件事做到，V2 的观测链路才是通的。V2 的细粒度更新是真实的，但它的前提是“变化发生的那一层恰好有观察者”。正确的结构不是“给根节点加装饰器”，而是“凡是变化可能发生的那一层，都必须可观测”。链路断在哪一层，变化就停在哪一层。确实“支持深度观察”，于是把最外层类加上装饰器，再试，还是不刷。

2026-11-08 17:03:56 152

原创折叠屏掌机模式不是“分屏”，控显分离是两套输入输出通道

这些能力和控显分离不是互斥的，但它们对渲染后端的要求是一致的：Vulkan。把控制面板的输入抽象成一组离散的“控制指令”（方向、动作、扳机），在控制面板组件内部完成触控到指令的转换，指令通过轻量的事件通道送到渲染侧的输入队列。虚拟摇杆的位移、按钮的按压，需要走独立的输入通道上报给游戏逻辑，而不是和上半屏的触摸事件混在同一个。关键不在于布局怎么切，在于输入事件的路由和渲染的提交是否走了独立的路径。跑起来画面确实在上面、控制在下面，但触控延迟和普通分屏没有区别，摇杆的响应和画面上角色的反馈之间仍然隔着一层。

2026-11-08 16:55:50 143

原创 PersistenceV2.connect 返回 undefined，不是框架的锅

同一个 key，拿到的是共享引用，各自基于旧快照修改不同字段再写回，后写覆盖先写是预期行为。主题和未读数如果在不同 Ability 里独立修改，最终状态取决于写入顺序，不是“最后那个业务上应该赢的”。把写入收口到一个 Manager 里，字段级更新而不是整对象替换，是比换存储方案更直接的做法。但很多人只写了前两个参数，或者第三个参数写了一个返回空对象的 lambda，然后在页面里直接访问。持久化解决“重启之后还在不在”，不解决“谁先写谁后写”。不要在迁移失败时清掉存储，那才是把用户数据弄丢的方式。

2026-11-07 14:37:43 222

原创接上 AVSession 之后，后台播放还是被掐，漏的不是代码是长时任务

官方文档的措辞很明确：应用退至后台时，如果未接入 AVSession，系统会停止音视频播放；类型的长时任务，否则进程仍然会被挂起导致播放停止。AVSession 是播控入口的通行证，长时任务是进程存活的许可证，缺一张都走不通。后台播放的坑，一大半不在“播不播得起来”，而在“播起来之后，系统界面和你的播放器是不是同一套事实”。回调，锁屏面板能显示歌名了，切后台一测——播了十几秒，进程被挂起，声音戛然而止。里同时声明权限和后台模式，两行都要，少一行系统在申请长时任务时直接拒绝。，代码里传的却是别的类型，

2026-11-06 11:02:07 149

原创 Agent Skill 注册之后，用户说“帮我订一杯”为什么还是调不到你的应用

HMAF 2.0 的核心变化是“意图即服务”：你的应用不再只是被打开，而是可以把一部分能力注册成 Skill，让系统智能体按需调度。听起来很顺，但很多团队注册完 Skill 之后，用户一句“帮我订一杯拿铁”，系统仍然没有路由到自己的应用。schema 是系统理解你能力的唯一入口，不是注释。里只写“帮我订一杯拿铁”不够，至少要覆盖“来两杯大杯美式”“点一杯卡布奇诺”这类变体，否则系统学到的只是你写的那一句话。“下单咖啡”是一个 Skill，“查询订单状态”是另一个 Skill，不要把两者塞进同一个回调里。

2026-11-05 17:41:45 187

原创 HarmonyOS 7 瀑布流与长列表性能调优

另一方面，必须使用专门的图片缓存库，或者利用鸿蒙的 Image 组件自带的内存缓存。更关键的是，服务端下发的图片 URL，必须带上 CDN 的裁剪参数，只拉取 300x300 的缩略图，绝不能让客户端下载原图后再去压缩。几百张尺寸不一的商品图，加上复杂的标签和倒计时，只要手指滑得快一点，画面就疯狂掉帧，甚至出现大面积的白块。，并在滑动时观察内存曲线。如果你看到了绿色的内存占用在平稳波动，而不是像心电图一样上下乱跳，说明你的复用策略真正生效了。当新的数据进入屏幕时，直接复用旧的组件实例，仅仅更新里面的数据。

2026-11-04 11:04:59 189

原创 HarmonyOS 7 分布式数据库与跨端状态同步

为了实现这个功能，我们深入了 HarmonyOS 的分布式数据管理（KVStore），这其中的网络玄学和时间戳陷阱，简直让人抓狂。在断开网络的情况下，在设备 A 上添加一条记录，在设备 B 上添加另一条。用户用手机把“买白菜”改成了“买牛肉”，结果平板上离线状态下的修改（比如把时间猜错了）一同步，直接把牛肉覆盖回了白菜。最初的版本，我们使用了系统默认的同步策略：基于时间戳的最后写入者胜出（Last-Write-Wins）。），这样不仅同步快，还能实现细粒度的更新，大大降低了带宽消耗和合并冲突的概率。

2026-11-04 11:04:25 161

原创拒绝白屏的焦虑，HarmonyOS 7 冷启动耗时分析与极致优化

在这个快节奏的时代，用户连两秒钟的白屏都等不了。这样用户点击应用后，瞬间就能看到页面的轮廓，极大地缓解了等待的焦虑感。它允许我们把初始化任务拆分成独立的模块，并配置依赖关系，甚至允许它们并发执行。里声明启动任务后，你可以控制这些任务的执行时机。比如，推送 SDK 的初始化根本不需要在启动时完成，可以设置为。在启动时，系统会去解析这些图片资源，这也是个费时费力的活儿。所有的本地存储读写，必须改成异步，或者直接延后到首屏加载完成之后再执行。，让它在首屏渲染完毕后，再慢慢启动。里发起网络请求的同时，在。

2026-11-04 11:03:24 211

原创 ArkWeb 混合开发的内存泄漏与通信重构

如果你在 H5 页面里用了复杂的 CSS3 动画，比如阴影、渐变和滤镜，能明显感觉到手机背部发热发烫。在鸿蒙的混合开发规范里，能用原生的 Text 和 Image 解决的，千万不要用 Web 组件去渲染。公司的主 App 里嵌套了一个庞大的电商 H5 模块，最近被测试团队打回。如果你的页面被销毁了，但你没有显式去解绑，底层的渲染进程会一直持有你的 ArkTS 对象引用，导致整个页面的内存都无法被 GC 回收。在你的混合应用里，写一个 H5 页面，里面放三个按钮，分别调用原生的弹窗、获取设备信息和关闭页面。

2026-11-04 11:02:18 151

原创 HarmonyOS 7 端侧 AI 图像超分的工程化落地

用户抱怨网络差的时候图片传不上去，更严重的是，大量的私密照片上传到云端，引发了严重的隐私合规审查危机。痛定思痛后，我们决定把 AI 模型直接塞进手机里，用端侧的 NPU 来做推理，但这绝非易事。我们首先在服务端对模型进行了知识蒸馏，把参数砍掉了一大半，然后利用 MindSpore Lite 的转换工具，将模型转成了鸿蒙底层支持的。即便如此，模型依然有 20 多兆，我们最终选择了 FP16 量化，牺牲了极其微小的画质，换取了内存占用减半。推理过程极其消耗 CPU 和内存，稍微大一点的图，处理时间长达几秒。

2026-11-04 11:01:38 156

原创 Hvigor 流水线与包体积极限瘦身重构

那些没有被代码引用的废弃图片、甚至是一些未使用的三方库组件，在编译时被识别出来并自动踢出了安装包。这里必须注意，开启混淆后，要仔细检查实体类的序列化代码，必要时在。配合主模块的依赖声明，在打包时，这部分代码就不会被打进基础安装包，而是等用户真正点击短视频入口时，系统再动态下发。审查项目结构时，我吓了一跳：原本只给 10% 用户使用的短视频模块，居然占了 40MB 的空间，而且和主业务紧紧耦合在 Entry 模块里。没有被包含进来的小语种资源文件，在编译阶段会被彻底剔除，避免无意义的体积浪费。

2026-11-03 17:17:22 282

原创分布式 KV 跨端数据冲突的合并策略

在开发跨设备协作文档应用时，最大的噩梦不是网络断开，而是两台设备分别在离线状态下修改了同一份文档。等它们重新联网同步时，后同步的数据直接覆盖了前面的数据，导致用户的修改凭空消失。此时必须触发预设的业务合并算法（比如把两段文本拼接，或者提示用户手动选择保留哪一份），合并完成后，将本地版本号加一，再重新推送到 KVStore。同时联网后，用你写的版本号合并逻辑去拦截默认的覆盖行为，看看两边最终的数据是否都能保留下来。为了掌控数据的主权，我们必须放弃默认的时间戳策略，在业务层引入版本号机制。

2026-11-03 17:16:40 140

原创高分辨率图像处理与内存防爆重构

由于应用主打图文社交，最近总收到用户投诉，只要发动态时一口气选了 9 张手机拍摄的 4K 高清大图，应用必定闪退。一张 4000x3000 分辨率的手机原图，如果按默认的 RGBA_8888 格式解码，每个像素占用 4 个字节，加载进内存的瞬间，占用就是 4000 * 3000 * 4 字节，约等于。在处理头像裁剪功能时，我发现了一个诡异的现象：即使使用了降采样，只要用户频繁地更换头像，应用的内存依然会在几分钟内缓慢攀升，直至崩溃。本地展示没问题了，但在上传服务器时，原始大图依然会消耗用户大量的流量。

2026-11-03 17:15:48 67

原创打破主线程的桎梏，HarmonyOS 多线程与大数据流转重构

分析内存和 CPU 占用后发现，一个 8MB 的本地 JSON 文件在主线程被强行同步解析，直接堵塞了渲染管线。就是多线程，直到这次崩溃才明白，如果没有使用独立的线程池，所有的计算依然在 UI 线程排队。一个 8MB 的字符串，传给子线程时复制一份，解析成对象后再复制一份传回来。用上 TaskPool 后，界面确实不卡了，但大屏页面频繁切换时，内存直接飙到了 1GB 以上。这里藏着一个极深的警示：主线程传给子线程的参数，以及子线程返回给主线程的结果，底层都会发生一次。关闭它，否则后台线程会一直泄露。

2026-11-03 17:15:09 378

原创从 ArkUI V1 监听泥沼到 V2 精准更新的性能跳跃，重构状态数据流

起初以为只是简单的 API 替换，没想到在一次复杂表单交互中，整个页面出现了严重的掉帧与输入延迟。为了过渡，我试图在一个 V2 的父组件里，塞入一个原本用 V1 编写的子组件。这也是为什么在重构中，我强制团队在涉及数组更新时，必须通过封装好的工具方法来操作。必须精确到需要更新的最底层属性，如果只用在外层对象上，内层的频繁变动依然无法触发 UI 的刷新。变化时，框架能够直接定位到绑定该变量的 UI 节点进行刷新，完全没有多余的遍历。用性能分析工具跑一下，体会一下消除深度代理后，页面渲染性能的直线拉升。

2026-11-03 17:14:25 282

原创警惕后台耗电杀手：HarmonyOS 7 长时任务与进程保活策略

如果你的应用被检测到在后台偷偷运行，不仅会被系统强杀，还会面临上架审核被拒的风险。在你的应用里，写一个简单的倒计时器，每分钟往沙箱里写一行日志。如果你在后台下载一个 500MB 的大文件，千万不能指望长时任务能保佑你跑完。启动长时任务时，系统会强制在通知栏显示一条消息（比如“XX应用正在后台运行”）。如果你不关，系统会一直挂着那条通知，并且持续扣你的电量。，但你的应用在后台根本没有音频流的输入输出，系统的功耗检测机制会立刻察觉，几秒钟内就会冻结你的进程。// 切到后台，如果处于上传状态，才去申请长时任务。

2026-11-02 16:17:35 169

原创跨设备数据同步的深水区，分布式 KV 数据库与冲突合并

用两台设备，在完全断网的情况下，分别修改同一个待办事项的不同字段（比如一台改标题，一台改截止时间）。如果你能通过合并算法让两边最终数据完全一致，并且两个字段的修改都没有丢失，你就掌握了分布式数据的真谛。在所有跨端功能中，数据一致性是最让人头疼的。手机稍微快了几分钟，它发出的数据就会永远覆盖平板上的修改。同时，一定要在同步完成后，及时清理不再需要的无效数据，防止本地库无限膨胀。对于待办事项这种需要严格状态一致的数据，千万不能依赖底层的时间戳。// 按照业务规则合并（比如只要有一个设备标记为已完成，就算完成）

2026-11-02 16:16:48 158

原创脱离 IDE 的自动化构建 HarmonyOS 7 CI/CD 签名与打包流水线

每次发版前，都要在本地打包、重命名、上传到测试平台，不仅浪费时间，还极容易因为手滑拿错版本。配合上代码混淆（Obfuscation），即使被人反编译，也抓不到你的真实接口地址。这要求你在 GitLab 的 CI/CD 变量里，把密码加密存储，并在流水线脚本里通过环境变量注入。在流水线环境中，守护进程会导致文件句柄无法释放，下一次构建时直接报错文件被占用。没问题，但在流水线上跑，极其容易报 Node.js 版本不兼容或者找不到模块。拉取依赖时，如果配置了私有仓库，可能需要凭证。不要用 IDE，打开终端，用。

2026-11-02 16:15:47 220

原创告别卡顿，HarmonyOS 7 低延迟音频采集与处理

如果你发现相邻两次回调的时间差超过 20 毫秒，说明你的设备底层已经被卡顿或者缓冲队列积压了，需要立刻调整缓冲区大小。如果你申请了 AUDIO_RECORDING，但在后台却干着下载文件的事，一旦被系统检测到，直接杀掉进程。如果你直接在回调里做混音、降噪或者写文件，主线程会瞬间被堵死。另外，如果你希望用户在锁屏或者切到微信时，你的语音还能继续录制，必须在启动采集前，申请长时任务（Continuous Task）。但要注意，音频流是连续不断的，如果子线程处理得慢，数据就会在内存里堆积，导致延迟越来越高。

2026-11-02 16:15:05 194

原创从黑屏到秒开，ArkWeb 混合开发中的桥接与资源优化

上周在重构公司内部的营销活动页时，就遭遇了极其严重的性能雪崩。用户在首页点击活动入口，页面不仅白屏了整整三秒，而且只要多进出几次，应用的内存直接飙升到崩溃边缘。最好的方案依然是保证 H5 打包时，接口请求的域和当前加载的域完全一致，配合离线包机制彻底解决网络加载延迟。在 H5 页面里嵌入了一个横向滑动的轮播图，结果发现只要手指在轮播图上滑动，就会触发原生底层的侧滑返回，导致页面直接退出，体验极其割裂。这段逻辑必须配合外层容器的状态监听才能生效，否则 H5 的滑动会和原生导航打架，用户根本没法正常操作。

2026-11-02 16:12:28 185

原创从100MB砍到40MB，HarmonyOS 7 包体积终极瘦身

上周提审新版本，应用市场后台直接给我亮了红灯。提示主 HAP 包体积已经超过了 100MB，限制了我的推荐流量。老板看着数据直摇头：“用户看到 100MB 的安装包，谁愿意下？给你一周时间，给我砍掉一半。我连夜把工程翻了一遍，发现里面全是我留下的“技术债”：各种高清切图、废弃的旧模块、甚至还有几十兆的音视频资源。这篇复盘，记录我是怎么给应用“抽脂”的。

2026-11-01 07:40:26 133

原创摇一摇功能导致 UI 冻结？HarmonyOS 7 Sensor Kit如何防抖

前两天加了一个非常经典的运营需求：“摇一摇”领红包。这功能听着复古，但底层逻辑就是监听手机的加速度传感器。我寻思着直接调 API 就完事了。代码刚写完，QA 跑过来说：“我拿着手机从工位走到饮水机，还没摇呢，你的红包弹窗就弹了五六次。更恐怖的是，一旦弹窗出来，整个屏幕就卡住了，点都点不动。查了性能工具，发现主线程被传感器的高频回调彻底堵死了。

2026-11-01 07:39:34 112

原创选了9张图瞬间闪退？HarmonyOS 7 媒体库与图片加载

社交类 App 必备的功能是什么？发动态。发动态就得选图。我用系统提供的（图库选择器）做了个九宫格选图。QA 拿测试机，一口气选了 9 张相机拍摄的高清大图（单张 10MB 左右），刚点确定，App 直接回到了桌面。内存溢出（OOM）了。Image。

2026-11-01 07:38:40 170

原创后台定位疯狂耗电？HarmonyOS 7 定位服务实战

公司最近做了一个物流配送 App，核心功能是：配送员移动时，后台实时上报位置。我用快速接入了后台定位，本地跑通就直接提测了。结果测试当天下午，QA 拿着测试机跑过来：“你这 App 跑了一小时，手机烫得像暖宝宝，电量掉了 40%，再这样下去谁用啊？我一看日志，好家伙，一秒钟定位了五次，这哪是配送，这是给手机做电焊。这周花了大量时间研究定位的频率控制和状态管理，终于把功耗降到了正常水平。

2026-11-01 07:37:54 179

原创通知栏疯狂弹窗？HarmonyOS 7 Notification Kit 进阶

上周把公司的营销模块重构了一下，加了个“秒杀活动”的本地倒计时提醒。我图省事，直接用起了一个基础通知，然后在后台用每秒去更新一次通知栏的文字。结果 QA 直接把我拉进群，甩了个录屏：手机通知栏疯狂闪烁，伴随着叮叮当当的提示音，整个系统下拉菜单卡得连手势都划不动了。原本以为是个很简单的系统 API 调用，硬生生被我写出了 DDOS 攻击的效果。这篇复盘，记录我是怎么把通知玩坏的，以及正确的姿势。

2026-11-01 07:37:07 155

原创 HUKS硬编码，一个金融级数据加密模块的重构

上个月，公司接了个金融理财类的鸿蒙原生应用。金融类应用，懂的都懂，上架审核极其严苛，对于用户隐私数据（比如身份证、银行卡号、Token）的存储，安全团队直接下了死命令：“绝对不能在沙箱里存明文，也不能把 AES 密钥硬编码在 ArkTS 代码里，一旦被反编译，整个库就裸奔了。我一开始想着，这不简单吗？找个成熟的加密库，把密钥混淆一下，存到里不就行了？结果安全团队直接甩给我一份渗透测试报告，指着被 Hook 到的明文密钥说：“这玩意儿形同虚设。没辙，只能去啃 HarmonyOS 底层的安全机制。

2026-10-31 20:55:31 75

原创编译 5 分钟，改 Bug 两小时，HarmonyOS 7 模块化重构

所以，拆包初期，先别急着动业务代码，先把公共的 UI 库、工具类，干干净净地抽成一个独立的 HAR。一旦模块之间的依赖路径写错（比如 A 依赖 B，B 又依赖 A），Hvigor 构建时直接给你甩个红色大叉，罢工。因为在鸿蒙的底层，所有的资源 ID 都会被映射到一个统一的索引表里。模块化重构，不仅仅是代码物理位置的变化，更是对团队架构设计能力的一次大考。我一开始嫌麻烦，把所有的工具类、UI 组件、业务页面，全抽成了 HAR。更崩溃的是，三个人同时改不同的功能，天天在 Git 上冲突。结果一跑，页面白屏。

2026-10-31 20:53:17 167

原创把卡片的刷新延迟从 5 秒降到 0.1 秒：HarmonyOS 7 桌面卡片实战手记

'green' : 'red')结果用户点开 App，把待办勾选完成了，退回桌面一看，卡片上的内容还在那挂着一动不动。我寻思着是网络延迟，等了 5 秒钟，它终于刷新了。是系统触发的定时刷新，或者是一些特定条件触发的，它根本不是实时的。，它只负责一件事——拿到最精简的数据，画到屏幕上，然后结束。只要数据库有一点变动，哪怕是别的业务表更新了，都触发了卡片的。卡片里不能用 Web 组件，不能用 Canvas，复杂的动画会掉帧，甚至长列表都不建议用。改造完代码，发现卡片终于能实时刷新了，但手机开始发烫，电量尿崩。

2026-10-31 20:51:55 194

原创 HarmonyOS 7 应用接续实录

公司最近在冲刺 HarmonyOS 的全场景体验，产品提了个需求：“用户用手机看视频，走到客厅想换平板接着看，要在平板上无缝续播，连进度条都不能差。在目标设备上，如果数据还没到，显示个骨架屏或 Loading，等数据到位了再渲染，别弄得界面一闪一闪的，看着像 Bug。查一下有没有信任的设备，如果没有，直接把这个功能按钮置灰，别等用户点了报错了再找原因。你在这里面发网络请求，系统早就把你掐断了。我一开始的写法是这样的，想着要把当前播放的数据做一次网络请求拉取，存到。，测试的时候平板一旦在后台，接续就没反应。

2026-10-31 20:50:55 1

原创被一份掉帧日志逼出来的优化：HarmonyOS 7 长列表渲染重构记

我用 DevEco Studio 的 ArkUI Inspector 看了一下渲染树，发现每次滑动时，只要超出屏幕的节点，都会被标记为“销毁”，而新进入屏幕的节点，都会经历一次完整的。另外，组件的 UI 结构必须完全一致，如果你列表里有多种完全不同的样式（比如有的带图片，有的不带），千万别强行复用，否则会出现状态错乱。并不是银弹，它只是提供了一个虚拟列表的骨架，真正让列表活起来的，是合理的组件复用策略和精确到字段的数据更新。这就好比你去餐厅吃饭，每洗一个盘子就把旧的砸了，重新烧制一个新盘子。

2026-10-31 20:47:52 1

原创精准碰一碰的 NFC 标签遇上冷热启动的连环坑写

就为了这个“优雅的碰一碰”，我翻烂了文档，熬了两个大夜。onCreate和onNewWant缺一不可。这是鸿蒙系统拉起应用的标准逻辑，做通知跳转、深链跳转都必须两者兼顾。AGC 后台的域名校验。如果你发现手机能识别标签，但死活不拉你的应用，99% 是因为你的域名没在后台校验或者校验失效了。UI 更新不要写在 Ability 里。这是架构设计的底线，数据流转一定要用AppStorage或EventHub做中转，交给 UI 页面自己去消费。希望后来者看到我这篇踩坑日记，能少走点弯路，早点下班。

2026-10-27 16:52:57 397

原创用 Web 组件重构 HarmonyOS 7 H5 页面加载与生命周期管理

重构完这个商城模块，我最大的感触是：Web 组件虽然强大，但绝不能把它当成一个简单的黑盒。原生和 H5 的边界越模糊，生命周期和内存管理就越容易出事故。所有的 Bridge 方法，都要加 try-catch。H5 可能会传不规范的数据，别让原生进程陪葬。没网的时候，一定要有兜底的 H5 错误页。别让用户看着系统级的 404。如果你的 H5 要调用相机、定位等敏感权限，务必在原生层拦截并申请。H5 内部的在鸿蒙中支持度有限，直接用原生桥接最稳妥。

2026-10-26 12:25:18 42

原创 HarmonyOS 7平行视界，一个 easy_go.json 让 App 在大屏自动双栏

平行视界不是替代手写响应式布局的方案，它是给那些"来不及做大屏适配但又不想在平板上显示一条竖栏"的 App 准备的兜底方案。当你的 App 在平板、折叠屏展开态等宽屏设备上运行时，系统可以把两个页面左右并排显示在一个窗口里——左边是主页，右边是从主页跳转过去的二级页。这意味着左栏的列表页不会被销毁，右栏的详情页加载时，左栏仍然在运行。写错文件名系统读不到，分栏不生效，而且不会报错——这是最坑的地方，没有任何提示，你只能自己排查。正确的做法是：在平行视界模式下，返回键应该先关右栏，右栏关完再关左栏。

2026-10-24 13:46:06 790

空空如也

空空如也