—— 一份关于 EDR 渲染机制、设计语言演化与亮度认知模型的系统化文献


第一章：EDR，不只是“更亮”那么简单

当人们第一次在 iOS 26 或 visionOS 中看到那些“比白色还亮”的桌面图标时，我会将它称之为 “HDR UI”——这是2023年底我为这种新兴视觉现象所创造的通俗表述，尚未在业界广泛使用。

但如果我们认真追溯这个变化背后的技术机制，它的正式名字其实是：EDR（Extended Dynamic Range）。

▍什么是 EDR？

EDR 是 Apple 在系统层提出的一种 亮度动态扩展机制，最早并不是为 UI 而设计的，而是用于显示 HDR 内容的过渡层解决方案。它允许显示系统打破传统 RGB 的亮度上限，在保持图像细节的同时，呈现出更高峰值的亮度层次。
而今天，EDR 正式出现在了 UI 层：

• 图标的发光感、界面中按钮的浮光跃动、色块边缘的微妙对比，
• 不再是普通 RGB 色彩值可以表达的，而是建立在 线性曝光（Linear Exposure） 之上。

Apple 的开发者文档中写道（WWDC21）：
"EDR is a technique that lets you display content that exceeds the display's standard dynamic range by blending linear-light values with the tone-mapped SDR presentation." —— Apple Developer, WWDC21,

Explore HDR Rendering with EDR

▍EDR ≠ HDR，HDR ≠ HDR UI

我们必须清晰地区分三个概念：

虽然“HDR UI”不是 Apple 官方使用的说法，但从传播角度来说，这个词准确地传达了用户视觉感知的变化：
UI 不再是平的、静态的色彩组合，而是充满光感与动态层次的视觉语言。

▍从像素到光强：人机界面的亮度进化

这是一场从“像素表达”向“亮度意图”的跃迁。
在传统设计中，一个 UI 元素的视觉表现由 HEX 或 RGB 值控制；而在 EDR 中，这种表达方式已经不再足够。你不仅可以设定颜色，还可以控制其最大曝光强度，例如：
color.maximumEDRExposure = 2.0

这意味着这个颜色元素的亮度峰值可以达到标准白的 2 倍，从而在 HDR 屏幕上表现出「亮过白色」的效果。
设计师以往所认为的“纯白”，不再是界面的极限。光，成为新的界面基础元素。

▍不是“更亮”，而是“亮度有结构”

很多人对 HDR 的印象仍停留在“会不会亮瞎眼？”、“会不会更耗电？”这种感性层面。但真正的 EDR，不是单纯把所有元素拉亮，而是：

• 有组织的亮度分配机制；
• 有条件的曝光触发策略；
• 有系统级的焦点判断与亮度预算管理。

Apple 在 2025 年 WWDC 中展示了 UITraitHDRHeadroomUsage 和 HDRHeadroomUsageLimit 的机制，明确指出：
系统会根据元素是否处于焦点、是否在主窗口中，动态调节该元素的 EDR 渲染强度。
这不再是一个静态的 UI 皮肤，而是一个 视觉光场的动态调度系统。

本章小结：

• EDR 是系统层面的一种渲染机制，不等于传统视频意义上的 HDR；
• HDR UI 指代使用 EDR 机制的界面表现，是未来视觉语言的一种新结构；
• 设计语言正在从“色彩值”转向“亮度意图”，设计师需要掌握这套变化背后的逻辑；
• “白”不是绝对的，UI 的视觉表达进入了一个新的连续值空间。

第二章：为什么我称它为 HDR UI？

当系统 UI 首次展现出“超越白色”的亮度表现时，业界尚无统一的术语来形容这种现象。Apple 在其文档中使用的是 “EDR” 来描述这一机制，但这属于面向开发者的底层命名，较为晦涩。而我在 2023 年底选择使用 “HDR UI” 作为对这种视觉新现象的通俗表述，是基于传播效率和用户理解层面的考量。

▍HDR UI 是什么

这个表述并不等同于 HDR 内容，也不等同于 Apple 的 EDR 渲染机制。它是一种从用户感知角度出发的总结：

• 比传统 UI 更亮，但并非全亮；
• 有光感，有结构，不同于 sRGB 中的纯色扁平化设计；
• 在视觉感知中引入了“亮度分层”，构建出一种“光的设计语言”。

我们称之为 HDR UI，并非是技术精确命名，而是捕捉了其最直观的视觉感受。

▍传播的需要，不是命名的主权

我并不试图宣称“命名权”或设立标准。HDR UI 是一个过渡性的标签，它的意义不在于它是否成为官方术语，而在于：

• 是否帮助了设计师理解当前变化的本质；
• 是否让非开发者也能参与到新一代界面语言的讨论中；
• 是否为未来的 UI 结构命名和表达打下基础。

与其说是术语，不如说是观察者的一种实践记录。

▍为何不用 EDR UI？

很多人可能会问，为何不直接称为 “EDR UI”？
原因在于 “EDR” 对大多数人而言过于陌生且难以直观理解，而 “HDR” 已经广泛存在于用户的摄影、视频、显示器体验中，具有较好的感知锚点。
虽然两者有本质差异，但如果我们能够在传播初期使用一个熟悉但不误导的表达方式，建立认知入口是有价值的。

HDR UI 是一个设计语言正在变革过程中的叙述性描述。它不是标准，却可以成为理解标准的过渡桥梁。



第三章：亮度感知模型——设计师的新素养


▍从色值到亮度意图：视觉表达的跃迁

在传统的 UI 设计中，我们习惯以 HEX 或 RGB 色值来描述颜色，建立视觉层级。白色是上限，黑色是下限，其他色彩在中间游移。亮度的理解，也往往依赖色相、饱和度与对比度之间的关系。
但 EDR 渲染机制带来的改变是：
“亮度” 不再是由色值推导的，而是作为一种独立的参数存在。
你可以在颜色结构之外，定义其最大亮度阈值（如 maximumEDRExposure = 2.0），意味着这个颜色的最终亮度表现将高于系统白色。这样的表达方式，超出了设计稿本身的还原能力。

▍亮度可以被感知，也可以被量化

一个常见误解是：亮度是感性的，因屏幕和环境而异，设计无法控制。但事实是：

• 系统的渲染引擎（如 Metal）会根据线性曝光值（linear-light value）对元素进行 tone mapping；
• Apple 明确支持设计者设定曝光值（exposure value），并使用 HDRHeadroomUsageLimit 控制资源预算；
• 元素是否处于焦点（focus）、主窗口（key window）都会影响其亮度调度。

因此：
亮度感受不是纯主观，而是可以与系统亮度值建立映射关系的。
设计师可以逐步建立一套“亮度感知模型”来辅助决策，比如：

• 1.0 = 系统标准白（最大 SDR 白）
• 1.5 = 界面中局部提亮（如选中态）
• 2.0+ = 高光状态或拟物发光元素

▍设计稿 ≠ 最终视觉，Gap 如何应对？

设计稿大多仍使用 sRGB 色彩空间，原因包括文件格式兼容、设计工具限制和输出平台多样性。这意味着：
你在 Figma 或 Sketch 中看到的亮度层级，并不能完全还原最终在 HDR 屏幕上的真实表现。
那么如何工作？

1. 建立亮度心智模型，在设计时就考虑曝光等级，而非只看视觉图层；
2. 与开发协作设定参数，将色彩设计语言延展为光强语言；
3. 通过真实设备预览，建立“设计稿-实际效果”的感知映射表。

未来的设计师，必须理解亮度是“意图”而非“结果”，就像版式是为了引导阅读，色彩是为了传达情绪一样，
光，是为了组织注意力，塑造感知层次。



第四章：不是你以为的“亮瞎眼”——关于 EDR 的常见误解

当 HDR UI 渐渐进入公众视野，伴随而来的，是一系列似是而非的误解。
正如当年 Retina 屏幕刚刚普及时，许多设计师担心图标文件会暴涨、设备性能跟不上，如今关于 EDR，也有不少误读——“会不会太亮”、“是不是费电”、“对老设备不友好”……这些问题如果不被澄清，会极大阻碍设计师和开发者的正确认知。

▍误解一：EDR UI 会亮瞎眼？

真实情况：EDR 并非让所有内容变亮，而是一个有预算、受控调度的亮度增强机制。
Apple 在 WWDC 2025 中提出了 UITraitHDRHeadroomUsage 与 HDRHeadroomUsageLimit，用于控制：

• 哪些元素可以提升亮度（如主窗口、焦点元素）；
• 提升多少亮度（最大曝光预算限制）；
• 在什么状态下提升（动态判断）

所以，所谓“亮瞎眼”，本质上是对 HDR 视频中错误调色、全屏过曝的误解套用到了 UI 上。
UI 的亮度提升，通常是局部的、受约束的，而且设计师可以设定最大曝光值。例如：
color.maximumEDRExposure = 1.5 // 不超过标准白的1.5倍

▍误解二：亮度越高越费电？

这是一种对“亮度=功耗”的机械理解。
事实上，在 OLED 屏幕上，亮度功耗与面积和峰值亮度有关，但 UI 中的 EDR 多数只在小范围元素上使用，不会大面积高亮；
而 Apple 的动态调度机制，会在非交互状态、非焦点元素中主动降低曝光，从而降低功耗。
更重要的是，EDR 是按需触发、可控的，而非持续施加的。
正如动态岛并不会始终全亮，EDR 的光感也不会持续满功率工作。

▍误解三：这只是视觉噱头？

EDR 的使用不仅是“更漂亮”，而是推动 UI 向“光感结构”过渡的一种系统性演化。
设计师不再仅仅用色值去表达层级，而是用“光与影”去建立视觉注意力。
这不是滤镜效果，也不是 UI 主题皮肤，而是界面表达模型的根本变化。

▍误解四：只有最新设备才支持？

实际上，Apple 从 macOS Monterey / iOS 15 就开始在设备上支持 EDR 内容显示；iPhone 12 Pro 起即具备相关能力。
真正的变化在于：iOS 26 首次将 EDR 用于系统 UI 的主视图层级，这才是设计语言的跃迁起点。

▍误解五：设计师控制不了亮度？

EDR 的曝光值、焦点控制逻辑、资源预算机制，未来都将开放更多接口。
目前虽然 Figma / Sketch / XD 等工具仍主要基于 sRGB，但：

• 你可以通过开发者文档与实际设备观察，建立“亮度-意图”映射；
• 你可以与工程师协作设定曝光参数，实现比设计稿更真实的表现；
• 你可以参与“亮度设计语言”的制定，而非被动等待视觉还原。

结语：
HDR UI 所带来的不是一场表层美学潮流，而是从显示机制到底层语义的一次范式重构。
理解这些误解的来龙去脉，是设计师走向新视觉时代的第一步。


第五章：设计师角色的转变与组织的适配

当 UI 不再是简单的二维图形组合，而是拥有了亮度层级与动态光感的表达能力，设计师的角色也随之发生转变。
从颜色值的控制者，变为视觉能量的编排者； 从输出静态稿件的图层操作手，变为协同系统渲染与交互逻辑的参与者。

▍设计系统如何适配 EDR？

现有设计系统（Design System）大多基于 sRGB 构建，其 Tokens 通常定义为：
{
"primary-color": "#007aff",
"background-color": "#ffffff"
}
但在 HDR UI 中，还需要扩展新的维度：

• maximumEDRExposure（最大曝光）
• toneMappingCurve（局部映射曲线）
• focusPriority（焦点曝光优先级）

这些参数本质上是“非视觉图层”的元信息，需要写入组件文档中，供开发参考。
这也意味着：
设计语言未来不仅描述颜色、排版、形状，还必须描述光的使用方式。

▍与开发的协同将进入“物理层”沟通

以往我们与工程师沟通的是像素密度、边距与响应逻辑；而未来，我们还要沟通：

• 元素是否处于主窗口？
• 是否需要高曝光优先级？
• 某个交互动效是否触发局部提亮？

这要求设计文档中写清楚：
[按钮组件]
- 默认状态曝光值：1.0
- Hover 状态：1.25（受限于 `HDRHeadroomUsageLimit`）
- Active 状态：1.5，焦点元素触发
设计师不再只是交出一个 PNG，而是交出一组与系统协同运行的光感行为说明书。

▍组织层面的响应机制

随着 HDR UI 成为主流，组织需要更新以下机制：

1. 设计评审标准：

• 不仅评审图层，还要评估最终设备上的曝光表现；
• 可能需引入 HDR 屏幕设备参与日常评审流程。

1. 组件开发流程：

• UI 组件需支持 EDR 参数 注入与条件渲染；
• 与 Design Token 同步定义新曝光变量结构。

1. 设计工具更新节奏：

• 关注 Figma、Sketch 等工具何时支持 HDR 色彩与曝光参数；
• 暂时通过注释或与开发共享曝光结构表方式过渡。

1. 协作语汇标准化：

• 明确“1.5曝光值”、“焦点状态”、“亮度预算”等术语定义；
• 建立 UI 光感语言的团队内部共识。

结语：
当系统不再帮你“还原设计稿”，而是邀请你一起塑造最终视觉行为时， 设计师的核心价值也将从“交付物的创造者”，转向“视觉系统的合作者”。
这正是 HDR UI 时代，真正有能力的设计师，所要扮演的未来角色。


第六章：渲染机制Deep Dive —— Tone Mapping、Metal 与多平台适配

要理解 HDR UI 的渲染逻辑，仅靠设计师常见的 RGB / HEX 色彩知识已远远不够。
本章将从更底层的渲染机制展开，包括 Tone Mapping 曲线、Metal 框架的角色、HEIF HDR 素材在平台间的显示适配等，构建一套设计与工程之间可交互的认知桥梁。

▍Tone Mapping：将超亮信号映射回显示设备

Tone Mapping（色调映射）是 HDR 系统中最关键的核心技术之一。
它的任务是在不丢失高光信息的前提下，将线性光强信号映射到有限的显示亮度范围中。
常见的 Tone Mapping 算法包括：

• Reinhard Curve：温和渐进，常用于摄影；
• ACES Filmic Curve：常用于电影级别后期渲染；
• Apple EDR Custom Curve：Apple 系统自定义的可调控映射策略。

设计师应知晓：你设置的 maximumEDRExposure = 2.0，在不同 Tone Mapping 曲线下的表现会有所不同。

▍Metal 与 UI 渲染管线

Apple 的 Metal 是底层图形渲染框架，在 HDR UI 中主要用于：

• 支持 Linear 光强数据处理（vs gamma-corrected sRGB）；
• 管理多层级亮度 buffer 的合成与混合；
• 实现 EDR Compositor（从 macOS Ventura 起已支持）。

这意味着设计师交付的资源，并不是“直接贴图”那么简单，而是会经过一系列的 动态光强重建与曝光调度。
Apple 在 WWDC21 与 WWDC25 中均有说明： "EDR compositing blends linear-light values with tone-mapped SDR content using Metal-based rendering pipelines."
【参考链接：WWDC2021 - Explore HDR rendering with EDR】https://developer.apple.com/videos/play/wwdc2021/10047/

▍HEIF + HDR（10-bit 4:4:4）素材的跨平台问题

目前 iOS 26 支持截图保存为 HDR HEIF 格式：

• 色深：10-bit；
• 采样：4:4:4；
• 含有高亮元数据（Peak Brightness Tags）

但其显示效果在不同平台存在差异：

因此，设计师应采取以下措施：

• 对外分享时，使用双版本图像（HDR原图 + SDR回退图）；
• 避免在未明示支持的平台上仅用 HDR 图像传达设计意图；
• 在系统内部（iOS、visionOS）可使用 HEIF HDR 素材还原原始光感。

▍建议建立术语索引与标准参数表

为便于跨团队理解，建议在设计交付文档中添加以下术语表：

结语：
HDR UI 不是设计师独舞的舞台，而是系统渲染、平台支持、交互逻辑共同编排的视觉协奏曲。
理解这些底层机制，是构建高适配性、高质量视觉体验的前提。
让设计语言在所有屏幕上都能发光，是我们这个时代真正的使命之一。


第七章：照亮未来的不是技术，是理解力

从 sRGB 到 Display P3，从 gamma 显示到 linear 光强，从色彩数值到亮度结构，HDR UI 的演进并不是一次炫目的视觉更新，而是一次底层认知结构的更替。
设计师若想持续发光，必须主动进入这个新空间，并提出自己的理解框架。

▍从设计稿到视觉现实，中间还有多少"不可说"

EDR 的到来，让设计稿的“真实还原”变得前所未有地复杂：

• 不同屏幕的最大亮度能力不同；
• 系统 tone mapping 会动态调节曝光；
• 焦点管理策略会影响最终视觉分配；

这意味着：你交付的不再是一个确定结果，而是一个带有动态响应行为的设计意图。
UI 的表现，从“像不像”变为“应不应该亮”与“亮在哪儿”。
未来的设计稿，可能需要用 Design + Behavior Script 的形式存在。

▍设计教育体系，也要改变了

目前大部分设计教学仍停留在：

• 色彩搭配 / 网格布局 / 可用性原则；
• 高保真稿件输出与组件复用技巧；

但在 HDR UI 语境下，我们需要加入：

• 亮度结构识别（Brightness Composition）；
• 光感焦点推理（Focus-based Exposure Planning）；
• 多平台视觉策略（Multi-context Display Design）；

这将是设计与工程之间的一次真正融合，而不仅仅是“懂点代码”的 Designer。

▍标准化与协作流程的预见

未来五年，我们可能会看到：

1. Figma / Sketch 支持曝光控制参数；
2. Design Token 扩展至亮度与 tone mapping 曲线控制；
3. 组件库中增加光感变体（EDR-aware variants）；
4. 开发平台统一 HDR 渲染指令集（跨 Apple / Android）；

这其中需要：

• 企业内部的适配组织机制；
• 设计社区对工具厂商的推动；
• 内容平台对 HDR 素材的支持升级；

这些都将是设计话语权延伸至系统生态层的关键一战。

▍从 Pixel 到 Perception：设计的哲学层面

设计师的使命，从来就不只是让“界面好看”，而是构建人与信息之间的感知桥梁。
HDR UI 把这个命题重新提上桌面。
我们开始意识到：

• 视觉，不只是颜色，更是能量感受；
• 信息，不只是结构，更是注意力调度；
• 界面，不只是页面，更是一块被光激活的行为剧场。

最终章语：
EDR 不是一项“设计功能”，它是一场对于视觉感知机制的重新定义。
在光的世界里，每一束亮度都不再是数字，它是行为、是意图，是一场人与机器共建的新语言。
而我们每一个设计师，正在成为这门语言的最早缔造者之一。

愿你的设计，不止能被看见，更能照亮理解。

優(yōu)網(wǎng)科技秉承"專(zhuān)業(yè)團(tuán)隊(duì)、品質(zhì)服務(wù)" 的經(jīng)營(yíng)理念，誠(chéng)信務(wù)實(shí)的服務(wù)了近萬(wàn)家客戶，成為眾多世界500強(qiáng)、集團(tuán)和上市公司的長(zhǎng)期合作伙伴！

優(yōu)網(wǎng)科技成立于2001年，擅長(zhǎng)網(wǎng)站建設(shè)、網(wǎng)站與各類(lèi)業(yè)務(wù)系統(tǒng)深度整合，致力于提供完善的企業(yè)互聯(lián)網(wǎng)解決方案。優(yōu)網(wǎng)科技提供PC端網(wǎng)站建設(shè)（品牌展示型、官方門(mén)戶型、營(yíng)銷(xiāo)商務(wù)型、電子商務(wù)型、信息門(mén)戶型、DIY體驗(yàn)、720全景展廳及3D虛擬仿真）、移動(dòng)端應(yīng)用（手機(jī)站、APP開(kāi)發(fā)）、微信定制開(kāi)發(fā)（微信官網(wǎng)、微信商城、企業(yè)微信）、微信小程序定制開(kāi)發(fā)等一系列互聯(lián)網(wǎng)應(yīng)用服務(wù)。