课题名称：智能终端UI负载冗余自动化分析和优化技术
挑战方向：用户与负载感知的操作系统资源供给方法
揭牌年份：2025年
揭牌单位：北京航空航天大学开源鸿蒙技术俱乐部
课题负责人：周鸣一，北京航空航天大学开源鸿蒙技术俱乐部指导老师，助理教授
1
课题背景
用户对智能终端的UI流畅度有着极高敏感度。统计数据表明，约78%的应用差评与UI渲染性能直接相关。随着开源鸿蒙生态的高速扩张，大量从Android/iOS迁移而来的开发者对开源鸿蒙平台的UI渲染机制和调优工具尚不熟悉，应用质量参差不齐，性能问题尤为突出。
在众多性能痛点中，UI负载冗余是影响开源鸿蒙应用体验的核心因素之一，典型表现为过度绘制、无效刷新以及不必要的后台活动。这类问题往往隐匿于深层次的UI组件树结构中，传统性能分析工具主要呈现帧率、CPU占用率等宏观指标，难以精准定位到异常组件及其对应的源码位置。因此，构建一套面向UI负载冗余的全链路自动化分析系统，已成为开源鸿蒙生态的迫切需求。北京航空航天大学开源鸿蒙技术俱乐部相关团队承担了此项课题。
·
2
这事儿为什么难？三个“拦路虎”
团队深入调研后发现，当前开源鸿蒙应用的性能优化领域面临以下三个核心技术挑战：
第一，现有UI自动化测试工具并非为负载冗余检测而设计。Monkey、Stoat、DroidBot等主流工具以代码覆盖率提升和崩溃发现为核心优化目标，事件生成机制缺乏应用语义信息。以Monkey为例，平均每500次交互中仅有约8%的操作能真正触达有效交互路径，大量操作处于“无效探索”状态，无法覆盖用户真实使用中的高频、高负载场景。
第二，性能分析工具缺少从UI组件到源码的细粒度映射能力。Systrace、Perfetto及开源鸿蒙DevEco Profiler、SmartPerf-Harmony等工具主要提供CPU占用率、帧率曲线、内存趋势等聚合指标。开发者虽能感知到性能异常，却难以将问题归因到具体的UI组件或函数调用栈，陷入了“见其然不知其所以然”的困境。
第三，开源鸿蒙生态尚缺乏系统化的性能归因与优化建议体系。截至目前，开源鸿蒙社区尚未出现基于GUI的自动化负载冗余分析框架，从性能场景发现、数据采集、根因定位到优化建议的完整技术链路仍属空白。
·
3
北航团队为此提出全链路技术方案：四步核心流程
面对这三座大山，北航团队提出并实现了一套全链路解决方案，核心逻辑可以概括为：GUI Agent场景式探索→路径智能优化→细粒度性能归因→自动化报告生成。
（一）让AI“读懂”应用该怎么用
传统自动化测试依赖随机或覆盖率驱动的事件生成策略，操作缺乏应用语义先验，大量交互偏离有效路径。本方案利用大语言模型的应用理解能力，输入应用描述文本、界面截图或用户指定的特定任务后，LLM可分析应用的功能架构与典型使用流程，自动提取结构化的核心任务列表，例如“搜索商品→浏览详情→加入购物车”。这种场景化任务规划，使探索资源优先投入高频、高负载的真实用户场景，从根本上区别于以覆盖率和崩溃为目标、不关注性能场景的传统方法。
（二）GUI Agent自动“上手”操作
开源鸿蒙应用用的是声明式ArkUI框架，组件层次复杂、状态管理灵活。传统基于坐标或控件ID的自动化操作，换个版本就可能失效。
开源鸿蒙应用采用声明式ArkUI框架构建，组件层次复杂、状态管理灵活，传统基于坐标或控件ID的自动化操作在跨版本适配时脆弱性较高。本模块构建了基于多模态LLM的GUI Agent，核心工作流程遵循“观察→决策→记录→终止”四步循环：
观察阶段：Agent接收当前界面截图、已执行操作历史与任务目标描述，通过视觉理解能力解析界面布局，识别按钮、输入框、列表等可交互元素。
决策阶段：LLM预测下一步操作类型（点击/滑动/输入/返回），输出目标坐标或控件定位信息及必要的输入内容。
记录阶段：每步操作后计算界面状态哈希值以支持后续冗余检测，同时记录操作序列及对应的界面状态变化。
终止条件：任务目标达成或达到预设的最大探索深度。
实测数据显示，Agent在热门应用上的主要功能探索时间控制在3至5分钟，能够有效覆盖应用的核心交互路径。与依赖Accessibility Service获取控件树的传统方式相比，视觉感知方式对应用版本变化的适应性更强，且能处理非标准控件与自定义渲染场景。
（三）路径分析与智能优化：为操作路径“减负增效”
GUI Agent生成的原始操作路径存在三类典型问题：冗余步骤（重复点击、无状态变化的操作、无效返回）、低效路径（连续无目的滑动、过长时间等待）以及用户偏差（LLM探索路径与真实用户操作习惯之间的差异）。这些问题会导致测试脚本冗长、不稳定，且难以准确反映真实用户的性能体验。
团队设计了一套多维路径优化策略，核心是把界面状态哈希去重和操作序列语义压缩结合起来：
无效步骤直接删：对比操作前后的界面状态哈希，没变化的操作直接砍掉或合并。
循环链路只留一次：检测重复子序列和回环模式，提取循环体，保留单次执行路径。
让AI理解操作逻辑：用LLM分析操作序列的语义连贯性，重排顺序以对齐用户习惯。
结合业务逻辑验证：过滤异常路径，只保留高置信度的序列。
优化后，热门应用主要任务的路径压缩率普遍达到10%至50%，既提升了测试脚本的可复现性，也使其更贴近真实用户的操作流程。
（四）从“看指标”到“找代码”
性能测试跑完，会产生大量原始数据——CPU采样、内存分配、帧率统计、组件树快照等等。怎么从这些数据里提取出跟UI负载冗余相关的洞察，再把性能热点映射到具体源码？这是整个课题最核心的技术难点。
团队基于ArkAnalyzer-HapRay框架，通过命令行执行性能测试并采集多维度数据：CPU指令归因（精确到函数级的指令数统计）、内存占用趋势、组件树结构、UI页面状态等。然后用时间轴对齐技术，把性能数据和测试脚本的操作序列关联起来，建立起“操作→界面状态→性能开销→函数调用栈”的完整因果链。
分析结果有两种呈现方式：结构化JSON报告（给下游工具用）和可视化Web UI面板（开发者直观查看），火焰图能清晰展示函数级CPU时间分布。
系统内置的规则引擎能自动识别三类负载冗余模式：UI遮挡（被上层组件完全挡住、但还在参与布局计算的组件）、离屏计算（屏幕外还在做渲染更新的组件）、内存导入浪费（图像被完整导入内存但实际只需要低清晰度数据）。每个检测到的问题，系统都会给出“问题描述+影响分析+优化建议”的完整方案。
·
4
课题成果
目前，这个项目已经取得了相当扎实的成果：
学术方面，两篇相关论文分别被软件工程领域顶级会议ASE 2025 Industry Track和FSE 2026接收。
平台方面，智能终端UI负载冗余自动化分析和优化平台已合入ArkAnalyzer-HapRay开源项目。
实测数据：在QQ音乐、Bilibili等热门鸿蒙应用上完成了验证——GUI Agent主要功能探索时间3到5分钟，路径压缩率10%到50%，常见任务测试时间1到2分钟搞定。系统已支持UI遮挡、空刷、内存浪费等3种负载冗余场景的检测。
开源贡献：核心模块已托管于GitCode，未来将作为开源鸿蒙孵化项目ArkAnalyzer的组成部分，持续为开源鸿蒙生态贡献性能分析能力。
课题组寄语
周鸣一：开源鸿蒙生态正在大力发展中，研究中遇到的问题既是挑战也是机遇。课题组在开源鸿蒙领域的研究中发现的问题，都逐步转换成了相关成果。开源鸿蒙应用的性能优化依然有着大量亟待解决的科学和工程问题，欢迎大家加入进来。
写在最后
本课题填补了开源鸿蒙生态在自动化性能场景发现和UI组件级源码归因两个维度的技术空白。课题成果对开发者而言，将性能优化流程从“数日手工试错”压缩至“数分钟自动分析”，降低了技术门槛；对生态建设而言，可作为应用商店自动化审核工具，快速识别上架应用的性能瓶颈。
目前，本课题相关的核心技术模块已开源，社区可通过插件化方式扩展检测规则，形成持续演进的性能分析生态。未来将覆盖10+种典型问题场景，建设面向开源鸿蒙的综合测试服务平台，构建开源鸿蒙应用性能知识图谱。
附录：
开源项目地址：
ArkAnalyzer‑HapRay：https://atomgit.com/SMAT/ArkAnalyzer-HapRay
发表论文：
[1] “Phantom Rendering Detection: Identifying and Analyzing Unnecessary UI Computations”
[2] “An Empirical Study on UI Overlap in OpenHarmony Applications”
本文经AI辅助，人工审校后发布。
审核编辑 黄宇