- 博客(368)
- 收藏
- 关注
RSS订阅原创 HarmonyOS 7 NearLink：星闪广播advertisingId串线与会话收口
PulseBeacon轮换失败源于异步句柄与状态的竞态：全局advertisingId被新旧任务交叉读写，导致停止错误广播。通过引入代次（epoch）和局部变量捕获、串行化轮换链、纯函数构建参数、回调单次注册及完整释放，实现状态机收敛。核心是“代次+局部句柄”确保每个异步分支只操作自身会话，杜绝误停。最终保障30秒定时轮换稳定，接收端持续收包。
2026-10-06 14:35:26
1
原创 HarmonyOS 7 RxJS：WebSocket重连双重订阅与序号缺口回放
OpsStream 通过拆分连接、回放与视图三态，解决重复派单问题。引入四状态（DISCONNECTED→CONNECTING→SYNCING→LIVE）精准追踪连接与数据同步进度，用 SequenceGate 在事件处理前校验序号，杜绝重复与缺口。采用 shareReplay({refCount: true}) 确保连接随最后一个订阅者释放，避免僵尸连接。代码层面重构 WebSocket 生命周期管理，实现稳定、可观测的实时流架构。
2026-10-06 14:32:25
原创 HarmonyOS 7 floatView：闪控窗重复启动1300031与会话代次隔离
9 月底把派送路线做进闪控窗时，我原以为最难的是窗口尺寸。真正把测试包卡住的却是一条很短的日志：用户连续点两次“开启随行窗口”，第一次start()已经返回，第二次仍然报 1300031；偶尔主页面明明显示“已停止”，旧控制器的STARTED回调又把状态改回“运行中”。窗口本身没有复制出两个，但业务层已经同时相信两个互斥事实。这次 Demo 叫，入口页是，闪控窗内容页是，任务号固定为FV-1012。路线为“东门仓 → 科技园 B3”，共 7 件包裹，当前进度 68%，预计 12 分钟。
2026-10-06 14:29:16
原创 HarmonyOS 7 ArkTS+Ajv：动态表单热切换缓存污染与错误归一化
本文记录了在 SchemaDock 项目中，因缓存失效、并发验证与错误状态管理不当导致的页面卡顿与校验结果不一致问题。通过引入基于业务名、版本与哈希的稳定键、严格白名单验证、同步深拷贝错误快照并绑定页面代次、以及将动态路径映射为固定字段 ID，最终实现校验结果稳定、缓存高效、回归可复现。
2026-10-06 14:25:55
1
原创 HarmonyOS 7 XComponent：取帧重入110002隔离与结果代次对齐
FrameLens Demo 解决了图像 AI 分析在动态画面中的并发与状态同步问题。通过引入 surfaceEpoch + frameSeq 双重令牌，确保异步结果仅更新当前有效画面；采用“单飞+最新覆盖”策略，实现队列峰值恒为1，避免重复分析与状态错乱。核心 AnalyzerGate 以微任务驱动补跑，保障最终帧不丢失，同时严格校验代次，杜绝旧帧污染。页面仅在完整校验后更新 UI，实现“所见即所得”的精准反馈。
2026-10-06 14:22:30
1
原创 HarmonyOS 7 NDK+CMake：HAR合并libc++版本漂移与依赖闭包
摘要（148字）： 发布候选包因引入旧SDK构建的vision_bridge.har，导致Release HAP合包时混入多个libc++_shared.so，运行时符号不匹配引发崩溃。虽源码一致，但依赖闭包未校验，最终通过扫描器在HAP落盘后验证动态依赖、RUNPATH及符号提供情况，确保仅保留一份同源C++运行库，并强制使用C ABI隔离跨模块耦合，修复了隐蔽的ABI兼容性问题。
2026-10-06 14:19:56
原创 HarmonyOS 7 Preferences：三方SDK延迟装配与撤回清理
本文剖析了一次因隐私协议升级引发的合规漏洞：旧版同意状态未及时清理，导致三方SDK在用户未重新确认前即完成初始化。通过将布尔值同意状态升级为带版本与摘要的凭据，结合UIAbility生命周期驱动的闸门机制，实现“先核验、后装配”的安全流程。引入可逆序清理的SDK注册表，确保资源释放幂等可靠；最终以状态机统一协调全链路行为，杜绝重复初始化与监听泄漏，达成“0次重复初始化、0个监听泄漏”的稳定态，验证了从“页面抢跑”到“生命周期协同”的架构演进价值。
2026-10-06 14:09:51
1
原创 HarmonyOS 7 Zod 4：远程灰度配置运行时收窄与坏快照回滚
FlagHarbor 通过 Zod 4 实现远程配置的运行时校验，杜绝“解析成功即有效”的误区。结合请求代次与 generation 比较，确保异步请求按序提交，避免过期响应覆盖最新状态。最近好快照必须经同一 Schema 验证后写入，防止旧缓存污染。最终实现页面稳定回退至安全配置，真正达成“不可信输入 → 可信快照 → 安全应用”的闭环。
2026-10-06 14:07:00
1
原创 HarmonyOS 7 Display Kit：折叠姿态抖动下列表锚点保持
这类问题很容易被“看起来没跳”误导。动画把滚动遮住，不代表状态正确。我最后固定了四个验收项。第一，当前布局只能由最新 epoch 写入，。第二，recipe_042在折叠前后都位于视口顶部下方36 vp，允许 2 vp 的渲染误差。第三，进入并退出页面 20 次后，折叠监听和窗口监听都只存在一份，销毁时注销数量为 2。第四，条目在过滤后不存在时，页面回到安全位置并产生诊断，不崩溃、不滚到随机下标。最终运行状态是STABLE：原始事件 7、提交 2、丢弃旧任务 5、恢复 2、错误 0。
2026-10-06 14:03:45
原创 HarmonyOS 7 Ability Kit：碰一碰票据版本校验与幂等恢复
本文通过一次“碰一下恢复两遍”的故障，揭示跨设备接续中幂等性与状态一致性的重要性。作者以TapRelay Demo为例，提出构建带版本、时间、nonce的接续票据，明确源端仅签发不宣告成功，目标端先校验后恢复，并采用“先占用、再改页面”的幂等机制，确保重复请求不破坏用户数据。核心在于：交互越快，越需严谨的会话层防护。
2026-10-06 14:00:55
原创 HarmonyOS 7 Spatial Recon：3DGS前后台切换与迟到回调隔离
应用切后台导致进度倒退，根源在于运行模式与业务状态未分离。通过引入epoch机制隔离回调、保持会话跨前后台存活、严格区分runningMode与stage，并由桥接层统一管理生命周期，最终实现状态稳定流转。关键措施包括：启动后立即设置运行模式、回调携带epoch校验、轮询结果按epoch比对、页面仅转发事件不操作会话。最终任务GS-1328成功构建模型bronze_lion_07，完成3次前后台交接，丢弃2次旧回调，无数据丢失。
2026-10-06 13:57:35
原创 HarmonyOS 7 Hvigor+ts-morph：权限声明双向差分门禁
本文介绍了一套针对HarmonyOS应用权限的自动化门禁系统，通过解析module.json5、AST扫描运行时请求、集合差分比对，实现对敏感权限声明与使用的一致性校验。系统将权限分为声明、运行时请求、未解析调用三类集合，精准识别“缺失”与“孤儿”权限，并输出可追溯的处置建议。关键创新在于：权限元数据版本化管理、动态代码路径证据留存、不可自动修复的阻断机制，确保隐私合规可审计。最终以REVIEW-1346为例，实现从BLOCKED到PASSED的闭环验证，日志清晰可复现，支撑提审流水线高效通过。
2026-10-06 13:54:54
原创 HarmonyOS 7 ArkUI无障碍：动态清单朗读焦点续接与语义分组
摘要（148字）： FocusLedger 修复无障碍问题 A11Y-1818，通过语义树重构解决朗读时焦点跳失、重复播报等缺陷。核心策略为：任务卡设为无障碍组，显式定义播报文本；焦点续接基于业务 ID 而非数组下标；引入 FocusContinuation 与 SemanticsProbe 实现筛选后焦点稳定恢复与本地预检可追溯。最终达成上架报告 score=100，四项异常归零，保障视障用户流畅操作。
2026-10-06 13:47:28
2
原创 HarmonyOS 7 + decimal.js：多币种十进制定点计算与余差归集
账单差两分钱源于舍入误差累积。SplitMint 通过字符串输入、decimal.js 精确计算与最大残差法分配余数，确保结果可复现。快照哈希基于标准化输入与算法版本生成，杜绝因汇率波动或页面重载导致的不一致。关键在于：全程使用字符串传参、仅在最终输出时转 toFixed(2)，余差按残差排序补给，且快照幂等性由代次控制，实现确定性结算。
2026-10-06 13:44:28
2
原创 HarmonyOS 7 Media Library：文搜图索引增量失效与墓碑回收
摘要： IndexTide 项目因增量索引更新机制缺陷，导致已编辑或删除的图片仍被召回。问题根源在于将系统媒体变化通知误作“新增”处理，未区分语义变更与物理变动。通过重构为“通知-合并-扫描-提交”四层架构，引入代次（epoch）控制并发、基于 uri+modified+size 的轻量指纹判断是否重算向量，实现精准增量更新。最终确保索引状态与真实资产一致，避免脏数据与并发冲突。
2026-10-06 13:40:48
1
原创 HarmonyOS 7 + RxJS：扫码回调风暴与窗口背压
摘要（149字）： PulseShelf 仓库盘点页因扫码回调风暴导致页面卡顿、重复更新。原因在于直接响应原始回调，未做去重与代次隔离。通过引入 ScanEvent 封套带代次（epoch），结合 bufferTime(200) 合并同码、保留异码，配合 takeUntil 管理生命周期，实现精准批次提交。页面退出前先阻断接收，再停止硬件与销毁订阅，确保迟到回调被忽略。最终将 300 次回调压缩至 12 次有效提交，状态机清晰可控，彻底解决压测问题。
2026-10-06 13:37:50
原创 HarmonyOS 7 Spatial Recon：3DGS采集帧与位姿纳秒对齐
PoseClock 重建异常源于图像与位姿时间戳不同步，最大偏差达18.6ms。通过引入显式时间配对机制，以纳秒级时间戳匹配最近位姿，设置8ms容差门限，拒绝偏差过大帧，实现240帧中226帧有效接收，p95偏差降至5.8ms。关键改进包括：基于epoch的会话隔离、拒绝前预判配对、避免乱序数据污染、以及前后端状态同步机制，确保重建稳定可靠。
2026-10-06 13:34:38
原创 HarmonyOS 7 + Axios：并发401单飞刷新与请求回放
TokenHarbor 通过六个并发请求触发的 401 问题，揭示了令牌刷新机制的深层缺陷。旧方案导致重复刷新、状态错乱与登录页跳转。最终采用“单飞刷新”策略：隔离 apiClient 与 authClient，共享一个 refreshFlight Promise，限制回放次数为一次，并结合 AbortController 实现请求取消。关键改进包括：拦截器按需安装/卸载、请求前动态读取令牌、避免递归刷新、以及精准控制生命周期。最终实现并发 6 请求、仅刷新 1 次、零失败，达成稳定会话修复。
2026-10-06 13:31:49
1
原创 HarmonyOS 7 SlideDrop：多设备坐标准确率与一致性验收
SlideDrop第06篇聚焦三类设备画像（平板、PC窗口、折叠屏）的可重复回归测试，覆盖六大核心场景：目标窗口识别、坐标变换、幂等提交、大文件断点恢复、离线重放与冲突处理。通过20轮完整链路验证，实现100%坐标命中率、零重复提交、零重放错位、零会话冲突，平均解析延迟7.2ms，大文件恢复P95为2460ms，内存增长仅+0.9MB，全面验证系统在多形态设备下的稳定性与一致性。
2026-10-06 13:27:00
2
原创 HarmonyOS 7 SlideDrop：ArkData离线重放与会话恢复
SlideDrop第05期聚焦跨生命周期一致性，通过持久化Session与Commit History实现重放防护。引入双层幂等：内存去重应对瞬时重复，历史记录保障重启后不丢不重。关键机制为先查历史命中，再比对本地版本，冲突时采用KEEP_LOCAL_NEWER策略，确保用户最新编辑不被覆盖。结合ArkData Preferences存会话、独立Repository管理提交历史，实现高效恢复与版本安全。
2026-10-06 13:24:18
1
原创 HarmonyOS 7 SlideDrop：UDMF大文件异步加载与断点恢复
SlideDrop 通过升级坐标链与引入 LazyPayloadProvider，实现大文件（84.6MB 视频）投递的高效体验。核心在于：先快速展示预览与目标槽位，真实数据分块按需传输；依托 UDMF 标准化元数据与断点续传机制，确保失败后可恢复、不重复提交；仅在全部分块完成并校验无误后才 Commit，保障状态一致性。全程性能分层可观测，预览临时、正式素材分离，实现“触碰即反馈、传输可恢复、完成无残留”的稳定体验。
2026-10-06 13:21:22
1
原创 HarmonyOS 7 SlideDrop：坐标变换与触点重映射
本文聚焦 SlideDrop 第三篇，解决复杂视图变换下的精准坐标映射问题。面对缩放（1.25x）、滚动（96/60vp）等动态布局，系统构建了标准化的坐标变换链：窗口坐标 → 本地坐标 → 加滚动偏移 → 除以缩放比例，得到逻辑画布坐标。引入 geometryVersion 保障布局一致性，确保事件锁定时上下文可追溯。同时，DropZone 定义于逻辑坐标系，支持跨尺寸兼容；并严格限制在几何稳定态（READY）才执行投递，避免动画中误判。最终实现触点精准落槽，为高保真交互奠定基础。
2026-10-06 13:18:23
7
原创 HarmonyOS 7 SlideDrop：UDMF素材封装与重复触碰去重
本文聚焦 HarmonyOS 拖拽场景下的精准投递与幂等性保障。通过 UDMF 标准化封装多条记录（图片+文本），实现跨应用数据统一；采用 PendingCommit 保证原子提交，避免半成功状态；基于 sessionId + digest + targetSlot 构建 800ms 去重窗口，由 DedupCommitManager 在提交前拦截重复事件。强调去重逻辑应置于接收链路而非 UI 层，且 800ms 为工程经验值，非系统协议，需结合业务实际调整。
2026-10-06 13:15:09
4
原创 HarmonyOS 7 SlideDrop：Precise Share目标窗口与触碰坐标
HarmonyOS 7“碰一碰·精准分享”实现核心在于将触碰坐标与目标窗口精准绑定。本文以SlideDrop为例，解析如何将系统传入的窗口与坐标，转化为业务槽位。关键步骤包括：校验targetWindowId、转换窗口坐标为局部坐标、基于动态布局匹配槽位，避免硬编码。通过抽象几何状态与归一化坐标日志，确保跨设备、缩放场景下的准确性。最终状态TARGET_LOCKED标志着精准定位成功，为后续传输奠定基础。
2026-10-06 13:12:19
4
原创 HarmonyOS 7 FlexDesk：Metrics多尺寸多设备回归验收
FlexDesk 06 完成五种输入/窗口 Profile 各8轮共40次回归测试，全通过。重点验证布局、导航、折叠、焦点、快捷键等核心状态在反复切换下的连续性与稳定性，实现0错误、0内存泄漏、0内容重建。平均布局耗时2.2ms，导航2.6ms，折叠4.3ms，输入0.9ms，性能基线清晰可追溯，为后续版本迭代提供可靠验收标准。
2026-10-06 13:04:14
15
原创 HarmonyOS 7 FlexDesk：Pointer键盘焦点导航与快捷键一致性
FlexDesk 05 版本聚焦桌面端交互一致性，突破触屏思维定式。通过 onHover 实现悬停反馈、bindContextMenu 绑定右键动作、焦点链支持 Tab/方向键导航，并统一键盘快捷键与鼠标操作的业务逻辑。关键成果：12 个可获焦组件无丢失，4 次快捷键命中，右键菜单精准绑定任务，状态隔离清晰，实现触屏、鼠标、键盘输入下同一业务状态一致体验，为跨设备交互奠定坚实基础。
2026-10-06 13:01:19
4
原创 HarmonyOS 7 FlexDesk：FoldStatus折叠态与编辑草稿保持
第一组，FOLDED 430vp，SINGLE。第二组，EXPANDED 920vp，DUAL。第三组，HALF_FOLDED 720vp，HOVER。第四组，再展开，详情仍然是 task_1042。第五组，再折叠，草稿仍然 128 字。第六组，cursor=96 / scroll=384vp / unsaved=true 全程保持。第七组，五次形态变化中。才成立。
2026-10-06 12:58:11
41
原创 HarmonyOS 7 FlexDesk：Multi-Window连续缩放与信息密度降级
FlexDesk 03 优化多窗口适配：通过合并高频 windowSizeChange 事件（18 次仅提交 6 次），结合 48ms 节流，实现布局稳定；引入 MINIMAL 断点（<420vp），基于窗口宽度动态降级信息密度，而非缩放 UI；详情面板显隐与任务状态解耦，确保业务连续性；密度策略封装为纯函数输出，提升可维护性。最终实现窗口拖动中“状态不抖、体验流畅、信息不失”。
2026-10-06 12:55:27
28
原创 HarmonyOS 7 FlexDesk：Tabs与SideBar导航选中态连续性
第一组，430vp：底部 Tabs。第二组，720vp：侧栏 Tabs。第三组，920vp：侧栏 + 详情面板。第四组，selectedIndex 始终为 1。第五组，始终一致。第六组，滚动位置保持 384vp。第七组，920 → 430 → 920，详情状态仍然恢复，内容重建次数为 0。才成立。
2026-10-06 12:52:26
15
原创 HarmonyOS 7 FlexDesk：windowSizeChange与DynamicLayout窗口断点
第一组，430vp 打开，必须是 COMPACT。第二组，720vp，必须切 MEDIUM，两列。第三组，920vp，必须切 EXPANDED，三列。第四组，920 → 430，task_1042仍然选中。第五组，来回拖动以后，草稿仍然 128 字符。第六组，五次窗口事件结束后，六张 TaskCard 都没有重新初始化业务状态。才成立。
2026-10-06 12:49:46
32
原创 HarmonyOS 7 JsonPulse 适配实录06：Metrics回归验收与资源基线
JsonPulse 06 完成最终回归：5个数据集 × 2个ABI × 4轮 = 40次全量验证，全部通过。重点聚焦正确性闭环与资源安全，确保跨ABI结果一致、错误契约匹配、异步流程无泄漏。性能按环境独立基线，内存稳定增长可控，符号与SDK检查严格准入。核心成果：零解析/错误/回调/资源泄漏，为HarmonyOS原生JSON解析能力奠定坚实基础。
2026-10-05 17:01:00
155
原创 HarmonyOS 7 JsonPulse 适配实录05：HAR预构建SO与ABI分发打包
JsonPulse 从 Demo 演进为可复用 Native 库，完成多 ABI 构建、C++ 符号边界隔离、libc++ 版本对齐与依赖验证。通过 HAR 包封装、C_ONLY 接口设计、自动符号检查及 Consumer 端零配置集成，实现稳定、安全的跨应用共享，具备发布为公共包的工程能力。
2026-10-05 16:58:11
5
原创 HarmonyOS 7 JsonPulse 适配实录04：ThreadSafeFunction线程安全回调
将48MB JSON解析移至napi_async_work异步执行，避免阻塞主线程，维持UI流畅。进一步引入napi_threadsafe_function实现安全进度通知，每5%触发一次回调，减少冗余开销。取消操作通过原子标记实现，不强制终止线程，支持任务重试。核心机制：Worker仅传递原生数据，由主线程构造ArkTS值并调用回调，确保跨线程安全。最终实现高响应、可取消、可监控的异步解析链路。
2026-10-05 16:55:33
133
原创 HarmonyOS 7 JsonPulse 适配实录03：napi_async_work异步解析与Buffer所有权
JsonPulse 03 重构异步解析线程模型，将输入从同步借用改为显式拷贝至 Native Own Buffer，实现异步生命周期可控。通过 napi_async_work 统一管理 Promise、工作对象与缓冲区，确保并发安全。尽管引入 7.8ms 拷贝成本，但换来主线程流畅（58.9fps），解析耗时 182.4ms 在独立线程执行，避免 UI 卡顿。关键改进：异步上下文封装、execute_cb 不用 env、资源闭环释放，达成稳定高性能异步解析。
2026-10-05 16:52:58
7
原创 HarmonyOS 7 JsonPulse 适配实录02：Uint8Array与Buffer零拷贝边界
JsonPulse 02 通过将输入改为 Uint8Array，实现 Native 层零拷贝桥接，消除 ArkTS 字符串转换开销。关键优化包括：使用 napi_get_typedarray_info 精确获取字节指针、采用 parse_unpadded 模式避免额外填充、确保缓冲区生命周期安全。实测 4.8MB JSON 解析耗时从 43.7ms 降至 26.1ms，节省 17.6ms，验证了桥接层“无全量拷贝”的可行性，同时明确“零拷贝”仅限于桥接边界，不等于系统级无复制。
2026-10-05 16:50:03
7
原创 HarmonyOS 7 JsonPulse Native三方库适配实录 01：simdjson × Node-API：CMake接入、模块注册与首个Native解析接口【鸿蒙心迹】
Native 解析很快→ Native → ArkTS 大量对象转换→ 桥接成本重新变大recordsfieldsmaxDepthparseCosterrors也就是说，先证明：simdjson 的核心能力确实已经进入工程，而不是先把跨语言边界做成另一个性能瓶颈。第一组，合法 2.4MB JSON，正常返回摘要。第二组，非法 JSON，errors 不为 0。第三组，ArkTS 传空字符串，Native 返回明确参数错误。第四组，模块名与 so 名不匹配，构建阶段直接发现。
2026-10-05 16:44:28
132
原创 HarmonyOS 7 PixelForge 图像超分工程实录 06：Metrics × Regression：多尺寸、多格式、耗时、内存与结果一致性验收【鸿蒙心迹】
PixelForge第六篇回归测试以固定5类多尺寸、多格式图像（JPEG/PNG/WebP/HEIF/Tiled JPEG）执行12轮，共60次验证，全部通过。测试聚焦真实工程收口：输出尺寸一致性、格式能力探测、单图与瓦片超分耗时（平均319ms，P95 438ms；Tiled P95 1682ms）、内存峰值（最高171.2MB）与循环后基线（+1.1MB）、资源释放（活动资源为0）、缓存误命中检测（0次）、恢复一致性等。结果表明系统在复杂场景下稳定可靠，具备版本间可比性与生产可用性。
2026-10-05 16:30:37
12
原创 HarmonyOS 7 PixelForge 图像超分工程实录 05：Stage × ImageSR：前后台切换、结果写盘与异常恢复【鸿蒙心迹】
第五篇聚焦超分任务在后台中断后的恢复机制。PixelForge采用“状态持久化”而非依赖后台运行，通过SrTaskJournal记录任务关键信息（如阶段、临时文件路径），确保进程重启后可准确恢复。恢复时先校验临时文件完整性，再原子性提交为正式文件，避免重复计算或读取半成品。核心原则：不依赖运行时对象，以文件证据驱动状态判断，实现可靠、高效、低开销的断点续传。
2026-10-05 16:27:51
5
原创 HarmonyOS 7 PixelForge 图像超分工程实录 04：ArkData × SR Cache：超分结果缓存、源图变更与版本失效【鸿蒙心迹】
PixelForge 04 版本引入智能缓存机制，通过 sourceHash、scale 与 modelRevision 构建唯一 cache key，实现内容寻址，避免文件名覆盖导致的错误复用。缓存仅存储轻量索引，真实结果保留在文件系统，结合“两阶段提交”确保一致性。首次计算耗时 341ms，二次命中仅 17ms，节省 324ms，且不立即解码大图，降低内存占用。源图变更自动失效旧缓存，支持后台清理 stale 条目，TTL 7 天为可配置策略，兼顾性能与资源管理。
2026-10-05 16:25:09
7
原创 HarmonyOS 7 PixelForge 图像超分工程实录 03：ImageSR × Region Decode：大图分块、重叠边界与拼接缝治理【鸿蒙心迹】
第三篇聚焦大图超分的内存瓶颈，提出“区域分块处理”方案：基于4439×2959大图，采用含96px输入重叠的四块非均分切分策略，通过Region Decode仅加载当前区块，避免整图PixelMap占用。每块独立解码、超分、裁剪重叠区后拼接，输出重叠288px用于羽化融合。峰值内存降至168.9MB，释放8个PixelMap，拼接缝差异从12.8%降至1.9%，实现高效低耗的大图超分。
2026-10-05 16:22:25
9
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人