- 博客(668)
- 收藏
- 关注
RSS订阅原创 HarmonyOS 7 平行视界实战 05：生命周期、恢复与成品化打磨，完成“双栏研读台”最终收尾【鸿蒙心迹】
第五篇聚焦“双栏研读台”的收尾与成品化，不再新增功能，而是强化生命周期管理、状态恢复与工程规范。通过重构目录结构，将状态、路由、存储分离；定义统一的RestoreSnapshot快照协议，精准保存分栏比例、滚动位置等细节；引入StateSyncService实现跨场景状态同步与持久化。重点解决应用重启、切后台、多设备适配下的自然恢复问题，使Demo从“可演示”迈向“可交付”的原型阶段，真正体现工程闭环能力。
2026-10-27 16:09:08
291
原创 HarmonyOS 7 平行视界实战 04：分栏比例 + 状态同步解决“双栏研读台”多尺寸适配问题【鸿蒙心迹】
第四篇聚焦“双栏研读台”在HarmonyOS平行视界下的响应式体验，提出基于窗口宽度的智能分栏比例系统。通过定义可解释的RatioType模型与断点策略（<900:1:1, 900–1360:1:2, ≥1360:2:1），实现自动适配；结合LayoutService与StateSyncService，确保比例切换时阅读状态（文章、滚动位置等）可恢复、可同步。项目结构清晰分离布局与状态逻辑，使双栏体验在不同设备上保持一致性，真正实现“像同一个产品”。
2026-10-27 15:46:57
139
原创 HarmonyOS 7 平行视界实战 03：导航固定 + 覆盖切换重构“双栏研读台”大屏阅读体验【鸿蒙心迹】
本文聚焦大屏阅读中“固定导航+覆盖切换”模式的实现，解决第二篇“连续推进”带来的导航混乱问题。通过明确三条产品规则：左侧导航不动、右侧覆盖切换、返回仅恢复内容区状态，构建稳定体验。项目目录工程化拆分，引入FixedNavLayout、OverlayRouteService与ReadingSessionStore三核心组件，重构Index.ets为总装配台，以Stack结构实现内容层覆盖。强调导航职责单一——维持用户方向感，最终实现结构清晰、切换明确、返回可溯的大屏阅读链。
2026-10-27 15:30:55
232
原创 HarmonyOS 7 平行视界实战 02：左右推挤 + 路由关联完善“双栏研读台”连续浏览链路【鸿蒙心迹】
“双栏研读台”第二篇聚焦于构建连续阅读链路，通过Navigation路由系统实现文章间的层级推进，区分push与replace，确保浏览路径可追踪。引入路由历史、去重机制与来源标记（list/related），提升体验连贯性与可维护性。明确应用路由与系统平行视界职责分离，为大屏连续浏览提供清晰、可持续的架构基础。
2026-10-27 15:18:07
271
原创 HarmonyOS 7 平行视界实战 01：Navigation + ArkUI 搭建“双栏研读台”第一版分栏阅读【鸿蒙心迹】
本文聚焦于构建HarmonyOS平行视界下的“双栏研读台”第一版，核心是搭建稳定的页面关系骨架：通过Navigation分栏模式实现左列表、右详情的主从结构，使用NavPathStack管理路由切换，确保大屏下双栏布局的可演进性。项目目录清晰，优先用模拟数据验证分栏逻辑与点击跳转流程，不追求功能复杂度，为后续“左右推挤”“固定导航”“比例自适应”等交互能力的逐步扩展奠定基础。
2026-10-27 14:28:34
322
原创 HarmonyOS ohpm install × Git diff：三方库锁文件意外变更的发布前门禁【鸿蒙心迹】
同一个 HarmonyOS 工程，在开发机上安装第三方库之后可以正常启动，到了发布分支却多出一份没有人解释的锁文件变化。这时最麻烦的往往不是“到底哪个包升级了”，而是根本不知道变化来自主动更新、清理缓存之后的重装，还是有人随手执行了安装命令。等到上架构建报错再去倒查，版本记录、安装日志和提交历史通常已经分散。本文做一个很窄的发布前门禁：识别 Git 工作区中依赖清单与锁文件是否出现未经解释的变化，并把差异交回给维护者复核。这里需要先划清官方能力和项目脚本的边界。是工程或模块的依赖声明文件，
2026-10-21 14:08:47
42
原创 HarmonyOS ArkUI Slider × Stack：超分前后对比滑杆的零宽保护与位置校准【鸿蒙心迹】
做图片超分功能时，最容易吸引注意力的是处理后有多清晰。但真正给用户验收效果的页面，往往只是两张照片和一根可以左右移动的滑杆。它看起来很简单，却有一个容易忽视的问题：比对位置应当对应原图和增强图中的。如果布局初始宽度尚未确定，或者前后图以不同裁切方式铺满容器，视觉上就会出现“滑杆移动，山峰也跟着跑”的错觉。本文不实现超分算法，而是把比对组件本身做成有明确边界的 ArkUI Demo。
2026-10-21 14:04:27
95
原创 HarmonyOS ArkUI focusControl × id：平行视界列表重排后的焦点定位与失效回退【鸿蒙心迹】
更糟的是某条结果被过滤后，开发者继续请求一个已经不存在的组件 ID，只看到焦点请求失败，却没有可预测的回退路径。双栏资料浏览器有一个不太显眼的问题：内容换成了第二条，蓝色选中态也停在第二条，但接上键盘继续操作时，焦点可能回到第一条。另外，示例把已选中的 N-902 保存在父组件中，不依赖点击后的页面栈来恢复，因此也不等同于 Navigation 自动替应用保存焦点。这份方案的价值不在于创造新的“平行视界 API”，而是把列表业务键、焦点目标 ID、焦点请求受理和焦点实际落点拆成可核查的四个量。
2026-10-21 13:59:25
70
原创 HarmonyOS ohpm list × Node.js fs：三方库目录体积阈值与资源副本预检【鸿蒙心迹】
可靠的脚本至少应检查目标是否仍落在项目根下，区分普通文件与目录，拒绝跨目录的符号链接，并将读取失败当成明确错误而非记作零字节。示例对候选资源读取字节并计算 SHA-256，先按字节数分桶，再对疑似相同的内容求摘要，最后给出资源对。查看已安装依赖关系，人工或由 CI 维护一份被批准的目标目录映射，再让 Node.js 读取这些确定路径，不去猜某个版本的内部 lockfile 结构。这种做法少了一点“全自动发现”的炫目，却更容易审核：扫描范围是受控的，某个目录变了要修改配置，而不是让脚本在整个。
2026-10-21 13:55:02
65
原创 HarmonyOS ArkUI GridRow × accessibilityText：折叠屏大字模式下操作卡片的断点与朗读校验【鸿蒙心迹】
但当用户把系统字体调大，或者应用处于窄窗口时，标题变成两行，按钮的朗读信息却依然只有一个“查看”，四张卡片都是相同提示。这个函数只是测试用的契约校验，不属于 ArkUI 或系统无障碍 API，更不能替代真实聚焦和朗读顺序的体验测试。在本例里，四个按钮可见文字都叫“查看”，却分别设置“文档管理，查看”“图片处理，查看”等上下文标签。第四次开启屏幕朗读，从 A-01 依次移动到 A-04，记录实际读到的标签、动作、描述，以及聚焦跳转顺序。则为相邻卡片留出间距，不能用一个很大的空白文本元素强行撑开布局。
2026-10-21 10:34:09
176
原创 HarmonyOS 3DGS × Node.js：相机位姿时间戳与角度单位的重建前门禁【鸿蒙心迹】
前一轮已经讨论过输入帧序与缺口，这里换一个更深的位置：帧号连续只说明文件清单能排上队，不能证明同一场景的位姿元数据可用。3DGS 项目最让人头疼的环节未必是建模，而是输入数据看起来齐全，实际却有两类难以肉眼发现的元数据问题：相机位姿中的角度单位没有统一，或者采集时间戳在导出、合并时倒退。它不会触发拍摄，不会重建点云，不会向远端服务提交素材，反而方便把隐私敏感的拍摄数据与审计摘要分开保存。如果未来需要真正联动，需要另做可信的报告传递、签名和读取流程，不能把图片里的“导出预检清单”按钮当作已实现的系统能力。
2026-10-21 10:29:40
108
原创 HarmonyOS ArkUI ForEach × ArkTS Map：闪控窗候选提醒的 TTL 淘汰与重复合并【鸿蒙心迹】
本文代码和配图用于说明工程设计，示例时间、订单号、日志及屏幕都是；不表示已在 DevEco Studio 编译或真机跑通，也不表示接通系统闪控窗。所谓“候选提醒”，专指应用自行管理的展示列表。
2026-10-21 10:24:23
190
原创 HarmonyOS ArkUI $r × Node.js：上架前多语言占位符漂移与回退清单审计【鸿蒙心迹】
文章、日志、审核结果与配图均为，不是华为应用市场官方审核结论、真实审核接口调用或已完成的真机测试。本文的“BLOCK”只表示团队自定义发布门禁未通过。
2026-10-21 10:19:58
170
原创 HarmonyOS ArkData Preferences × ArkTS：精准碰一碰确认超时与撤回恢复【鸿蒙心迹】
Demo：TouchConsent｜任务编号：TP-206｜业务素材：DOC-418 / 会议资料.pdf / 2.3 MB内容性质：精准碰一碰的业务确认层方案。数据、日志、示意界面均由案例构造，未接入或实测系统精准碰一碰回调。
2026-10-21 10:14:27
216
原创 HarmonyOS ArkUI Image × ArkTS Promise：超分预览回包乱序与跨图串帧防护【鸿蒙心迹】
Demo：UltraPreview｜任务编号：SR-206｜方向：图像超分业务预览层内容性质：基于官方组件资料编写的工程示例；文中日志、数据和图片是，未在真机或 DevEco Studio 中实测，也不代表系统自带超分推理接口。
2026-10-21 10:10:03
164
原创 HarmonyOS 7 + ArkUI GridRow：折叠盘点页的筛选快照与断点渲染解耦【鸿蒙心迹】
本文通过 StockFold Demo 演示了折叠屏下响应式布局变化引发的查询错位风险：界面断点切换导致布局重构，若将当前视图状态误作导出条件，易造成“用户看到的”与“导出的”不一致。核心解决方案是：冻结筛选快照（QuerySnapshot），以 id 为唯一标识，确保异步回执比对快照而非实时输入；同时分离布局与业务状态，避免 onBreakpointChange 干扰查询逻辑。强调三类验证顺序与日志追踪，保障导出一致性，提升跨设备体验可靠性。
2026-10-20 11:42:39
36
原创 HarmonyOS 7 + Node.js JSON5：上架受限权限的发布凭据与视频证据映射【鸿蒙心迹】
本文介绍ReleaseProof本地发布材料预检工具，针对华为AppGallery Connect上架中“包内声明、发布配置、证据材料”三份清单不一致的常见问题。通过模拟检查受限权限R-01的视频缺失，输出NEEDS_REVIEW与具体缺项，实现对人工准备材料的完整性校验。工具仅做映射核对，不替代审核结论，强调清单来源可信、人工复核必要，并建议生成可追踪的工单以提升协作效率。
2026-10-20 11:38:45
29
原创 HarmonyOS 7 + ohpm nativeComponents：Native HAR 的 SDK 兼容声明分层校验【鸿蒙心迹】
本文介绍 NativeCompatGate 兼容性预检机制，针对 HAR 引入 Native 代码时的 SDK 版本不一致问题。通过分析 oh-package.json5 中的 compatibleSdkVersion 与 nativeComponents 字段，仅校验元数据（不反编译 ELF），识别如 NATIVE_SDK_TOO_NEW 等风险。基于整数版本比对，区分宿主、HAR 及 Native 组件的 SDK 标识，避免误判。报告页面清晰展示各层版本与问题来源，强调“本地门禁”非编译失败，提升复用组
2026-10-20 11:34:53
36
原创 HarmonyOS 7 + ArkUI Slider：折叠屏时间轴的朗读步长与精细编辑分离【鸿蒙心迹】
本文介绍FoldTrim项目中如何解决折叠屏下时间轴裁切的无障碍操作矛盾。通过分离“普通编辑步长”（step=1）与“朗读手势步长”（scrollStep=5），实现精准控制与高效操作的平衡。采用配置校验函数确保参数合法性，避免隐式错误；页面状态独立于布局变化，保障数据一致性；并通过纯函数测试验证逻辑正确性，区分推演与真实设备行为，提升开发可维护性与可测性。
2026-10-20 11:30:50
31
原创 HarmonyOS ArkTS×3DGS：相机位姿矩阵正交性检查与坏帧隔离【鸿蒙心迹】
本文提出名为 PoseFence (PF-1010) 的端侧3DGS重建前置校验工具，针对相机位姿数据中常见的旋转矩阵非法问题。通过检查矩阵正交性、单位长度及行列式符号，区分“缩放错误”（SKEW）与“镜像反射”（MIRRORED），避免误判重建算法缺陷。基于ArkTS实现轻量级校验逻辑，支持行优先格式输入，输出详细诊断报告。六组示例验证得4帧通过、1帧SKEW、1帧MIRRORED，强调校验不修改原始数据，仅作门禁拦截，保障后续重建流程可靠性。
2026-10-20 11:20:36
22
原创 HarmonyOS ArkUI×accessibilityText：发布前图标按钮无障碍标签覆盖巡检【鸿蒙心迹】
本文提出一种轻量级无障碍自查方案，通过维护静态控件清单与本地脚本审计图标按钮的可访问性标签。针对“无文字图标”易被忽略的问题，强调accessibilityText与accessibilityDescription的正确使用，并以AX-1011为例，实现4项自动通过、1项人工复核的可解释检查流程。方案不依赖自动扫描，重在建立业务责任机制：确保每个图标入口有唯一ID、清晰标签与语义说明，辅以断言验证与人工复核，避免仅凭数量达标而忽视真实可用性。最终目标是推动发布前可读性审查落地，而非替代设备实测。
2026-10-20 11:16:35
33
原创 HarmonyOS AppGallery Connect×Node.js：上架截图规格离线检查门禁【鸿蒙心迹】
本文介绍如何为华为AppGallery Connect发布构建本地图片门禁系统，通过Node.js脚本自动校验图标与竖版截图的尺寸、数量及文件大小，实现对AG-909任务的静态检查。脚本仅读取PNG头部信息，快速识别错误（如02-task.png高度不符），输出可追溯的修复建议，并以非零退出码提示失败，助力团队在发版前精准定位问题，提升上架效率与准确性。
2026-10-20 11:12:35
39
原创 HarmonyOS ArkUI List×平行视界：筛选后滚动锚点回填与右栏定位隔离【鸿蒙心迹】
本文探讨宽屏应用中左右分栏布局的锚点恢复问题，核心是区分“索引”与“记录ID”——筛选后列表顺序变化，仅靠索引无法准确还原用户浏览位置。通过引入anchorId（锚点）、selectedId（详情）和visible（筛选结果）三者分离的设计，确保滚动恢复不干扰右侧详情。利用纯函数resolveAnchor实现基于业务规则的兜底策略，结合ArkUI的Scroller与稳定key，实现精准锚点定位。同时建议以首个可见项更新锚点，避免因滚动误判位置，提升用户体验一致性。
2026-10-20 11:08:24
25
原创 HarmonyOS ArkTS×3DGS：采集包断号与失联帧的重建前门禁【鸿蒙心迹】
摘要（≤150字）： 为解决拍摄中断后清单完整性误判问题，开发 FrameLedger 工具，在3DGS重建前校验采集清单。它独立检查序号缺失（如4、6）、空URI（如7），区分“未采集”与“引用失效”，输出三类计数：记录数、缺失序号、空引用序号。不依赖重建接口，仅基于自定义清单，确保结果可复现、不可混淆。通过明确边界与阻断逻辑，防止错误导出，保障数据可追溯性，提升采集流程可靠性。
2026-10-20 10:57:51
26
原创 HarmonyOS string.json×Node.js：上架前多语言占位符漂移巡检【鸿蒙心迹】
本文针对多语言本地化中“资源存在但文案不完整”的隐蔽问题，提出用Node.js编写静态巡检脚本LocaleProof，通过对比基准语言与目标语言的占位符数量与类型，精准识别如日语pickup_eta缺参数、privacy_hint缺失等2类问题。脚本拒绝静默覆盖，强制校验重复键与格式错误，输出具体文件与键名问题，支持CI流程集成。强调自动化检查无法替代人工审校，尤其在语序翻转、文化合规、布局适配等方面仍需人工介入。
2026-10-20 10:53:38
19
原创 HarmonyOS Image Kit×PixelMap：超分前ROI裁剪越界保护与资源归属【鸿蒙心迹】
本文针对图像超分流程中的裁剪预检环节，提出并实现 RoiBench 的边界校验逻辑（任务号 ROI-708）。针对原始像素坐标与界面缩放坐标的差异，设计 clampRoi 函数，通过角点计算确保选区合法，自动截取有效交集。结合 cropAndReleaseOwnedPixelMap 实现资源安全释放，避免共享 PixelMap 引发的副作用。进一步通过 estimateTarget 预估二倍超分所需内存（约 1.10 MiB），为后续处理提供预算参考。整体流程强调输入合法性、所有权清晰与可复查日志，不涉及实
2026-10-20 10:49:25
17
原创 HarmonyOS 闪控窗×ArkTS：取件倒计时前后台补偿与终态幂等【鸿蒙心迹】
本文以 QueuePulse 取件任务 QP-707 为例，揭示前后台切换下倒计时状态错乱的根源：将 remainingSec 当作唯一真相会导致业务事实失真。提出三层次设计：以 dueAtMs 为不可变截止时间，status 表示终态，remainingSec 仅作为实时计算值；通过 DeadlineClock 分离刷新调度与状态更新，确保恢复前台后正确重算剩余时间；引入 TerminalGate 防止“完成取件”与“到期关闭”重复提交。强调倒计时仅为展示，终态必须由幂等闸门控制，日志应区分刷新与业务事件
2026-10-20 10:45:18
26
原创 HarmonyOS ArkTS×精准碰一碰：交接回执幂等防重与状态回退【鸿蒙心迹】
本文以“现场交接”为场景，通过TapReceipt样例拆解物理触发、业务受理与回执落账三者差异。基于唯一requestId实现幂等判重，区分确认、重复与冲突状态；页面独立统计接收次数与有效确认数，确保可观测性；强调本地台账仅作临时缓冲，最终幂等需由服务端保障。同时提醒：状态不可逆、时间戳可信、日志过滤严谨，并指出跨进程持久化与版本控制等工程边界，为真实接入“碰一碰”能力提供前置设计参考。
2026-10-20 10:41:00
19
原创 HarmonyOS HAR×ArkGuard：混淆发布后公共接口契约保护【鸿蒙心迹】
本文聚焦HarmonyOS HAR库发布时的混淆兼容性问题，强调“debug通过≠release可靠”。核心指出：公共API稳定性不等于内部标识符不变，反射字符串、序列化字段等动态依赖易被忽略。需通过consumerFiles传递明确保留规则，并建立静态检查、构建产物验证与消费端运行回归三重隔离。建议以最小化保留策略保护真实契约，杜绝凭经验添加规则。巡检应区分“静态通过”与“发布通过”，关键路径必须人工复核，避免误判。最终强调：版本变更须同步更新契约与回归用例，确保发布可信。
2026-10-20 10:36:49
33
原创 HarmonyOS ArkWeb×JSBridge：营销H5消息白名单与过期会话隔离【鸿蒙心迹】
本文介绍鸿蒙应用中通过ArkWeb实现H5与原生交互的安全机制——PromoGate。针对外部页面可能发送非法或过期消息的风险，设计了基于sessionId、action、couponId的三重校验策略，仅允许特定动作（如openCoupon）且拒绝类型不符或旧会话请求。通过限制JSBridge暴露方法为单一submit，结合白名单控制与会话生命周期管理，确保消息可信、权限可控。示例验证三条测试用例：放行1条、拒绝类型1条、过期会话1条，强调安全边界应由原生侧严格把控，而非依赖前端校验。
2026-10-20 10:21:11
26
原创 HarmonyOS ArkUI GridRow：跨窗报修看板断点重排与统计守恒【鸿蒙心迹】
本文提出在响应式布局中分离数据与排版逻辑，确保窗口宽度变化仅影响卡片列数而不触发数据重载。通过固定ticketId作为唯一标识、使用纯函数countByStatus统一统计口径，并结合GridRow的breakpoints与WindowSize实现视觉自适应，避免因断点切换导致工单消失或统计闪烁。强调“统计守恒”原则，验证数据一致性，提升报修看板在多窗口场景下的稳定性与可读性。
2026-10-20 10:10:55
37
原创 HarmonyOS ArkTS×3DGS：采集角度覆盖与重复帧预检【鸿蒙心迹】
本文提出一种端侧3DGS重建前的元数据预检方案——OrbitCheck，针对商品采集中视角重复、覆盖不全等核心问题。通过角度归一化与环形距离计算，实现对8帧样本的智能筛选：识别近角度候选（≤5°）、统计方向扇区覆盖（4/4），输出可复核的预检报告。强调预检仅评估输入质量，不删减文件，确保后续重建可追溯。代码逻辑独立于页面状态，保障结果一致性，为重建管线提供可信前置校验。
2026-10-20 10:06:50
24
原创 HarmonyOS ArkUI Grid×文搜图：多来源命中去重与证据追溯【鸿蒙心迹】
本文提出在文搜图系统中，为解决多源检索导致的重复展示问题，设计并实现了一个轻量级归并契约——TagAtlas。通过统一候选协议（含photoId、score、source），在展示前进行资产级去重与合并，确保同一图片仅显示一次，并保留最佳来源与命中次数信息。该方案不依赖真实模型或隐私数据，仅基于元数据模拟，具备可预测性与扩展性，适用于后续接入不同检索模块，保障结果一致性与用户体验。
2026-10-20 10:02:47
28
原创 HarmonyOS WindowStage：诊断子窗口重复创建与销毁竞态【鸿蒙心迹】
build() { Column({ space: 18 }) { Text(‘TraceDock · 诊断面板’).fontSize(24) Text(}) }.width(‘100%’).padding(24) }}````AppStorage.get(‘windowStage’)在做应用内诊断面板时，一种很不显眼的交互会把代码里的生命周期问题放大：用户快速连续点两下“显示诊断窗”，面板可能只看见一块，但后台其实保留了两个窗口句柄。阶段与旧句柄，阻止再次创建；
2026-10-20 09:54:09
30
原创 HarmonyOS ArkUI Navigation：分栏订单选中态与空白占位修复【鸿蒙心迹】
如果团队为了交互方便，想进页面就自动选中第一笔订单，那应该显式把第一笔订单压入路由栈，而不是让占位组件假装详情。点开一笔订单后，右侧有了详情，再连续点几笔订单，返回键又像在翻一摞旧单据。某些流程确实需要逐级返回，但一个“左侧选列表、右侧换内容”的工作台，通常更符合用户直觉的是替换当前详情，而不是积累浏览历史。的定位：它解决“空栈时右栏看起来像坏了”的体验问题，却不是详情缓存、不是导航数据源，也不会帮业务恢复选中项。真正的多形态适配，首先要解决的是用户动作的含义，而不只是让两个区域同时出现在屏幕上。
2026-10-20 09:50:18
23
原创 HarmonyOS Image Kit×PixelMap：超分预检尺寸预算与旧结果丢弃【鸿蒙心迹】
本文通过ClarityGate示例，强调图像增强中“预检”与“算法执行”的状态分离。重点解决三问题：像素尺寸与内存预算的精确计算（如800×600放大2倍需约7.32MiB）、异常输入防御（使用Number.isSafeInteger防溢出）、以及异步结果隔离（通过请求序号防止旧结果覆盖新界面）。代码实现纯函数式预算检查，结合Image Kit读取真实元数据，确保状态机清晰、可测试，为后续接入超分算法奠定可靠基础。
2026-10-20 00:41:44
69
原创 AppGallery Connect×module.json5：权限声明与提审材料差异门禁【鸿蒙心迹】
ReviewLedger 是一个本地静态巡检工具，用于应用提交前的权限与隐私信息核对。它通过比对 module.json5 与 string.json 中的权限声明、理由引用及重复项，实现自动检查（如相机/麦克风理由存在性、权限去重），并强制人工复核隐私文本一致性。脚本不替代审核，仅输出可追溯的检查结果（如“静态通过3项、人工复核1项”），支持CI拦截格式错误，但保留合规判断由人完成。强调配置与资源对账、拒绝硬编码规则，适用于多模块、多语言场景，最终以可读巡检页呈现结果，确保提交前信息一致、可追溯。
2026-10-20 00:38:05
44
原创 HarmonyOS ArkUI×display：折叠态切换盘点草稿一致性【鸿蒙心迹】
本文以 FoldLedger 的 DraftPage 为例，探讨折叠屏设备下草稿数据一致性难题。核心思路是：分离设备形态与界面宽度判断，统一管理草稿状态，确保重排不丢失输入。通过将草稿数据独立于布局逻辑、使用 onAreaChange 动态判断双栏、避免重复初始化组件，并严格区分“可重算的展示状态”与“不可丢失的业务数据”，实现跨形态、跨窗口的草稿连续性。强调：数据一致性依赖单一数据源与状态更新机制，而非布局切换；真正的可靠性还需结合本地存储与版本控制。
2026-10-20 00:34:20
66
原创 ohpm×oh-package.json5：三方依赖漂移构建门禁与回滚清单【鸿蒙心迹】
项目构建因依赖版本范围（如^1.4.0）导致不一致，虽代码未变，但依赖树可能漂移。通过引入DependenceGate门禁工具，在构建前静态检查生产依赖声明范围，识别需人工复核项（如范围版本），并强制提交oh-package-lock.json5以确保可复现。工具仅做轻量级静态分析，不替代包管理器或安全扫描，输出报告编号DG-102，示例显示“2通过、1需复核”。移动端仅展示报告，不执行安装。强调锁文件由工具维护，回滚应基于已验证的锁文件，而非猜测版本。适用于多模块协作与持续集成场景，提升依赖变更可见性与发
2026-10-20 00:30:43
247
原创 HarmonyOS 7+Node.js：三方HAR本地化资源关键键覆盖门禁【鸿蒙心迹】
本文提出针对ArkUI组件多语言资源的静态检查方案，通过对比resources/base/element/string.json与en_US目录的键值差异，区分“可回退的普通键”与“必须翻译的关键键”。以LocaleGate项目为例，发现discard_warning（关键缺失，阻断）与tool_tip_extra（允许回退）两类问题。脚本基于源码进行差分，输出结构化报告，支持CI集成，退出码1表示关键缺失，2表示检查失败。强调需结合实际界面验证，避免仅依赖覆盖率数字，确保高风险提示文案不被忽略。
2026-10-20 00:24:24
138
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人