登录社区云，与社区用户共同成长
邀请您加入社区
ArkTS 提供了一套容器类库，包括 ArrayList、HashMap、LinkedList 这些。有人会问：JS 原生的 Array、Map、Set 不能用吗？能用，但 ArkTS 容器在性能上做了专门优化，运行时通过一条字节码指令就能完成增删改查，比原生 Array 的方法调用快。这篇把线性容器和非线性容器捋一遍，重点讲怎么按场景选容器。
知道了对象追踪和三种回收算法，再看 HPP GC 就是在看一个工程化方案：怎么把这些算法组合起来，既压低 STW 时间，又控制碎片，还保证吞吐。HPP GC（High Performance Partial Garbage Collection）是 ArkTS 运行时的 GC 实现，名字里的 High Performance 来自三个设计——分代模型、混合算法、流程并发化。这篇把这三块和 Heap
短生命周期对象尽量在函数内创建，函数返回后从 Root 不可达，下次 Young GC 就回收了。Young GC 频率高、开销小，这种对象几乎无感。长生命周期对象（缓存、单例）会被晋升到老年代，Old GC 频率低、开销大。老年代对象多不是问题，问题是老年代对象频繁增删会导致碎片和频繁 Old GC。大对象（几 MB 以上的 ArrayBuffer）会直接进 HugeObjectSpace，每个
Sendable class 属性必须显式初始化。不能用!，不能省略初值。这条规则强制你写出确定的初始状态，但也意味着不能延迟初始化。: string;// 报错，必须显式初始化@Sendable// OKSendable class 不能用私有属性。用private关键字代替。Sendable 不支持增加/删除属性。对象结构在创建时固定，只能改值不能改结构。动态加属性会报错。Sendable 方
别教条。决策树是参考，不是教条。有些场景两者都能用，选你写得快、维护成本低的。一个 2 分钟的独立计算任务，用 TaskPool 写 5 行代码搞定，没必要为了"理论最优"硬上 Worker 写 50 行。TaskPool 的 3 分钟限制只算同步执行。异步 I/O 等待不计入。数据库异步插入、网络请求的等待时间都不算，只算 CPU 实际处理时间。别看到 3 分钟就慌，先看任务是同步还是异步。Wo
TaskPool 用起来简单，但碰到要长时间占据线程、需要保存句柄状态、或者任务超过 3 分钟的场景，就得请出 Worker 了。Worker 给你一个独立的运行环境，自己管生命周期，自己跟主线程消息通信，自由度更高，代价就是写起来更繁琐。这篇文章把 Worker 的运作机制、创建方式、文件路径规则、生命周期管理和多级 Worker 用法都过一遍。
本文聚焦「一句找图」搜索效果的评估与优化，通过固定图库版本与查询语句，建立可复现的评测体系。引入expectedIds明确预期结果，以严格相关、部分符合等标准量化相关性，结合相似度排序提升结果可解释性。页面状态分离草稿与提交查询，确保结果对应准确；通过请求编号、会话与图库修订号实现回写追踪，保障异步操作一致性。最终实现可验证、可追溯的搜索体验闭环。
<think>我们根据要求，生成≤150字的文章摘要。首先理解内容：文章介绍使用HarmonyOS 7的Spatial Recon Kit实现商品3D展示，提升电商转化率。摘要需简洁概括核心。字数限制150字，包括标点。需突出3D展示优势、流程、关键代码。注意语言精炼。</think>本文介绍了如何利用HarmonyOS 7的Spatial Recon Kit，通过拍照、端侧重建、加载展示三步实现
口算应用看似只要随机两个数、拼一个运算符就能工作，真正落地时却会迅速遇到边界问题：一年级题目不能频繁出现负数，除法不能产生无法口算的小数，四则混合要遵守运算顺序，错误选项不能重复，随机练习不能改坏原题库，所谓“难度”还必须能被代码和测试明确解释。 本文基于口算王项目 D:\huawei\one16-11 的真实 ArkTS 源码，重点复核 MockBanks.ets 、 PracticePage.
API 26 Release 的导出调整让锁屏扩展和卡片扩展的角色更清晰，也把实况窗的工程难点暴露出来：真正需要管理的是跨进程、跨入口、跨网络的长期状态。以服务端为事实源，以版本化快照支撑扩展恢复，再用幂等创建、更新和结束守住生命周期，实况窗才能在应用被回收之后仍保持准确。
元服务（原原子化服务）的桌面卡片是用户获取信息的第一入口，很多开发者反馈「FormExtensionAbility 配置了定时刷新，但卡片内容半天不更新」。这个现象背后并不是某一个 API 失效，而是 HarmonyOS 的卡片刷新机制由刷新方式、卡片可见性、应用冻结状态、最小刷新周期四重约束共同决定。本文结合实际踩坑，给出一套可落地的排查清单与可运行代码。
文本搜图的价值，是让用户按记忆而不是文件组织方式找图片。把授权范围、索引版本、结果排序、竞态处理和隐私清理一起做好，语义检索才能从模型演示变成可靠的相册入口。
bg: string这是整个应用的色彩体系接口定义。SeaPalette 接口定义了 18 种颜色属性，涵盖了背景、主色、次色、卡片、文字、标签、警告、成功、提示等各种视觉场景。这种设计模式的核心优势在于颜色的集中管理。当需要调整主题色时，只需要修改调色板常量对象，整个应用的颜色就会同步更新。这比在每个组件中硬编码颜色字符串要优雅得多，也更容易维护。值得注意的是，每种颜色都有对应的"软"版本，比如
本文介绍了在轻量级HarmonyOS应用"心晴手记"中选择使用Preferences而非数据库的工程决策与实践经验。作者基于产品特性（无账号系统、本地存储、数据量小等）选择了将应用状态序列化为JSON字符串存储的方案，并详细阐述了这种设计的六个关键实践： 定义完整版本化状态对象作为持久化边界 健壮的数据读取与容错处理 新版本字段默认值补全机制 写入前创建确定状态快照 通过Promise链保证写入顺
FAST Kit 向开发者提供算法加速能力，将难编写及易引发性能问题的底层算法进行了系统级封装，开发者无需自研底层逻辑，只需一步调用，即可大幅提升应用运行效率并降低功耗。针对音频处理、信号处理及数组计算等场景，新增底层接口，基于ARM NEON指令集进行向量计算深度优化，帮助开发者节省大量手写循环的时间。传统字符编码排序往往低效且反直觉，导致长列表加载卡顿或用户查找体验差，FAST Kit 提供了
将显示数据和选项数据分离，既保证了 Select 的整洁，又保留了展示区的趣味性。这种设计有意避免了"实时计算"——星座配对本质上是一种"查询"而非"计算"，让用户主动点击按钮确认查询请求，比实时计算更符合使用心理。在星座配对中，每个 Select 的选项正好是 12 个，值域适中，是 Select 使用的典型场景。虽然配对分数是预设的，但其"数据驱动内容"的思想在真实的数据密集型应用中广泛使用。
如果检测逻辑非常复杂（如调用远程 API 检查密码是否在泄露数据库中），就需要"防抖"（debounce）处理。触发完整的 UI 重建，听起来很浪费，但实际上这个开销极低——密码字符串通常很短（<50 字符），5 个正则检测每个都是微秒级的操作。——如果说密码生成器是"创造密码"，那么密码强度检测就是"验证密码"。密码强度检测的基石是正则表达式。（actionable feedback），不仅告诉
HarmonyOS合并升级算法解析 本文详细讲解了HarmonyOS应用开发中"猫猫大作战"游戏的合并升级算法实现，包含三个核心技术点： 合并检测：通过四邻非对角校验（坐标差和为1）确保相邻合并，避免对角错误合并，并设置已合并标记防止重复触发 基础升级：实现两只同等级猫咪合并为高一级猫咪的逻辑，包括位置选择策略（默认取拖动目标方位置） 连锁合并：采用BFS（广度优先搜索）算法处理多级连锁合并场景，
五条件优先级：退出→超时→分数→无空格→无可合并，耗时升序排列无可合并剪枝：按等级分桶配对，提速 18 倍阈值触发：空格率低于 10% 才查可合并，避免每帧卡顿稀疏空格记录：维护空格数变量而非遍历，查询 O(1)判定顺序不可乱：耗时久者放后，前序短路。
本文深入探讨了排序算法在HarmonyOS游戏开发中的关键作用，以"猫猫大大战"游戏的下落算法为例。主要内容包括： 底部优先排序的必要性：通过数学分析解释了底部优先处理(按y坐标降序)能有效避免猫咪穿透现象，保证游戏物理逻辑正确性。 ArkTS严格模式下的排序实现：详细介绍了符合ArkTS严格模式的比较函数写法，包括类型标注、复合排序键和稳定排序保证。 性能优化方案：针对大数组场景提出分桶排序优化
用上场次数、搭档重复和对手重复三组历史约束生成双打轮换，先保证均衡再降低重复组合。
在数字化时代，密码安全是每个互联网用户必须面对的重要课题。一个强密码应当具备足够的长度、包含多种字符类型（大写字母、小写字母、数字、特殊符号），且不包含常见的单词或个人信息。然而，人类并不擅长创造和记忆真正随机的密码——这正是随机密码生成器存在的价值。本篇博文将深入解析一个基于HarmonyOS ArkUI/ArkTS开发的随机密码生成器应用。
猜数字（Number Guessing Game）是一款经典的数字推理小游戏，几乎伴随了每一代编程学习者的成长。其规则简单明了：系统随机生成一个1到100之间的整数，玩家通过输入猜测的数字，系统给出"大了"或"小了"的提示，引导玩家逐步逼近正确答案，直至猜中为止。同时，游戏会记录玩家的猜測次数，在游戏结束后展示给玩家。本篇博文将深入解析一个基于HarmonyOS ArkUI/ArkTS开发的猜数字
