鸿蒙 1024|从评测到鸿蒙应用开发:我做了一款专业屏幕测试工具
显示效果评测专家Navis在华为开发者大会后,基于鸿蒙系统开发新工具,克服技术挑战,提升效率并推出公众版本。 2025-10-28 11:4:41 Author: sspai.com(查看原文) 阅读量:8 收藏

编注

本文是少数派 1024 程序员节征文活动的入围文章,你可以点击这里查看本次征文活动的全部获奖文章以及入围投稿。


缘起 HDC

我是 Navis,如果有认识的朋友可能知道,我的主业之一是显示效果评测,从手机、电脑到电视、智能眼镜,只要是块屏幕,我们都会用专业的仪器和流程去量化它的表现,为关注屏幕素质的朋友提供参考。

但这个行业变化很快,我们的测试方法和工具也必须与时俱进。相对来说,电视和显示器的评测还算直接,它们是单纯的显示设备,一套 Calman 软硬件基本就能搞定所有测试;但手机就复杂多了,不管是 iOS 还是 Android,系统越来越强大,我们需要测试和利用到的系统特性也越来越多。

想要做出真正专业的评测而不是停留在「看个大概」的层面,就必须自己开发全套的软硬件。所以我们一直都有自己内部使用的 iOS 和 Android 客户端。

转折点发生在 2024 年的华为开发者大会 HDC。

当我以媒体身份坐在台下,看到 HarmonyOS NEXT 发布的时候,我清楚地意识到华为未来的设备必然会全面转换到原生鸿蒙,那目前基于 Android 的评测流程也会完全失效,这对我们来说是个非常严峻的挑战。

为了保证评测的专业性,我没有别的选择,必须重新在 HarmonyOS 5 上开发我们的测试流程。

我也是在那时候注册的华为开发者账号,并开始认真研究 ArkTS 和 ArkUI 的特性。我的目标只有一个:赶在第一批原生搭载 HarmonyOS NEXT 的产品(比如后来的 Mate 70 系列)上市之前,把我们的新一代评测工具做出来。

ArkTS 和 ArkUI 上手体验

真正投入开发后,我确实感受到了 ArkTS 和 ArkUI 在很多方面的优势,有些甚至超出了我的预期。

首先开发效率是真的高

做我们这种专业工具,UI 好不好看是次要的,核心的功能逻辑不出错才是最重要的。

ArkUI 的声明式范式,让我们能把绝大部分精力都放在「我们要测什么」以及「如何精确实现」上,而不是纠结于「这个按钮该如何渲染和更新」。

我们只需要定义好一个状态变量,比如 @State colorValue,然后把 UI 组件和它「绑定」。只要数据一变,UI 就会自动刷新。这种模式让我们能更专注于核心的功能,比如如何生成符合标准的色度标准的图案,或者如何精确控制 EOTF 灰阶曲线。

用原生鸿蒙开发的效率,比我们以前在其他平台上的经验快了非常多。

跨设备适配出乎意料的省心

我们的工作性质决定了 App 必须能跑在各种形态的设备上,不管是标准的直板机,还是各种形态的折叠屏。这不只是为了好看,更关系到测试的准确性。比如一个标准的棋盘格测试图,在不同比例的屏幕上要是被拉伸变形了,那测出来的数据就全错了。

ArkUI 在「一次开发,多端部署」这方面做得确实不错。它的布局系统很智能,能根据设备的屏幕尺寸和比例自己调整好。我们的 App 开发完,不用为哪种折叠形态单独写适配代码,在标准的直板机、三折叠、或者阔折叠,甚至后来的鸿蒙折叠电脑上都可以运行,效果都非常完美。

对显示测试 app 来说,底层能力很关键。鸿蒙对色彩管理的支持相当完善

做专业显示测试,我们最怕的就是系统在显示链路里增加一些「黑箱」或者是对色彩管理的支持不完全,那就会导致没办法精确控制颜色,测出来的数据也就又没有了意义。

鸿蒙在色彩管理这方面给了我们惊喜,它的渲染管线更透明、更可控。比如我们可以通过调用 colorSpaceManager,强制让 App 窗口工作在 Display P3 广色域下,确保输出的 P3 色域图案不会被系统偷偷压缩,保证色域和色准测试的有效性。

在测 HDR 时,我们也能通过 @kit.ArkGraphics2D 清楚地知道设备支持哪些 HDR 格式,然后输出对应的测试信号。

这种底层能力的开放是我们能做专业级测试的前提。

最后,除了手动测试我们也需要很多网络方面的支持。现在的评测是不可能手动进行的,否则费时费力,重复性可靠性也会下降,我们的核心还是让 App 控制屏幕显示正确的图像,然后和我们的 PC 客户端连接进行自动测试。

从我的体验来看,鸿蒙提供的 @kit.NetworkKit  确实好用,通过它我在 App 里自己动手实现了一整套网络服务,我们支持了自己的 HTTP API、TPG TCP 服务,还兼容了 Resolve 等行业工具的协议,甚至做了 UDP 广播来自动发现设备,整体体验非常的流畅稳定。

当然,我也能感受到 GodeGenie 一直在进化

GodeGenie 是 DevEco Studio 内置代码工具。随着我们的开发进程推进,它的智能化程度也在不断提升,从最开始简单的行内代码补全、相关信息搜索,到后来的智能上下文问答,我们有很多的问题其实都是通过 AI 的启发来解决的。

一次新领域的自我投资

最初选择开发鸿蒙应用,可以说完全是出于专业上的「自救」。但现在回头看,我们的收获远远超出了一个内部工具本身。

通过鸿蒙 App 的开发,我们对于系统熄底层是如何影响显示效果又有了新的理解,当然最核心的价值还是我们保住了「专业性」。当 Mate 70 系列发布时,我们没有因为缺少工具而手足无措,反而成了第一批能对原生鸿蒙显示效果进行深度量化分析的团队。

开发过程也并非一帆风顺,比如鸿蒙严格的功耗管理就给我们上了一课:在做动态模糊(MPRT)测试时,测试图案的闪烁必须和屏幕的物理刷新「严格同步」。为此我们采用了 displaySync 机制,让我们的逻辑由「帧」驱动,而非「时间」驱动,从根本上保证了同步的精确性。

但即便我们用 setExpectedFrameRateRange 接口请求了 120Hz 刷新率,系统出于省电的设计,只要屏幕画面静止,刷新率还是会很快掉到 60Hz,因为鸿蒙的高隐私权限限制,我们也没有办法用虚拟的触摸来「骗过」系统,让它保持最高刷新率。

最后还是通过外部的方式来绕过这一点。

我理解系统为大众用户体验做的取舍,但也真心希望,未来鸿蒙能为专业开发者提供一个更灵活的「开发者模式」,以满足这类特殊场景的需求。

目前,我们开发的这个 App 已经成功地帮助我们做了一年的评测,内部都已经迭代到了 2.0 的版本,当然它可能永远不会成为一个大众 App,但它的存在,本身就承载着我们对「精准」和「客观」这两个词的承诺。

接下来,我们计划把 App 里的一些手动测试功能简化一下,做一个面向公众的版本,让普通用户也能快速检查自己设备的显示效果。我们会继续努力,争取早日完成上架。

从最初被技术变革推着走,到如今能够主动参与到生态建设中,这段经历给我留下非常深刻的印象,挑战确实与机遇并存,前瞻的投入最终都会沉淀为自己最核心的竞争力,也希望华为的生态如此。

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀


文章来源: https://sspai.com/post/103206
如有侵权请联系:admin#unsafe.sh