10600华为黄大年茶思屋“难题揭榜”第106期——HarmonyOS难题第五期 全条目完整整理

总览基础信息

发布时间：2024-10-08 浏览量：636 次 更新时间：2026-05-19 08:39 出题规则：自主揭榜、踊跃投稿；解决难题 / 提供重大思路给予激励并张榜公示；问题对接接口专家，建议联系总架构师李毅 nicholas.li@huawei.com

难题 1：面向终端的 2D 视效算法性能优化技术

一、基础信息

出题组织：终端 BG 软件部；2012 理论研究部 接口专家：秒倩文 chaoqianwen@huawei.com；吴艺翀 wuyichong@huawei.com

二、技术背景

1. 终端 UI 动画、精致渲染效果直接影响用户体验，复杂滤镜叠加会大量占用 CPU/GPU，引发卡顿、掉帧，破坏流畅交互。

2. 主流移动 SOC 实现 120Hz 高帧率渲染约束：单帧仅能执行 1 次全屏高斯模糊，严重限制高端视觉效果落地。

3. 模糊、抗锯齿等 2D 原子视效算法成熟，但纯算法层面优化空间极小；

4. 场景性能痛点：

   1. 控制中心背板全区域二次模糊，单次全屏模糊 GPU 耗时 5ms；

   2. 通知中心渐变模糊：单帧最多 3 次区域模糊、1 次渐变模糊；

   3. 下拉控制中心桌面背板边缘像素扩展；

   4. 阴影叠加、多图标文字叠加场景性能损耗突出。

三、技术挑战

针对四类核心 2D 视效（Kawase 模糊、渐变模糊、阴影、像素扩展）设计性能优化方案，约束条件：不降低 UX 视觉可感知效果；目标二选一：

1. 负载大幅下降，满足商用落地标准；

2. 现有算力约束下显著提升视觉 UX 表现，通过 UX 专家验收。

四、当前技术成果

1. 像素扩展 + 阴影：上下采样缩放分层；底层基于高斯模糊，Skia 引擎实现 x/y 双 Pass 下采样流程优化；

2. Kawase 模糊、渐变模糊：依托 Shader 实现，渐变模糊采用两次 Box Blur，两类模糊均完成下采样基础优化。

五、技术诉求

1. 单项性能优化：研发终端 2D 视效硬件协同优化方案（新型 Kernel 替换、渲染流程重构等），达成二选一指标：

   1. CPU 指令 / GPU 时钟负载降低 20%；

   2. 无损画质前提下大幅升级 UX 视觉效果，通过 UX 专家评审；

2. 组合视效子级联优化：模糊、灰色、灰阶等多原子视效流程整合，整体整机能耗下降 20%。

六、参考代码开源地址

1. Kawase 模糊：openharmony/graphic_graphic_2d/rosen/render_service_base/renders/renders_blur.cpp

2. 渐变模糊：openharmony/graphic_graphic_2d/rosen/render_service_base/renders/renders_linear_gradient_blur_shader.cpp

3. 阴影：openharmony/graphic_graphic_2d/rosen/render_service_base/renders/renders_painter.cpp

4. 像素扩展：openharmony/graphic_graphic_2d/rosen/render_service_base/renders/renders_painter.cpp

难题 2：多设备并存场景的空间关系感知技术

一、基础信息

出题组织：终端 BG 软件部；2012 黎曼实验室 接口专家：孙飞扬 sunfeiyang2@huawei.com；关然 guanran@huawei.com

二、技术背景

1. 精准感知设备空间距离、方位，支撑全场景人机交互、用户意图分析、智能联动；

2. 统一通用感知模态：采用 1+8 全设备兼容超声波信号测距，保障多终端交互体验一致性；

3. 核心痛点：多设备同空间并发时，超声波信号互相干扰，测距时延、感知精度大幅恶化；精准测距依赖双端线性计算，基础时延偏高。

三、技术现状与挑战

1. 现有方案基线：两台设备测距时延约 0.3s（不含设备通信耗时）；多设备同场时超声波串扰，测距时延激增；

2. 信号收发并行架构可行，但多设备信号串扰会直接降低测距识别成功率；

3. 核心技术瓶颈：多设备并发下信号时序冲突、时钟不同步带来测距偏差、感知效率暴跌。

四、技术诉求

1. 算法实现：自研分布式空间感知算法，完成设备自主触发、多设备空间关系同步感知；

2. 硬件约束：适配华为 1+8 全设备，超声波采样率固定 48KHz；

3. 量化性能指标：

   1. 精度：5 米内测距误差＜1%，测量成功率≥95%；

   2. 扩展性：n 台设备场景，设备两两测距、感知总时延＜0.3*(n-1) 秒。

五、参考文献

[1] BeepBeep: A high-accuracy acoustic-based system for ranging and localization using COTS devices, ACM Transactions on Embedded Computing Systems [2] SCALAR: Self-Calibrated Acoustic Ranging for Distributed Mobile Devices, IEEE Transactions on Mobile Computing

配套用户评论问题

#难题 2: 多设备并存场景的空间关系感知技术# 提问：设备之间能否借电磁波信号完成时间同步与信息收发？

难题 3：提升 WebView 里 JavaScript 的执行效率

一、基础信息

出题组织：终端 BG 软件部；2012 编译器与编程语言实验室 接口专家：钟璇 zhongxuan1@huawei.com；李庄 email.lizhuang@huawei.com

二、技术背景

1. 业务场景：美团外卖、微信小程序等大量应用基于 WebView 开发，降低跨端重复开发成本；

2. 技术趋势：ARM 架构 CPU 针对 JS 语言推出硬件协同优化指令集（Tagged pointer，加速垃圾回收、内存访问）；

3. 系统基础：OpenHarmony arkTS 语言与 JS 语言底层逻辑高度相似，JS 优化方案可迁移复用至 arkTS；

4. 性能根源缺陷：

   1. JS 代码依赖解释器逐行执行，原生代码可预编译机器码直跑 CPU；

   2. JS 动态类型带来额外类型校验、高频 GC 回收，计算资源开销远大于 C/C++；

   3. JS 运行效率与原生程序存在显著差距，纯软件优化存在天花板。

三、技术挑战

现有 JS 引擎仅完成软件层面优化（内联缓存、JIT 即时编译），无法抹平软硬件架构差异；需结合 JS 语言底层特性，做软硬件协同优化，挖掘 WebView 性能上限。

四、当前技术成果

基于软件层 JIT、缓存优化实现 JS 提速，但缺少 CPU 硬件指令深度协同，性能提升存在瓶颈。

五、技术诉求

1. 设计目标：创新软硬件协同接口（不限于新增 CPU 指令），优化 JS 引擎执行效率，达成 benchmark 指标：speedometer、JetStream2 运行性能提升 15% 以上；

2. 验证方案： 1）基于开源 ARMv64 GEM5 平台搭建全新软硬件协同接口； 2）修改开源 JS 引擎 v8 适配新增硬件接口，整机负载下降≥15%； 3）标准化 benchmark 评测，覆盖 speedometer、JetStream2、JS 渲染等小程序高频 JS 场景。

六、参考文献

[1] The Cost of Speculation: Revisiting Overheads in the V8 JavaScript Engine. In IISWC 2021 [2] Co-designing accelerators and SoC interfaces using gem5-Aladdin. In MICRO 2016 [3] Performance Issues and Optimizations in JavaScript: An Empirical Study. In ICSE 2016

难题 4：面向 SMT 的多线程程序分析技术（已揭榜）

一、基础信息

出题组织：终端 BG 软件部；2012 编译器实验室 接口专家：陈冬杰 chendongjie2@huawei.com；徐潇 shawn.xuxiao@huawei.com；李勇彪 liyongbiao1@huawei.com

二、技术背景

1. SMT 同步多线程硬件特性：单 CPU 核并行执行多线程指令，硬件资源利用率更高、调度延迟更低；

2. 两层线程调度架构：上层用户态轻量级线程、底层 OS 内核线程；

3. 核心优化逻辑：分析用户线程之间SMT 硬件互补性，将资源互补的线程调度至同一个 SMT 硬件核并行执行，减少硬件资源冲突；

4. 核心待解问题：如何精准分析多线程程序内线程、代码片段之间的 SMT 硬件互补性。

三、技术挑战

1. SMT 互补性量化：硬件资源冲突驱动互补性，需转化为程序代码层面可量化、可分析指标；

2. 跨线程分析难度：复杂程序中仅能粗粒度判断线程互补，静态 / 动态分析结果存在残缺、精度不足；

3. 分段分析难点：单线程不同代码段硬件资源占用不同，互补性存在差异，需要全程序完整分析。

四、当前技术成果

1. 现有多线程分析工具聚焦软件竞态（数据竞争、死锁），无法直接支撑 SMT 硬件调度；

2. 编译优化方案：识别指令序列互补线程，合并调度提升 SMT 硬件利用率；

3. OS 内核调度方案：依托底层硬件 Profile 信息调度线程至 SMT 核，但完全忽略上层用户线程代码语义。

五、技术诉求

研发高精度多线程程序分析技术，完整识别多线程程序线程间、代码段间SMT 硬件互补性；落地场景：

1. 编译器优化：基于分析结果重构代码，生成 SMT 友好型程序；

2. 系统调度：辅助 OS 完成 SMT 最优线程调度； 量化指标：SMT 互补性分析结果准确率 ≥90%。

六、参考文献

[1] RacerD: compositional static race detection. In OOPSLA 2018 [2] Peasent: fast and precise static deadlock detection via context reduction. In ESEC/FSE 2022 [3] CSMT: Compiler based Software Simultaneous Multithreading. In PDP 2018 [4] Thread-Sensitive Scheduling for SMT Processors. In PDP 2008 [5] Auto-tuning Spark Big Data Workloads on POWER8: Prediction-Based Dynamic SMT Threading. In PACT 2016

难题 5：运行态轻量化采集关键日志及海量多维数据精确立体还原

一、基础信息

出题组织：终端 BG 软件架构设计部；2012 可靠性技术实验室 接口专家：蔡双林 caishuanglin@huawei.com；李煜 liyu1@huawei.com

二、技术背景

1. 现有日志采集两套方案

（1）开发者 Beta 采集模式

• 采集内容：应用 + 系统流水日志、Trace、内存快照、JS-Native 混合栈；

• 缺陷：采集范围越大，整机 CPU/IO 负载越高；边界场景漏检，线上版本质量无法 100% 验证。

（2）动态启停 Trace 方案

• 实现：API 向三方应用开放动态 Trace 抓取，界定性能问题边界；

• 缺陷：单应用每日仅允许 3 次 Trace 抓取，大量性能问题无法捕获，故障定位覆盖率不足 100%。

（3）采样抓栈方案

• 实现：主线程卡死自动抓取调用栈，单应用生命周期最多抓取 2 次；

• 缺陷：非卡死类性能问题无调用栈数据，无法完整复现定位。

2. 两大核心技术痛点

1. 运行态轻量化采集：鸿蒙超大规模代码网络结构，需要建立静态代码拓扑与关键日志特征映射，运行时仅采集最小范围、最小特征量日志；

2. 海量多维数据精确立体还原：设备低维稀疏日志（少量关键信息）向完整故障场景高维信息还原，约束逻辑、因果、时间轴完全一致，还原计算低时延。

三、当前探索进展

1. 轻量化采集：流水日志、Trace 轻量化处理，可基于流量 / 磁盘规格限制采集量；无法依托静态代码拓扑，动态识别最小采集范围；

2. 故障还原：Beta、测试全量日志可还原故障场景；缺少全量日志时，无法基于稀疏少量关键信息做数字孪生还原。

四、技术诉求（分场景量化指标）

统一约束：精准立体还原核心流程、异常分支的流水日志 / Trace / 调用栈，采集负载极低、日志体积极小。

全局硬性指标

1. CPU 负载：日志采集整机 CPU load 增量＜1%；

2. 日志体积：单次流水 + Trace 日志包＜100MB / 单设备；

3. 采集耗时：单次日志采集耗时＜1ms / 次。