显示器分辨率和缩放
使用高分辨率显示器时，很多人都会遇到应用界面太小的问题，比如正在使用27寸2K显示器，更换了27寸4K显示器后应用界面都会变小，需使用操作系统提供的缩放功能来放大。
Window和MacOS使用的不同的方法来解决高分辨率显示器带来的UI不适配的问题。
注意几个概念：
显示器尺寸，显示器物理分辨率，逻辑分辨率，渲染分辨率，设备像素比(DPR)/缩放因子
问题产生
首先了解显示器的基本原理，显示器有两个重要的参数，物理尺寸和分辨率。
- 物理尺寸：分为宽、高、对角线三种尺寸，常用对角线的长度（英尺）表示显示器大小，其宽高比例通常为16:9或16:10。
- 分辨率：显示器是由一个个像素点组成，横向的像素点个数即为宽的分辨率，竖向的像素点个数即为高的分辨率。常用的分辨率为1080p(1920x1080)，2K(2560x1440)，4K(3840x2160)，5K(5120x2880)，6K(6144 × 3456，其中 Pro Display XDR 为 6016 × 3384)。
常用显示器分辨率
| 分辨率名称 | 分辨率（宽×高） | 像素总数（百万） | 相对 1080p 面积倍数 | 典型 PPI（参考尺寸） | 主要用途与典型设备 |
|---|---|---|---|---|---|
| 1080p (Full HD) | 1920 × 1080 | ≈2.1 MP（约207万） | 1.0× | 24”：≈92 PPI | 主流入门标准；FHD 显示器、1080p 电视、普通笔记本；Netflix/YouTube 基准画质；PS4/Xbox One |
| 2K (QHD / 1440p) | 2560 × 1440 | ≈3.7 MP（约369万） | 1.8×（精确为1.78×） | 27”：≈109 PPI 24”：≈123 PPI | 27寸游戏显示器主流规格，兼顾清晰度与显卡负载；MacBook Air/Pro 外接 |
| 4K (UHD) | 3840 × 2160 | ≈8.3 MP（约829万） | 4.0×（横竖各×2） | 27”：≈163 PPI 24”：≈184 PPI | 4K 电视、消费级显示器；iPhone 视频录制规格；macOS @2× 等效 PPI 偏大（27”仅81ppi） |
| 5K (UHD+) | 5120 × 2880 | ≈14.7 MP（约1475万） | 7.1× | 27”：≈218 PPI （macOS @2× 等效 109ppi） | Apple iMac 27”、Studio Display、LG UltraFine 5K；27寸 macOS 的“甜点”分辨率 |
| 6K (Pro XDR) | 6016 × 3384 （标准 6K：6144 × 3456） | ≈20.4 MP（约2036万） | 9.8× | 32”：≈218 PPI （macOS @2× 等效 109ppi） | Apple Pro Display XDR（32”）、RED 6K 摄影机；视觉密度与 27” 5K 一致 |
常用显示器尺寸和对应分辨率
| 对角线尺寸 (英寸) | 宽 × 高 (英寸) | 常见分辨率 | PPI | 备注 / 适用场景 |
|---|---|---|---|---|
| 21.5 | 18.76 × 10.56 | 1920×1080 (FHD) | 102.5 | 入门办公、基础影音 |
| 24 | 20.92 × 11.77 | 1920×1080 (FHD) | 91.8 | 电竞/办公黄金尺寸，视野集中 |
| 24 | 20.92 × 11.77 | 2560×1440 (2K) | 122.4 | 小尺寸高分屏，文字锐利 |
| 24 | 20.92 × 11.77 | 3840×2160 (4K) | 183.6 | 超高PPI小屏，代码/精密修图/医疗影像 |
| 27 | 23.53 × 13.24 | 1920×1080 (FHD) | 81.6 | ⚠️ 颗粒感明显，不推荐 |
| 27 | 23.53 × 13.24 | 2560×1440 (2K) | 108.8 | 当前最主流甜点规格，游戏/办公均衡 |
| 27 | 23.53 × 13.24 | 3840×2160 (4K) | 163.2 | 设计/影视后期/Window用户首选 |
| 27 | 23.53 × 13.24 | 5120×2880 (5K) | 217.6 | Retina级细腻度，Mac Studio/iMac同级体验 |
| 32 | 27.89 × 15.69 | 3840×2160 (4K) | 137.6 | 高端生产力/主机游戏 |
| 32 | 27.89 × 15.69 | 6016×3384 (6K) | 226.4 | Apple Pro Display XDR同款，顶级HDR后期 |
显示器的 PPI（Pixels Per Inch）为每英寸像素数，是衡量屏幕显示细腻程度的核心指标。PPI 数值越高，每英寸空间上像素点越多，屏幕画面越清晰细腻、细节越丰富。
\[PPI = \frac{\sqrt{X^2 + Y^2}}{Z}\]其中 X：水平像素数（宽度），Y：垂直像素数（高度），Z：屏幕对角线尺寸（英寸）。得出在相同分辨率下，屏幕尺寸（Z）越大，PPI越小。
对显示器有了基本了解后，通过一个例子讲解为什么高分辨率的显示器导致UI偏小。
首先，假定一个 6英寸 x 4英寸 的显示器，分辨率为 6px x 4px，其PPI为1（$\frac{6 px}{6 inch}= 1$）
图1
在6x4的显示器中呈现一个占据两个像素的斜杠
图2
当将显示器的分辨率提升到12x8时，此时的ppi为2（$\frac{12px}{6inch} = 2$），斜杠的具体渲染为
图3
在显示器尺寸不变的情况下，同为占据两个像素的斜杠变小了。
解决方案
操作系统（如Window,MacOS）提出了逻辑分辨率来解决高分辨率显示器下UI过小的问题。
\[GPU渲染像素(显示器物理像素) = 操作系统逻辑像素 \times 设备像素比(DPR)/缩放因子\]注：其中设备像素比（DPR） 代表 一个逻辑像素需要几个物理像素渲染。
注：GPU渲染像素不一定等于显示器物理像素，尤其在MacOS中，如果无法满足整数倍缩放，GPU渲染像素是大于显示器物理像素的，需要降采样才能呈现到屏幕上。
在6x4的显示器中一个逻辑像素用一个物理像素渲染，DPR=1；下面给出在12x8的显示器中一个逻辑像素用四个物理像素渲染，DPR=2（宽高都是两倍，面积为4倍）。原来占据两个物理像素斜杠现在占据八个物理像素了，但其逻辑像素仍是两个。
图4
12x8的显示器在DPR=1中一个逻辑像素使用一个物理像素渲染，将宽高分别扩大两倍后，即用四个像素代替之前的一个像素，此时DPR=2。
12x8的显示器DPR=2的斜杠物理大小与6x4的显示器DPR=1显示的大小相同，只是前者用8个物理像素表示，后者用2各物理像素表示。这样解决了当PPI变高后UI显示变小的问题，当PPI变高后，就用更多的物理像素渲染UI，让其占用的物理空间变大。
操作系统引入了逻辑分辨率，用于解决高PPI屏幕（如Retina屏、4K屏）下如果按照逻辑像素：物理像素 = 1:1来显示界面，文字和图标会变得极其微小，难以看清的问题。逻辑分辨率是操作系统用来定义用户界面（UI）元素大小的基础单位。它不直接对应屏幕的真实物理像素，而是作为UI布局的参考基准。用于保证在不同PPI的设备上，文字、按钮等UI元素的“视觉物理大小”基本保持一致，提供舒适的阅读和操作体验。
为了方便理解，上面图4中黑色可以看作为逻辑分辨率，黑色加蓝色看作为实际物理分辨率。其中渲染的一个紫色块对于逻辑分辨率仍然是一个逻辑像素，但实际是用四个物理像素渲染。
具体流程
- 首先，操作系统确定逻辑分辨率，UI的布局使用逻辑分辨率（对于Macos，用户选择的即为逻辑分辨率；对于Window，用户选择的是显示器物理分辨率，逻辑分辨率=物理分辨率/缩放比例）
- 其次，操作系统会确定缩放因子，（对于MacOS，缩放因子必须是整数倍，如1x，2x等；对于Window，缩放比例可以是任意数值）
- 操作系统计算出实际的渲染分辨率，渲染分辨率=逻辑分辨率x缩放比例，GPU以渲染分辨率对UI组件渲染，对于倍率素材（如PNG）根据缩放因子选择对应的资源（如缩放因子=2选择@2x.png）
- 最后，将GPU按照渲染分辨率渲染出的画面呈现到显示器上，（如果显示器物理分辨率与GPU渲染分辨率低，则需要将采样，让渲染分辨率降采样到显示器物理分辨率，主要出现在MacOS中）
HiDPI渲染流程
布局规划
此阶段，所有计算均在逻辑坐标系中完成。
处理：UI 框架（如 WPF, SwiftUI, Qt）根据父容器约束和子组件需求，递归计算每个元素的
x, y, width, height。例如：按钮位于 (10, 20)，大小为 (100, 50) 逻辑像素。坐标变换
渲染引擎读取当前显示器的 DPI/缩放因子（如 2.0）。
处理：在构建 GPU 渲染指令或绘制列表时，将所有逻辑坐标乘以缩放因子，如逻辑
(10, 20)→ 物理绘制坐标(20, 40)；逻辑尺寸(100, 50)→ 物理绘制尺寸(200, 100)图片加载器根据缩放因子选择对应倍率的素材（如
@2x.png），避免运行时拉伸。字体引擎请求对应物理 DPI 的字形轮廓。光栅化合成
GPU/CPU 在物理分辨率级别执行实际绘制。
处理：
- 创建帧缓冲：分配一块大小为
逻辑宽×缩放因子 × 逻辑高×缩放因子的显存/内存区域。（缓冲区从一开始就是物理尺寸，而非逻辑尺寸） - 矢量光栅化：FreeType/CoreText/DirectWrite 直接使用物理 DPI 参数对字体轮廓进行采样和抗锯齿。
- 位图采样：若DPI/缩放因子是2, 对于 @2x 图片，以 1:1 映射到物理像素；若只有 @1x 图片，则在此阶段通过双线性/双三次插值上采样到目标物理尺寸。
- 图层合成： 将各个 UI 元素、阴影、透明度混合写入最终的物理帧缓冲。
- 创建帧缓冲：分配一块大小为
扫描输出
渲染完成的物理帧缓冲被提交给窗口管理器/合成器。
处理：点对点映射： 由于缓冲区尺寸已与显示器物理分辨率一致，显卡控制器直接进行 1:1 扫描输出，无需任何额外的硬件缩放。（如果是MacOS非整数倍缩放，缓冲区尺寸与显示器物理分辨率不同，需要降采样）
开发者设计应用大小
到此肯定有人困惑，那开发者如何针对不同尺寸不同分辨率的设计应用程序的尺寸呢？
一般设计应用大小有两种方式，使用固定大小，或根据屏幕大小使用百分比。
固定大小：开发者设计的大小都为逻辑大小（逻辑分辨率），如macOS/iOS：Points (pt)；Windows：DIP（Device-Independent Pixels）；Web：CSS pixels。
目前MacOS常用的逻辑分辨率有1920x1080和2560x1440，如果使用固定大小开发窗口，应用窗口的大小可设计为1400x900左右，这样在两种常用的逻辑分辨率下，占据窗口的大小都相对适中。（如果窗口为1800x1300，会导致在逻辑分辨率1920x1080下超出屏幕大小）但当逻辑分辨率提升到了3008×1692，此时应用程序对于屏幕来说就显得有些小了。
屏幕百分比：不同屏幕可以设置不同的逻辑分辨率，如果固定应用窗口大小，对于逻辑分辨率小的会出现应用窗口溢出，对于分辨率大的会出现应用窗口占据屏幕很小。为解决此问题，应用程序会首先获取操作系统的逻辑分辨率，以此为基准，按照设定好的比例（如80%）计算应用窗口应该多大。（如逻辑分辨率为1920x1080,应用窗口为1920x0.8 x 1080x0.8；若逻辑分辨率为2560x1440,应用窗口为2560x0.8 x 1440x0.8。这种情况下，如果屏幕尺寸不变，选择两种逻辑分辨率渲染出的应用窗口的物理大小是一样的）
使用屏幕百分比适配性更强，因为UI的物理大小只与逻辑分辨率和屏幕尺寸有关，应用程序只关心当前的逻辑分辨率并按照此分辨率计算UI占据屏幕的比例，具体映射到物理分辨率的渲染由操作系统负责。
下面给出几个例子讲解固定应用窗口大小在不同显示器尺寸，不同显示器物理分辨率下的情况，加深理解。
1 逻辑像素的大小（inch） = 物理宽度 / 逻辑宽度，开发者使用逻辑像素设计UI大小，所以UI的实际物理大小只与显示器大小和逻辑分辨率有关，与显示器物理分辨率无关。
| 显示器 | 物理尺寸 | 物理分辨率 | 逻辑分辨率 | 1 逻辑像素 (inch) | 1000pt 宽 (inch) | 500pt 高 (inch) |
|---|---|---|---|---|---|---|
| 24”1080p | 20.9” | 1920×1080(1080p) | 1920×1080(1080p) | 20.9/1920 = 0.010885 | 10.89 | 5.44 |
| 24”4K | 20.9” | 3840×2160(4K) | 1920×1080(1080p) | 20.9/1920 = 0.010885 | 10.89 | 5.44 |
| 27” 2K | 23.5” | 2560×1440(2K) | 2560×1440(2K) | 23.5/2560 = 0.009180 | 9.18 | 4.59 |
| 27” 4K | 23.5” | 3840×2160(4K) | 1920×1080(1080p) | 23.5/1920 = 0.012240 | 12.24 | 6.12 |
| 27” 4K | 23.5” | 3840×2160(4K) | 2560×1440(2K) | 23.5/2560 = 0.009180 | 9.18 | 4.59 |
| 27” 5K | 23.5” | 5120×2880(5K) | 2560×1440(2K) | 23.5/2560 = 0.009180 | 9.18 | 4.59 |
| 27” 5K | 23.5” | 5120×2880(5K) | 1920×1080(1080p) | 23.5/1920 = 0.012240 | 12.24 | 6.12 |
显示器最佳PPI
至此，已经理解了逻辑分辨率，显示器物理分辨率，显示器尺寸共同决定了UI尺寸和UI清晰度。但还有一个问题，开发者在设计应用程序时，应该以什么基准进行设计，操作系统提供了DPI/缩放因子（如1x,2x,3x），那这个1x的基准是什么？比如逻辑分辨率1920x1080放大两倍（2x）为3840x2160的渲染分辨率，逻辑分辨率2560x1440放大两倍（2x）为5120x2880渲染分辨率，两者都是放大两倍，选择都是2x的资源（如@2x.png）进行渲染，那开发者什么时候使用逻辑分辨率1920x1080，又什么时候使用逻辑分辨率2560x1440进行开发。这就需要引入显示器的PPI了。
MacOS历史发展
72 DPI 时代：为印刷而生的”所见即所得”（1984–2010）
在印刷行业中，1 point (pt) = 1/72 inch。这是几百年来铅字排版的物理标准。1984 年，Apple Macintosh 搭配 LaserWriter 打印机发布时，乔布斯和团队为了实现 “WYSIWYG”（所见即所得），刻意将屏幕分辨率设定为 72 PPI。保证了屏幕上 1 pt 的文字 = 打印出来 1 pt 的文字。即屏幕上的 1 英寸 = 现实中的 1 英寸。
- 初代 Macintosh 屏幕物理分辨率就是 72 PPI，1 个屏幕像素 = 1 个点（point）。
过渡期：物理像素增长 vs 逻辑坐标不变（2000s–2012）
随着显示器技术进步，Apple 自家和外接显示器的物理 PPI 逐渐超过 72，如MacBook Pro 15” (non-Retina) 是 110 PPI，但 macOS 从未改变其 72pt 的逻辑坐标系，导致文字和 UI 元素在更高密度的屏幕上物理尺寸变小。此时Windows 阵营此时已开始引入 DPI 缩放（96 DPI 基准 → 125%/150%），但 macOS 坚持不做非整数缩放。
Retina / HiDPI 时代：2× 整数倍缩放（2012–至今）
Apple 没有像 Windows 那样做”百分比缩放”，而是采用了整数倍方案。
| 概念 | 说明 |
|---|---|
| 物理分辨率 | 2880 × 1800（15” MBP） |
| 逻辑分辨率 | 1440 × 900（= 物理 ÷ 2） |
| 缩放因子 | 2×（每个逻辑点由 2×2=4 个物理像素渲染） |
| 等效 PPI | ~220 PPI（物理），但逻辑上仍按 ~110 PPI 布局 |
总结：
| 时代 | 代表设备 | 逻辑 PPI | 驱动因素 |
|---|---|---|---|
| 1984–2010 | Classic Mac / Cinema Display | 72 | 印刷排版对齐（1pt = 1/72 inch），非 Retina |
| 2010–2012 | MacBook Air / Thunderbolt Display | ~100–110 | 笔记本视距较近，需要更高密度；外接屏跟随 |
| 2012–至今 | Retina MacBook → 5K iMac → Studio Display | ~109–114 | Retina 渲染 + 桌面工作空间的平衡点确立 |
| 2026 (当前) | 全线在售 Mac | ~109–114 | 已收敛并锁定 |
最初设计逻辑PPI=物理PPI=72是为了与印刷排版对齐，屏幕呈现即打印所得，并不是为了让用户观看更加合适。后来随着屏幕PPI逐渐提升，Apple发现外置显示器通常放在距眼睛约60cm处，在这个距离下，人眼感觉”UI大小舒适”的逻辑密度大约就是 100~110 逻辑PPI。即每pt的实际物理大小为 $\frac{1}{109}$ 左右，最佳逻辑PPI一般只与观看距离有关，下面给出不同苹果设备最佳的逻辑PPI：
| 设备 | 典型观看距离 | 最佳逻辑PPI | 实际物理PPI | HiDPI倍率 |
|---|---|---|---|---|
| iPhone | ~35cm | ~160 | 460（Pro） | 3× |
| iPad | ~50cm | ~130 | 264 | 2× |
| Mac 外置显示器 | ~60cm | ~109 | 218 | 2× |
| MacBook | ~55cm | ~127 | 254 | 2× |
屏幕尺寸影响的是”逻辑分辨率”，同样是109逻辑PPI：
1
2
3
24寸屏：逻辑分辨率 ≈ 2048×1152 # 一般选择常用的1920x1080（1080p）代替
27寸屏：逻辑分辨率 ≈ 2560×1440 # 正好是2K
32寸屏：逻辑分辨率 ≈ 3072×1728 # 乘以2后选择6K代替
逻辑PPI相同，但更大的屏幕给你更多的桌面空间，而不是更大的UI。这也说明了显示器尺寸确定后，最佳逻辑分辨率也是确定的（因为外置显示器的最佳逻辑PPI=109是不变的，且显示器宽高比一般为16:10）。
Window历史发展
Window PPI的确定比MacOS简单多了，Window一开始就确定了96DPI的基准，后来提供了缩放比例，如Window11的任意缩放比例 或 125%,150%,175%,200%等常见比例。针对不同显示器的PPI选择不同的缩放比例。理论上是可以完美适配任何显示器的，但需要软件支持。 由于很多软件并没有支持，所以在Window仍然也是在整数倍缩放的效果是最好的（因为原来1个像素正好由$2^n$个像素（如4或8）完美替代，不需要引入类似差值算法导致模糊）。
\[Window 缩放比例 = \frac{显示器PPI}{96}\]| 显示器PPI | Window缩放比例 |
|---|---|
| 96 | 100% |
| 120 | 125% |
| 144 | 150% |
| 192 | 200% |
| 216 | 225% |
下面是市面上常见的显示器在Macos的最佳逻辑分辨率和在Window的最佳缩放比例
- macOS: 外置显示器的最佳体验永远是 PPI ≈ 220 (即 Retina 2x，逻辑分辨率 ≈ 109)。当 PPI 在 160~220 之间时，需开启 HiDPI 并选择“较大文字”；PPI < 140 时体验下降明显。
- Windows: 以 96 PPI = 100% 为基准。推荐缩放 =
显示器实际PPI / 96，然后取整到系统支持的档位（100/125/150/175/200%）。
| 尺寸 | 物理分辨率 | PPI | macOS 最佳逻辑分辨率 | macOS 备注 | Windows 推荐缩放 | Windows 等效逻辑分辨率 |
|---|---|---|---|---|---|---|
| 21.5” | 1920×1080 | 102.5 | 1920×1080 | ⚠️ 无法开启HiDPI，字体发虚 | 100% | 1920×1080 |
| 24” | 1920×1080 | 91.8 | 1920×1080 | ⚠️ 不建议Mac使用 | 100% | 1920×1080 |
| 24” | 2560×1440 | 122.4 | 1920×1080 (HiDPI) | 可用但偏模糊，非整数缩放 | 125% | 2048×1152 |
| 24” | 3840×2160 | 183.6 | 1920×1080 (HiDPI) | ✅ 接近Retina，文字锐利 | 200% | 1920×1080 |
| 27” | 1920×1080 | 81.6 | 1920×1080 | ❌ Mac/Win均不推荐 | 100% | 1920×1080 |
| 27” | 2560×1440 | 108.8 | 2560×1440 | ⚠️ 无HiDPI，Mac体验一般 | 125% | 2048×1152 |
| 27” | 3840×2160 | 163.2 | 2560×1440 (HiDPI) | ✅ Mac主力推荐，UI大小舒适 | 150% | 2560×1440 |
| 27” | 5120×2880 | 217.6 | 2560×1440 (HiDPI) | ✅✅ 完美Retina 2x，iMac同级 | 225% | 2560×1440 |
| 32” | 3840×2160 | 137.6 | 2560×1440 (HiDPI) | 可用，略低于Retina标准 | 150% | 2560×1440 |
| 32” | 6016×3384 | 226.4 | 3008×1692 (HiDPI) | ✅✅ 完美Retina 2x，Pro Display级 | 250% | 2406×1354 |
结合上表，对于Macos来说24寸4K，27寸5K，32寸6K是比较理想的；因为Window已经支持任意比例缩放，UI大小总可调到合适，可完美适配任何PPI的显示器，但呈现效果的好坏主要取决于应用程序是否支持 DPI Aware，开发者需要自己处理缩放。
注：Windows 的 DPI Aware 是自愿声明制，而非强制渲染管线。只要生态中存在一个未声明 PerMonitorV2 的组件，该窗口在非标准缩放下就会回退到位图拉伸。这就是为什么即使系统支持任意值，实践中仍推荐 100/125/150/200% 等”安全档位”——不是因为系统不行，而是因为第三方应用跟不上。Window理论上可以适配任何PPI的显示器，但具体的效果需要软件自己适配。
Window和MacOS的区别
表面上看起来一样，好像都是”物理分辨率 ÷ 缩放因子 = 逻辑分辨率”，但根本方向相反。
1
2
macOS：物理PPI 218 → 2×缩放 → 逻辑PPI 109
Windows：物理PPI 192 → 200%缩放 → 逻辑PPI 96
区别：
macOS：逻辑分辨率是第一公民：
先确定目标逻辑PPI（109） → 再根据屏幕物理PPI反推需要几倍缩放 → 物理分辨率是为逻辑分辨率服务的
开发者只需针对逻辑坐标系写代码，完全不需要知道物理分辨率是多少。
Windows：物理分辨率是第一公民：
先有物理分辨率（屏幕买来是多少就是多少） → 用户手动选择缩放比例（100%/125%/150%/200%） → 系统尝试把UI放大到合适大小
缩放是一个事后补救机制，不是预先设计好的体系。
对于渲染质量：
macOS：应用按逻辑点绘制 → 系统用精确2×渲染到物理像素。
永远是整数倍，像素完美对齐
Windows：125%、150%这类非整数缩放。
物理像素无法整数对齐 → 文字边缘模糊 这就是Windows长期被诟病的”字体发虚”问题
应用适配性：
macOS：应用只管逻辑坐标，系统保证渲染质量，开发者几乎零负担
Windows：早期应用完全不知道缩放存在（DPI Unaware），系统只能把整个应用截图放大 → 糊；
后来引入Per-Monitor DPI Aware，开发者需要自己处理缩放 → 负担很重
多显示器场景：
macOS：每块屏幕独立维护自己的逻辑坐标系，窗口跨屏时系统自动处理转换，开发者无感知
Windows：不同DPI的显示器之间移动窗口，应用需要自己响应DPI变化事件，否则在副屏上显示错误大小
总结：
macOS 是自上而下：先定义好逻辑世界，物理屏幕去适配它。
Windows 是自下而上：先有物理屏幕，再用缩放去补救。
以下内容以实际设备为例进行验证
MacOS缩放原理
MacOS为了解决不同尺寸不同分辨率的显示器在显示效果上的差异，提出了逻辑分辨率。UI的物理大小是由逻辑分辨率和屏幕尺寸共同决定的，与显示器分辨率无关。逻辑分辨率是提供给开发者使用的，开发者只需要根据pt设计UI界面（Apple官方提供了不同部件推荐的pt大小）并提供矢量图或多倍图@1x/@2x/@3x资源，最终显示器的呈现由MacOS自动缩放。至于每pt的实际物理大小是以不同设备观看距离确定最佳逻辑PPI决定的：
| 设备 | 典型观看距离 | 最佳逻辑PPI | 实际物理PPI | HiDPI倍率 |
|---|---|---|---|---|
| iPhone | ~35cm | ~160 | 460（Pro） | 3× |
| iPad | ~50cm | ~130 | 264 | 2× |
| Mac 外置显示器 | ~60cm | ~109 | 218 | 2× |
| MacBook | ~55cm | ~127 | 254 | 2× |
Macbook验证
以14寸和16寸Macbook Pro为基准 数据来源
14寸：14.2 英寸 (对角线) ，初始分辨率 3024 x 1964 (254 ppi)
16寸：16.2 英寸 (对角线) ，初始分辨率 3456 x 2234 (254 ppi)
\[对角线像素 = \sqrt{(水平像素)^2 + (垂直像素)^2}\]14寸对角线分辨率: $\sqrt{3024^2 + 1964^2} \approx 3606$
16寸对角线分辨率: $\sqrt{3456^2 + 2234^2} \approx 4115$
因为ppi高于160会被MacOS认定为高刷屏，会启动hidpi，默认的放大倍数scale=2，并且满足完美的放大整数倍，所以他们的逻辑分辨率是初始分辨率的一半。
14寸逻辑分辨率（pt）: 1512 × 982（3024/2 × 1964/2）
16寸逻辑分辨率（pt）: 1728 × 1117（3456/2 × 2234/2）
14寸对角线逻辑分辨率:$\sqrt{1512^2 + 982^2} \approx 1803$
16寸对角线逻辑分辨率: $\sqrt{1728^2 + 1117^2} \approx 2058$
因为软件开发者在设计软件大小的时候使用的是pt，pt也就是逻辑分辨率，比如一个(800pt x 600pt)的软件会被显示在 (1512pt × 982pt) 或 (1728pt × 1117pt) 逻辑分辨率的屏幕内。
所以1pt在14寸Macbook pro中的物理大小就是屏幕的长度 / 屏幕的逻辑分辨率 (严格来说应该分别计算宽和高，这里就用对角线替代了)
\[len(1pt) = \frac{14.2 inch}{1803pt} \approx 0.007876 (inch / pt)\]同理，1pt在16寸Macbook pro中的物理大小为
\[len(1pt) = \frac{16.2inch}{2058pt} \approx 0.007872(inch/pt)\]到此，得出对于Macbook Pro的UI开发基准为 每1pt对应的物理大小是0.008英寸左右，这也验证了上表中Macbook最佳的逻辑PPI为127,计算每pt的物理大小为$\frac{1}{127} \approx 0.0079$，两者是相同的。
（当然可以直接计算Macbook的逻辑PPI进行验证，此处计算出每pt的物理大小是为了让读者有一个直观的理解，这个每pt物理大小是观众可以直接观察到的）
外置显示器验证
Apple还推出了Stuido Display 和 Pro Display XDR:
| Studio Display | Pro Display XDR | |
|---|---|---|
| 尺寸 对角线（inch） | 27 inch | 32 inch |
| 实际分辨率 | 5120 x 2880 (5K) | 6016 x 3384 (6k) |
| ppi | 218 | 218 |
| 逻辑分辨率 | 2560 x 1440 (2K) | 3008 × 1692 |
按照Macbook的计算公式，可以得出这两款显示器中1pt对应的物理大小：
\[\begin{aligned} Studio\_27\_len(1pt) &= \frac{27inch}{\sqrt{2560^2 + 1440^2 }pt} \approx 0.009192 inch/pt \\ Pro\_32\_len(1pt) &= \frac{32inch}{\sqrt{3008^2 + 1692^2}pt} \approx 0.009694 inch/pt \end{aligned}\]计算实际每1pt对应的物理大小约为 0.0095。上表中外置显示器最佳的逻辑PPI为109,计算每pt的物理大小为$\frac{1}{109} \approx 0.009174$，两者是相同的。
HiDPI流程示例
macOS 的 HiDPI（High Dots Per Inch）是一种高分辨率显示技术，旨在在保持界面元素物理尺寸合理的同时，提升屏幕内容的清晰度和细节表现。当DPI过高时，会导致程序界面变小，为了给用户提供一个合适UI物理尺寸，需要将UI进行缩放。HiDPI提供了一套自动处理的流程，用户和开发者只需要关注逻辑分辨率即可，实际的缩放由MacOS控制。
- 首先操作系统以逻辑分辨率计算应用程序界面
- 按照逻辑分辨率放大后的分辨率（渲染分辨率）进行渲染（整数倍如2x,3x）
- 将渲染分辨率再压缩到显示器的实际分辨率（如果渲染分辨率与显示器分辨率相同则直接呈现）
只有显示器的DPI>160或者很高的时候才会主动开启HiDPI，因为HiDPI本身就是针对高分辨率显示器准备的。
整数倍缩放
以27寸4K(3840 x 2160)和27寸5K(5120 x 2880)为例：
整数缩放可获得最好的缩放效果，这里选择缩放比例scale=2，以27寸4K(3840 x 2160)选择1920x1080的逻辑分辨率，27寸5K(5120 x 2880)选择2560x1440的逻辑分辨率为例。
MacOS以逻辑分辨率计算程序界面(强调：只是UI布局按逻辑分辨率计算，并不是以逻辑分辨率进行渲染)
在27寸4K的1920x1080的逻辑分辨率下显示一个800x600pt的程序
在27寸5K的2560x1440的逻辑分辨率下显示一个800x600pt的程序
在屏幕尺寸一样（同27寸）的情况下，明显2560x1440下的800x600pt的程序会显得更小。
将逻辑分辨率进行放大到渲染分辨率，宽高放大两倍相当于1个像素点变为4(2x2)个像素点(此过程GPU才进行渲染，即每pt需要用2x2个像素来渲染)
27寸4K的1920x1080的逻辑分辨率放大为3840 x 2160，800x600pt实际以1600x1200px渲染(强调：UI的物理大小是没有变化的，因为在27寸的1920x1080画布上800x600的大小已经确定了)
27寸5K的2560x1440的逻辑分辨率放大为5120 x 2880，800x600pt实际以1600x1200px渲染
这个放大可以理解为 逻辑分辨率 与 显示器屏幕尺寸 决定了 UI的物理大小，但这个逻辑分辨率是低于显示器的实际分辨率的，如果直接用逻辑分辨率渲染对显示器来说是浪费，所以首先放大逻辑分辨率，将放大后的渲染分辨率映射到显示器的物理分辨率上。
将放大后渲染分辨率的再压缩到显示器的物理分辨率(如果两者相同直接呈现不需要压缩)
以上两个例子27寸4K的1920x1080的逻辑分辨率放大为3840 x 2160和27寸5K的2560x1440的逻辑分辨率放大为5120 x 2880都是放大到了显示器的物理分辨率，直接交给显示器呈现即可，不需要压缩，不会增加GPU负担。
最后计算一下 27寸4K(3840 x 2160)以1920x1080的逻辑分辨率 和 27寸5K(5120 x 2880)以2560x1440的逻辑分辨率 的每pt对应的物理大小：
\[\begin{aligned} 27\_4K\_len(1pt) &= \frac{27inch}{\sqrt{1920^2 + 1080^2}pt} \approx 0.012257 (inch/pt) \\ 27\_5K\_len(1pt) &= \frac{27inch}{\sqrt{2560^2 + 1440^2}pt} \approx 0.009192 (inch/pt) \end{aligned}\]27寸4K(3840 x 2160)以1920x1080的逻辑分辨率 会显示的略微偏大，而27寸5K(5120 x 2880)以2560x1440的逻辑分辨率 的显示比较合适，接近外置显示器的$\frac{1}{109} \approx 0.009174$。
图示总结：
- 屏幕尺寸 和 逻辑分辨率 共同决定UI大小
- 虽然27寸2K(原生渲染)与27寸5K(逻辑分辨率2K)中UI大小是一致的，但渲染分辨率相差4倍，27寸2K的1个像素在27寸5K中用4个像素表示
- 对于开发者，只需要设计程序大小为xx pt（需要在基准显示器上，如Macbook Pro），对于不同显示器显示大小由MacOS决定。例如：应用程序的大小设计为 800pt x 600pt（在Macbook Pro为合适大小），不同显示器会根据HiDPI进行缩放。
- MacOS会提供一系列逻辑分辨率供用户选择，比如 1920x1080,2560x1440等，实际上就是对应的1920ptx1080pt,2560ptx1440pt，比如一个800ptx600pt的应用，会占据1920x1080屏幕宽度的41%，会占据2560x1440屏幕宽度的31% (800/1920 = 0.41, 800/2560 = 0.31)
- 但MacOS的最佳的逻辑分辨率只与显示器屏幕的大小有关，当显示器屏幕大小一定时，最佳的逻辑分辨率就已经确定了（因为最佳PPI只与眼睛到屏幕的距离有关，是一个定值）。
非整数倍缩放
下面给一个非整数倍缩放，以27寸4K(3840 x 2160)以2560x1440的逻辑分辨率为例，首先以整数倍2倍放大，2560 x 1440放大为5120 x 2880，但显示器的实际分辨率为3840 x 2160，不足以显示5120 x 2880，所以要把5120 x 2880压缩到3840 x 2160再显示(这个压缩过程会导致画面模糊并增加GPU负担，这也是推荐整数倍缩放的原因)。但27寸显示器以2560 x 1440的逻辑分辨率每pt对应的物理大小就是0.009192inch，UI的物理大小会更加合适。
根据上面的计算，给出针对MacOS外接显示器的配置推荐：
| 显示器尺寸 | 最舒服逻辑分辨率 | 理想物理分辨率 |
|---|---|---|
| 24寸 | 1920×1080 | 3840×2160 (4K) |
| 27寸 | 2560×1440 | 5120×2880 (5K) |
| 32寸 | 3008×1692 | 6016×3384 (6K) |
注：上表中的最舒服逻辑分辨率是针对目前市面上常用的显示器分辨率（如1080p，2K，4K, 5K, 6K）中最佳的分辨率。
计算24寸，27寸，32寸在市面上常见分辨率中比较合适的逻辑分辨率：
\[\begin{aligned} 24\_len(1pt) &= \frac{24inch}{\sqrt{1920^2 + 1080^2}pt} \approx 0.010895 (inch/pt) \\ 27\_len(1pt) &= \frac{27inch}{\sqrt{2560^2 + 1440^2}pt} \approx 0.009193 (inch/pt) \\ 32\_len(1pt) &= \frac{32inch}{\sqrt{3008^2 + 1692^2}pt} \approx 0.009272(inch/pt) \end{aligned}\]注：外置显示器的最佳len(1pt)约为0.009(inch/pt)，。
注：上面的缩放倍数都是以2倍进行的缩放，但按照HiDPI的设计，也可以进行3x,4x等整数倍的缩放，比如24寸的逻辑分辨率是1920x1080，但24寸显示器的分辨率是5760x3240，此时MacOS会选择3倍缩放，但目前来说24寸显示器不会达到这么高的分辨率，一般3倍会用在手机上。
总结
HiDPI的设计目标是由 逻辑分辨率 + 屏幕尺寸 决定UI的实际物理大小， 显示器物理分辨率 决定UI的清晰度细腻程度。Window系统的是将UI实际物理大小和细腻程度都交给了DPI，以96DPI为100%缩放基准设计的。
MacOS是HiDPI整数倍缩放后压缩到目标分辨率，Window是直接选择不同缩放比例进行缩放
MacOS选择外置显示器，只需要选择显示器的PPI是110（外置显示器最佳的逻辑PPI）的整数倍即可。
常见困惑
看到这里相信不少人会出现这样一个困惑：
- 对于27寸4K的显示器，Window系统是可以直接选择1080p输出，而MacOS以1080p的逻辑分辨率输出到4K上。两者都经历了放大过程，Window通过GPU输出1080p的画面在显示器上放大两倍呈现，MacOS也是先用1080p的逻辑分辨率布局然后在通过HiDPI放大两倍呈现。两者效果为什么不同？
MacOS 的实际工作流程
- 逻辑分辨率（Logical Resolution）：1920×1080
- 这是应用程序“看到”的坐标空间，UI 布局按此计算。
- Backing Scale Factor（缩放因子）：2.0
- 系统告诉 GPU 和 App：每个逻辑像素要用 2×2 = 4 个物理像素来绘制。
- 实际渲染分辨率（Backing Store）：3840×2160
- 所有 UI 元素（文字、图标、窗口边框）都以 4K 原生精度渲染！
- 最终输出：直接以 3840×2160 输出到显示器，无任何拉伸或插值。
结果：UI 大小和 1080p 一样，但清晰度是 4K 级别。
Windows 1080p输出的实际工作流程
- 系统分辨率设为 1920×1080 → 整个桌面合成器、所有应用都按 1080p 渲染。
- 显卡/显示器将 1080p 信号拉伸到 4K 物理像素 / 甚至是直接1080p直接映射到4K显示器上 → 使用插值算法（如双线性）填充缺失像素。
MacOS的逻辑分辨率只是用来UI布局使用的，真正UI渲染时仍然采用放大后的渲染分辨率来渲染。而Window中如果选择低分辨率，UI布局和渲染都是采用的1080p，最后强行拉伸到了4K。
在 Windows 上，一定使用显示器的原生分辨率 + DPI 缩放来达到合适UI大小，不要在Window中选择低于显示器物理分辨率的值，会浪费硬件资源还会导致画面模糊。
对于27寸4K显示器，Window中直接选择 4K + 200% ：4K+200% 的 UI 是在4K分辨率下进行渲染的，在渲染过程中选择了200%的资源（如@2x.png)，UI大小看起来像在27寸1080p的分辨率下（即逻辑分辨率）。
Windows 的 4K + 200% 缩放 和 macOS 的 1920×1080 逻辑分辨率（HiDPI）的对比
| 项目 | Windows：4K + 200% 缩放 | macOS：1920×1080 HiDPI |
|---|---|---|
| 物理分辨率 | 3840×2160（原生） | 3840×2160（原生） |
| 逻辑分辨率（App 看到的） | 1920×1080（通过 DPI 缩放抽象） | 1920×1080（通过 backing scale=2 抽象） |
| 缩放因子（Scale Factor） | 2.0（200%） | 2.0 |
| 实际渲染缓冲区大小 | 通常为 3840×2160（对 DPI-aware 应用） | 总是 3840×2160（或等效高 DPI buffer） |
| 最终输出 | 原生 4K，无拉伸 | 原生 4K，无拉伸 |
共同点：两者都以 2× 物理像素渲染每个逻辑 UI 单元，因此理论上清晰度一致(前提是Window应用已经适配高分辨)。
但对于非整数倍缩放
比如显示器分辨率为3840×2160(4K)，Window选择150%缩放(以96 DPI为基准，缩放150%后为144 DPI)，MacOS选择逻辑分辨率为2560x1440。此情况下，MacOS会多一步降采样。
| 维度 | Windows 150% (现代应用) | macOS 2560×1440 HiDPI |
|---|---|---|
| 应用看到的 Scale Factor | 1.5x (144 DPI) | 2x (@2x) MacOS只支持整数倍 |
| 应用实际渲染分辨率 | 3840 × 2160 (等于物理像素) | 5120 × 2880 (大于物理像素) |
| 是否有后处理缩放（降采样） | ❌ 无（点对点输出到物理像素） | ✅ 有（5120×2880 → 3840×2160） |
| GPU 负载 | 较低（仅渲染物理像素量） | 较高（渲染超物理像素 + 降采样） |
| 文字/UI 锐度 | 原生 1.5x 光栅化，清晰 | 2x 渲染后降采样，理论上略软于原生，但因 PPI 高肉眼难辨 |
| 旧应用兼容性 | 模糊（DWM 拉伸） | 依然清晰（因为旧应用也被迫走 2x 管线） |
| 多屏混合体验 | 窗口跨屏时可能触发重排/闪烁 | 无缝过渡 |