- 博客(26)
- 收藏
- 关注
RSS订阅原创 声音明信片实验室 06｜HarmonyOS 7.0 音频空间化：铃声绕着走时怎样记住起点【鸿蒙心迹】
本文探讨在HarmonyOS 7.0音频工程中实现铃声旋转模式的可重复性问题。针对“重播时铃声从相同方向、顺序重现”的需求，提出通过冻结配方与独立重建管线保障状态一致性。采用C++17 std::variant区分固定摆位与旋转配置，确保参数语义清晰。实验验证两种恢复路径：复用管线与重新初始化，重点对比第8秒接入时的输出一致性。强调输入游标归零不等于效果状态归零，需结合管线事件、输出进度与日志追溯。最终通过实时播放与离线导出双路径比对，确保旋转运动可重复、可验证，为声音明信片提供可靠的空间渲染方案。
2026-11-07 14:45:48
282
原创 声音明信片实验室 05｜HarmonyOS 7.0 音频空间化：导出明信片再听一遍【鸿蒙心迹】
本文阐述了OHAudioSuite在HarmonyOS 7.0下实现离线音频导出的完整方案，核心在于通过不可变配方模型统一实时与离线路径的参数配置，确保导出文件可追溯、可复现。采用深拷贝快照机制，在用户确认后冻结当前配置，避免后续编辑干扰导出任务。导出流程严格区分输入供数、渲染完成与文件保存三个阶段，通过显式校验有效数据写入、缓冲处理与状态管理，保障输出完整性。测试覆盖版本切换、参数修改、异常中断等场景，确保产物与最终配置一致，实现“所见即所得”的离线生成目标。
2026-11-06 07:29:25
336
原创 声音明信片实验室 04｜HarmonyOS 7.0 音频空间化：拖动声源和试听断续【鸿蒙心迹】
本文聚焦于音频编辑中实时拖动铃声位置时的性能优化问题，通过固定摆位参数与合并中间更新策略，解决因事件积压导致的音频断续、延迟与跳变。采用按版本/声源保留最新待提交位置、松手后统一提交的机制，避免频繁参数变更对渲染管线的冲击。结合20毫秒输出块预算分析，合理分配处理时间，支持双管线推进与降级切换，确保听觉连续性。测试验证了合并策略在负载下的有效性，为实时音频交互提供可落地的工程方案。
2026-11-05 14:08:00
325
原创 声音明信片实验室 03｜HarmonyOS 7.0 音频空间化：双版本试听无缝切换【鸿蒙心迹】
本文探讨在HarmonyOS 7.0 API 26下实现双实时音频配置无缝切换的方案。通过保留两套独立管线，分别管理读取游标、处理状态与输出块，确保切换时时间连续性与空间位置一致性。采用版本标记、请求序号与范围校验机制，防止过期数据干扰。测试验证了多位置同步、预滚策略及跨版本切换的可靠性，为高精度空间音频应用提供可落地的技术路径。
2026-11-04 20:23:09
244
原创 声音明信片实验室 02｜HarmonyOS 7.0 音频空间化：让雨声和铃声各就各位【鸿蒙心迹】
本文探讨音频编辑中声源空间定位的实现方案，基于HarmonyOS 7.0与OHAudioSuite API，采用“每路声音独立空间渲染”（方案B）确保可分别摆位。通过定义声源ID与坐标映射函数，将UI拖动坐标转换为左手坐标系下的空间位置（[-5,5]米），并建立独立空间节点绑定，实现雨声、翻书声、铃声的精准定位。测试验证了坐标映射与参数提交的正确性，为后续听觉辨识实验奠定结构基础。
2026-11-03 14:11:11
114
原创 声音明信片实验室 01｜HarmonyOS 7.0 音频空间化：三段录音对齐时间轴【鸿蒙心迹】
本文探讨了在音频项目中统一不同来源声音素材的时间尺度问题，提出以48 kHz、双声道、S16LE格式为标准，对雨声、翻书声与街角铃声进行统一转换。通过精确计算样本帧数与字节偏移，确保三段素材在20秒项目中保持准确时长，避免因采样率或格式差异导致播放偏差。采用导入阶段预转换策略，分步完成格式转换、完整输出保存与裁剪补齐，保障音视频同步与空间布局的可靠性。
2026-11-02 11:27:44
328
原创 灶台菜谱设计手记 05｜HarmonyOS 7.0 空间化：玻璃效果实现【鸿蒙心迹】
本文通过番茄炖牛腩菜谱的沉浸式界面优化，系统检验玻璃材质在动态背景下的性能开销与用户体验价值。基于三组对比方案（重叠、避让、关闭材质），结合帧耗时、卡顿、功耗等多维度数据，验证了装饰性材质若无明确任务支撑，将带来不必要的重算与绘制成本。最终结论：仅保留承担信息传递任务的材质区域，其余按“保留、缩小、移除”分级处理，实现视觉效果与性能的平衡。
2026-11-01 17:41:07
287
原创 灶台菜谱设计手记 04｜HarmonyOS 7.0 空间化：信息折叠展开【鸿蒙心迹】
本文探讨在灶台菜谱应用中如何兼顾“当前步骤可见性”与“阅读空间完整性”。通过将步骤摘要与返回入口统一置于MiniBar，实现跨页签的上下文保持；同时采用动态避让机制，确保正文末行不被悬浮区域遮挡。方案结合HDS组件与空间化适配，通过状态共享、几何计算与多场景检验，达成操作连续性与视觉可用性的平衡。
2026-10-31 21:31:51
332
原创 灶台菜谱设计手记 03｜HarmonyOS 7.0 空间化：沉浸光感反馈 【鸿蒙心迹】
本文探讨了在“灶台菜谱”界面中，用户操作“下一步”按钮时，如何区分触摸反馈与业务反馈。通过对比方案A（依赖瞬时光效）与方案B（持续显示步骤状态），提出应以文字和符号明确标识已完成步骤，确保用户即使离开后也能清晰判断进度。实现上，采用独立的推进逻辑函数，严格区分交互入口与业务规则，并通过状态推导动态展示当前步骤与完成标记，避免因动画结束导致信息丢失。最终强调：触摸反馈解释接触，业务反馈解释变化，二者不可混淆。
2026-10-30 12:21:15
248
原创 灶台菜谱设计手记 02｜HarmonyOS 7.0 空间化：菜图滚动实现 【鸿蒙心迹】
本文通过固定菜谱与步骤，对比三种底栏材质方案（薄材质+自动反色、厚材质+关闭反色、实色底）在不同背景下的文字可读性与视觉层次。实验采用四类背景样本，控制设备、主题与布局一致，重点检验文字辨认与界面干扰。结果表明，薄材质配合自动反色在多数场景下兼顾清晰度与沉浸感，而厚材质与实色底则在复杂纹理或低算力设备上表现更稳定，最终需根据实际使用环境权衡选择。
2026-10-29 15:10:08
132
原创 灶台菜谱设计手记 01｜HarmonyOS 7.0 空间化：材料配置矩阵【鸿蒙心迹】
做番茄炖牛腩时，查菜谱通常是一连串很短的动作：打开列表，进入详情，确认牛腩和番茄的用量，再返回当前步骤。手机放在灶台旁，界面需要让人迅速分清哪里是内容，哪里可以操作。“灶台菜谱”围绕这个过程组织页面。详情保留“备菜、烹饪、笔记”三个页签，使用本地菜谱和固定菜图，步骤由用户手动推进。我们希望材质帮助操作区域建立层次，同时让食材正文保持稳定的阅读背景。把目标版本升级到API 26后，一个值得检查的场景是：打开“切换菜谱”菜单时，菜单可能已经采用新的材质；在正文食材卡片上设置类似属性，却看不到预期变化。
2026-10-28 16:55:38
364
原创 HarmonyOS 7.0 端侧3DGS实验⑧：失败案例与复现【鸿蒙心迹】
本文提出“证据复核、协议重复、输入重放”三重复现机制，明确案例归档需分阶段记录问题、环境、操作与证据，强调失败原因与处置动作分离。实验包规划中材料分组清晰但多数尚缺实测数据，强调输入重放依赖持久化契约与验证依据。复现路径按目标选择，每步需核对前提与证据，关键缺失时停止依赖并保留已得结果。当前仅完成结构设计，真实执行与可复现报告仍待补充。
2026-10-27 13:29:22
185
原创 HarmonyOS 7.0 端侧3DGS实验⑦：三维记录浏览【鸿蒙心迹】
本文提出“桌面三维记录册”的完整浏览链路方案，涵盖从文件核验、加载执行到视角控制与页面退出的全流程验证。通过browsePlanId统一管理浏览状态，明确加载前提、渲染契约与操作证据要求，强调节点加载不等于画面显示，用户操作需可追溯。重点区分场景、节点、相机与视口四要素，规范入口状态、异常处理及资源回收机制，确保每次浏览具备可复现、可验证的闭环证据链。
2026-10-26 16:33:37
120
原创 HarmonyOS 7.0 端侧3DGS实验⑥：采集规模与消耗 【鸿蒙心迹】
本文提出在固定覆盖范围与运行条件下，通过分规模组采集桌面物品的三维数据，严格记录帧数、调用次数与热状态，以对比不同采集方案对重建耗时、内存、温度等性能指标的影响。强调独立会话、统一时间基准与测量口径，区分采集、重建与保存阶段，保留完整事件与采样证据，避免因果误判，确保实验可复现、可验证。
2026-10-25 13:11:58
158
原创 HarmonyOS 7.0 端侧3DGS实验⑤：空洞、漂浮伪影与视角稳定【鸿蒙心迹】
本文提出“桌面三维记录册”质量评价协议，聚焦产物可辨认性、关键部位可见性及观察路线连续性。通过定义固定观察路线与显示条件，区分视频与模型视角检查路径，建立逐视角定位、连续复核与输入对照机制。强调证据分层：任务完成、可观察产物与质量现象三类证据需明确区分，避免误判。采用结构化记录模板（C1-C3），保留未执行状态，仅在具备实证时填写实际条件与现象标签（如空洞样缺失、漂浮伪影等），并严格区分覆盖不足、观察受限与异常候选，确保评价客观可追溯。
2026-10-24 13:20:37
183
原创 HarmonyOS 7.0 端侧3DGS实验④：第一次端侧重建【鸿蒙心迹】
本文规划“桌面三维记录册”首次任务的执行与记录方法，强调输入接收、重建启动与结果保存三阶段的独立验证。通过分层证据体系（调用返回、进度查询、完成通知、文件检查）确保状态可追溯，避免误读进度值。基于固定环境变量与输入可用性核验，建立受控流程：先创建会话并推入有效数据，再启动重建并手动保存，确保每步有明确证据。应用状态与系统回调分离管理，防止状态覆盖，保障任务可审计、可复现。
2026-10-23 12:13:23
213
原创 HarmonyOS 7.0 端侧3DGS实验③：曝光、反光与低纹理处理【鸿蒙心迹】
本文提出桌面三维记录的质量观察框架，聚焦人工识别与标记，明确“曝光变化”“反光”“低纹理”等现象的记录规范。强调观察、标签与处置分离，建立分层记录结构：保留帧关联、环境参数与偏差信息，统一使用JSON格式记录质量观察与处置决策。不涉及图像修复或重建算法，重拍需新建批次并关联原记录，确保可追溯性与可比性。
2026-10-22 14:31:32
168
原创 HarmonyOS 7.0 端侧3DGS实验②：距离、视角与背景【鸿蒙心迹】
本文提出“桌面三维记录册”实验协议，通过experimentId、sampleId与baselineId统一管理输入批次，明确距离、覆盖范围与背景三类变量的独立对照设计。强调每次仅改变一个因素，详细记录计划与实际条件（如测量方法、路线、照明），并保留偏差与证据链。重点确保采集数据可追溯、可比较，为后续重建质量评估奠定可靠输入基础。
2026-10-21 08:21:58
211
原创 HarmonyOS 7.0 端侧3DGS实验①：什么值得做成3DGS【鸿蒙心迹】
本文探讨桌面物品的多视角三维记录方法，聚焦3D Gaussian Splatting（3DGS）技术在设备端重建中的应用。通过建立实验档案体系，系统记录设备环境、样本条件与执行状态，确保结果可复现。重点明确支持查询、输入约束与会话管理流程，为后续重建质量评估与交互浏览验证奠定基础。
2026-10-20 14:24:01
177
原创 HarmonyOS 7.0 文搜图实战⑤：从功能到交付【鸿蒙心迹】
本文为「一句找图」实战收官篇，聚焦工程化落地。通过拆分代码职责，构建清晰的模块边界：页面专注展示，SearchCoordinator 统一协调流程，VisionPort 抽象平台接口，实现可测、可复现。强化状态管理，区分持久状态与会话状态，确保恢复逻辑准确。完善关闭流程，保障服务释放有序，避免资源泄漏。最后建立细粒度故障记录机制，追踪各阶段操作，提升可维护性与问题追溯能力。
2026-09-30 12:32:01
150
原创 HarmonyOS 7.0 文搜图实战④：搜索结果优化【鸿蒙心迹】
本文聚焦「一句找图」搜索效果的评估与优化，通过固定图库版本与查询语句，建立可复现的评测体系。引入expectedIds明确预期结果，以严格相关、部分符合等标准量化相关性，结合相似度排序提升结果可解释性。页面状态分离草稿与提交查询，确保结果对应准确；通过请求编号、会话与图库修订号实现回写追踪，保障异步操作一致性。最终实现可验证、可追溯的搜索体验闭环。
2026-09-29 15:52:35
191
原创 HarmonyOS 7.0 文搜图实战③：结合图库实现检索【鸿蒙心迹】
本文探讨图库动态管理，提出三套数据分离机制：沙箱副本、应用清单与服务检索记录。通过状态机（如pending、ready、deleting）实现操作可恢复，确保导入、入库、去重、移除等流程在中断后仍能正确恢复。重点强调先删记录再删文件、校验摘要去重、清单写入串行化等设计原则，提升系统可靠性与用户体验。
2026-09-29 13:03:48
161
原创 HarmonyOS 7.0 文搜图实战②：第一次自然语言检索【鸿蒙心迹】
本文实现「一句找图」的完整检索流程：将五张测试图片从资源目录复制至沙箱，通过Core Vision Kit的insertImage插入特征；初始化文搜图服务后，完成图库准备。用户输入“海边的落日”触发查询，系统调用search接口返回匹配结果。页面分阶段展示准备状态（files→init→indexing→ready），确保每步可追踪。首次查询严格校验输入，仅当描述含中文且长度合理时才发起请求，最终实现从数据准备到检索反馈的闭环。
2026-09-28 17:33:34
289
原创 HarmonyOS 7.0 文搜图实战①：从“一句话找照片”开始【鸿蒙心迹】
本文记录了基于HarmonyOS 7.0 Core Vision Kit实现“一句话找照片”Demo的初步探索。通过构建测试图库、明确文搜图与传统搜索的区别，厘清平台能力与应用责任边界。重点完成环境搭建、基础页面开发及接口调用逻辑设计，验证了从输入描述到展示结果的完整链路可行性，为后续性能优化与真机验证奠定基础。
2026-09-28 15:58:27
538
原创 HarmonyOS Canvas能力解读：ArkUI中图形绘制与AI图像分析功能实践
新手程序员Kevin（小K）学习ArkUI中Canvas组件，梳理其核心功能：作为绘图画布，需依赖RenderingContext进行绘制，API 8起支持，最大尺寸限10000px×10000px。重点掌握onReady事件触发时机及画布清空特性，强调绘图逻辑需可重执行。API 12新增AI分析能力，支持主体、文字识别，可结合长按识别等交互。注意enableAnalyzer与overlay冲突、context不可共享等限制。适用于图表绘制、图片标记、手写板及智能识别场景，潜力丰富。
2026-09-12 20:01:48
174
原创 ArkTS collections.Array 机制解析：为什么需要区别于 JavaScript Array
新手程序员Kevin（小K）首日自学ArkTS，从collections.Array入手，发现其不仅具备普通数组功能，更专为并发场景与可传递数据设计。该类支持Sendable类型限制，确保跨实例安全传递，减少拷贝开销。通过构造函数、静态方法如create、from及丰富实例方法（增删查改、遍历转换、结构操作等），实现高效数据处理。特别功能如shrinkTo、extendTo、at()负索引等，体现系统级优化。学习中意识到：在鸿蒙分布式架构下，底层数据结构设计直接影响性能与安全，需深入理解。后续将通过实践巩固
2026-09-12 20:00:27
89
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人