登录社区云，与社区用户共同成长
邀请您加入社区
诗境」的刷卡页把一整个年级的诗铺成一叠牌：当前那张居中、左右各露一角，手指划过 100vp 就翻到下一张。这个「牌堆」不是真正的列表容器，而是 111 个（或某个年级的十几二十个）卡片组件按算出的三组几何参数同时叠在同一个Stack里。五个常量决定了它看起来像不像一叠纸。前三个是几何，第四个是动画时长，第五个是手势阈值。它们全部是模块级常量，不在组件里 —— 这五个数字是这套交互的「设计参数」，改
采集阶段是硬约束，用户拍摄时长不可控，只能软提示不能强制限制优化阶段占 60% 且算法不可改，只能调迭代次数，降迭代质量跟着掉降帧率性价比最高，从 30fps 降到 15fps 质量几乎不变，特征提取耗时减 45%降帧率边际收益递减，15fps 以下再降省不了多少反而影响视角覆盖导出 PLY 比 GLB 快 40%，仅展示用 PLY，需要后续编辑用 GLB按场景复杂度动态调参，简单场景用默认参数，
我们做文物保护的客户提了个需求：野外文物采集，地点在山区没信号，3DGS 重建能不能纯离线跑。我们一开始拍胸脯说能——Spatial Recon Kit 是端侧重建，端侧就是离线。真到山里测才发现，端侧重建的某些环节偷偷要联网：特征提取用的模型默认从云端拉，离线时直接失败。这篇文章记录我们把重建流程的联网依赖摸清楚，做离线兜底，以及离线模式下质量和功能掉多少。
闪控窗（应用内悬浮窗）的核心在于搞清楚SubWindow的创建、拖拽和生命周期。普通应用只能做应用内悬浮窗，别去申请 SYSTEM_FLOAT_WINDOW。交互区域要区分清楚，用控制点击穿透。主窗口销毁时，一定要 destroy 子窗口，并在应用切回前台时主动showWindow。
把探索页的平面地图换成 ArkGraphics 3D 立体浮雕：一张原画配九张高程图，钉位用引擎射线标定，选中地块沿自身边界浮起；记录事件冒泡误选、伪 3D 薄板被否与方向光 1.7 次幂三处实测。
session 是单例，destroy 是异步，resolve 之后仍有资源清理窗口销毁后创建需要保护延迟，时长按设备实测，120ms 在 9030 上够用快速切换场景必须用状态机，纯 Promise 链无法处理取消createReconSession 失败时状态必须回 IDLE，否则 manager 死锁应用切后台回前台要处理 INVALID_SESSION，强制重建 session长期不用的
isSupport只挡崩溃线，体验线要应用自己加capability level 是颗粒度更细的查询，但仍然不保证具体帧率9020 旗舰也存在热启降频，连续重建要给冷却间隔中端机即便放行也要降目标分辨率和帧数，否则重建耗时不可接受低端机直接挡，别让用户白等一场最后 OOM设备矩阵随固件更新会变，做成可配置而不是硬编码测性能数据要记录冷启/热启和机身温度，否则不可复现。
空间坐标系（3D）：原点在相机位置，x 向右、y 向上、z 向前（深度）。单位是米或 vp。3D 模型、空间面板用这套。屏幕坐标系（2D）：原点在屏幕左上角，x 向右、y 向下。单位是 vp。2D 组件、文字、列表用这套。两套坐标系在混合渲染里不是互斥的，是叠加的——2D 区域在屏幕上的位置（屏幕坐标）决定了 3D 区域的视锥边界，3D 区域的投影结果（屏幕坐标）决定了 3D 模型在屏幕上画在哪。
可见性 visible：组件是否在视锥内且未被裁剪。空间里可见性不是那种二值，而是"在视锥内 + 未被遮挡 + alpha > 0"三个条件合算。视锥裁剪由相机位置和朝向决定，组件自己改不了，只能监听。焦点 focused：组件是否是当前交互选中目标。空间焦点是 3D 的，带 z 坐标。同一时刻只能有一个组件 focused（单焦点模型，API 26 不支持多焦点）。深度 z：组件在 Z 轴的位置
Z 轴位移动画用 ease-out，别用 spring（振荡最晕）位移速度 ≤ 2 m/s，耗时 1~1.5s 为宜峰值加速度 ≤ 5 m/s²，覆盖前庭敏感人群连续 Z 轴动画缩位移幅度，间隔 <500ms 切 linear 缓动X/Y 轴动画可以用 spring，不引发晕动症单次 SSQ < 10 可接受，连续操作注意累积效应目前阈值是按 12 个同事的测试定的，样本量小。下一步打算做更大规模
默认NONE不穿透，半透明面板后的组件点不到让部分可见的后面组件可交互，组件数 50 以内可接受alpha 阈值按业务分档，API 的 0.95 太高，建议 0.5 分界AABB 遮挡判定有精度问题，圆形/异形组件要用精确碰撞体只用于调试，生产环境别开前层组件想让射线穿透，alpha 要够低（<0.5）且设目前 alpha 分档阈值是写死的 0.5，换场景可能要调。下一步打算把阈值做成主题变量，让
ReviewBoard 在折叠屏上因鼠标、触控、键盘交互不一致导致操作入口消失或冲突。问题根源在于将输入状态（如 hover）直接绑定业务逻辑。解决方案是分离输入事件与状态，建立 hovered、focused、pressed、menuOpened 四个瞬时事实，通过规则推导 actionsVisible，确保三端操作语义统一。同时，动作收敛至同一执行路径，保证行为一致性与可维护性。最终实现跨设备
把视线当"注意力"而非"控制信号"。它天生有噪声且无意识，任何"看一眼就触发"的设计几乎必然会遭遇迈达斯之触。正确的姿势是让视线做选择和预览，把副作用留给手势。给每个通道划定职责。视线负责"选谁"，头部负责"面向哪"，手势负责"对它做什么"。职责交叉越多，冲突消解越难做，也越难向用户解释系统为什么这么响应。阈值按场景可配置。注视时长、头部转角容忍度、手势置信度都不该是一组固定值。熟练用户和初次使用
手势数量宁少勿多。识别能支持几十种手势不代表用户记得住。常用手势控制在 7 个以内，超出部分要么合并语义，要么让用户自定义。每个手势都要有视觉预览。用户做手势的过程中，界面要实时反映"系统现在认为你在做什么"，比如抓取时对象上浮、滑移时内容跟手。没有预览，用户不知道自己有没有做对。容错的重心在"不做"而不是"纠正"。系统认不准的时候，最好的选择是保持现状，等用户重新做一次。自动"纠正"用户的意图，
先决定"看"和"选"分不分家。如果场景允许手势，优先做注视+手势，把副作用交给显式动作；只有在免手场景下才考虑 Dwell，并且接受它必然存在的误触残余。Dwell 阈值按目标重要性分层。不要全局一个值。高频、低风险的操作可以短，低频、高风险的操作要长。反馈是 Dwell 的一部分，不是装饰。没有进度的等待对用户就是卡顿，环形进度、径向放大这类反馈直接决定了 Dwell 能不能用。滤波延迟和抖动要
语义先定，数值后调。先把三档语义带定下来，再让设计稿去贴合，比反向凑数值省事。焦点层同一时刻只留一个。两个东西同时"最近"，用户不知道该看谁。虚化要配合后退。只虚化不后退，看着像图层蒙了层雾；只后退不虚化，背景又会抢戏。给动画留时间。深度切换 300~400ms 比较舒服，太快会晕，太慢会拖沓。中景是"家"，别让焦点层把中景遮死。留出可见的边缘，用户才有返回的参照。
<think>我们根据要求，生成≤150字的文章摘要。首先理解内容：文章介绍使用HarmonyOS 7的Spatial Recon Kit实现商品3D展示，提升电商转化率。摘要需简洁概括核心。字数限制150字，包括标点。需突出3D展示优势、流程、关键代码。注意语言精炼。</think>本文介绍了如何利用HarmonyOS 7的Spatial Recon Kit，通过拍照、端侧重建、加载展示三步实现
图 1：图表库适配封面图，用来概括本文主题、适配对象和工程边界。实际项目里，图表库适配经常不是“引入依赖就能用”的问题。真正麻烦的是输入来源、平台能力、生命周期、异常处理和发布说明没有被写清楚。前期省掉这些边界，后面一升级库版本或换设备，就会变成全链路排查。本文围绕和展开，目标是把三方库从“能跑一次”整理成“能被业务稳定接入”。读者可以按文中的源码地图、配置入口、封装层、示例页和验收清单，把自己的
在高校信息化建设浪潮中，校园媒体资讯平台是连接师生与校园生态的核心枢纽。从头条要闻的横滑浏览到频道栏目的嵌套翻页，从校园站点的网页直达到下载文件的双链溯源，从晨报速递的 AI 字幕听报到个人订阅的身份管理，每一项功能都需要精确的数据驱动、流畅的滚动交互和丰富的多媒体能力。传统校园应用往往面临三大困境：资讯分类缺乏视觉锚点导致浏览效率低下、下载来源无法追溯导致文件去向不明、听力障碍或静音场景下音频内
