显示器分辨率和缩放
使用显示器时，很多人都s会遇到字体或应用界面太大太小的问题，比如正在使用27寸2K显示器，更换了27寸4K显示器后应用界面都会变小，需要使用系统提供的缩放功能来放大。
Window和MacOS使用的不同的方法来解决高分辨率显示器带来的UI不适配的问题。
Window
Window为了解决不同尺寸不同分辨率的显示器在显示效果上的差异，引进了缩放功能，用户可以在不同的显示器上尝试不同的缩放来达到合适的UI呈现。比如一个800px x 600px的应用程序，在相同尺寸的显示器下，在1920x1080分辨率的显示器上占据的面积是$\frac{800 \times 600}{1920 \times 1080} \approx 23\%$，而在2560x1440分辨率的显示器上占据的面积是$\frac{800 \times 600}{2560 \times 1440} \approx 13\%$。因为显示器尺寸相同，这导致应用程序在高分辨率下变小了。为了能有统一的UI呈现，需要将2560x1440分辨率的显示器进行放大$\frac{2560}{1920} \approx 133\%$
Window是根据PPI(Pixels Per Inch)来解决缩放问题。PPI即每英寸的像素量，PPI约高显示效果约细腻。
UI物理大小的基准
由于历史原因，Window以96DPI的100%缩放为基准设计UI。DPI是渲染时像素数，即渲染时每英寸的像素量，反过来其是就是每个像素是几物理英寸，这与下面要介绍的MacOS的每pt的物理英寸大小很相似，但两者的设计原理不同。DPI是历史遗留，96DPI就是当时设置的标准。
| DPI | 缩放大小 |
|---|---|
| 96 | 100% |
| 120 | 125% |
| 144 | 150% |
| 192 | 200% |
软件开发这需要对系统提供缩放比例进行适配，对于未适配的软件会插值取样后强行缩放，会产生模糊。
有了DPI(渲染时每英寸的像素量)为基准，为了让UI大小更加合适，需要让显示器的PPI约接近DPI则UI大小约合适。即满足 \(\frac{dpi}{ppi} \approx 1\)
24寸1080p(1920x1080)
通过计算可得24寸(1920x1080)的PPI=93,所以$\frac{dpi}{ppi} = \frac{96}{93} \approx 1.03$，非常接近1,则只需要100%缩放即可。
24寸2K(2560×1440)
24寸2K(2560×1440)的ppi=122，其最佳缩放比例为$\frac{dpi}{ppi} = \frac{96*125\%}{122} \approx 0.98$，非常接近1,需要125%缩放。
24寸4K(3840x2160)
24寸4K(3840x2160)的ppi=184，其最佳缩放比例为$\frac{dpi}{ppi} = \frac{96*200\%}{184} \approx 1.04$，非常接近1,需要200%缩放。
通过上述三台24寸的显示器得出，24寸最佳的分辨率是1080p或者4K（保证整数倍的缩放）。
27寸4K(3840x2160)
通过计算得27寸(3840x2160)的PPI=163:
- 按照100%缩放，$\frac{dpi}{ppi} = \frac{96}{163} \approx 0.58$，明显小于1,会导致UI变小
- 按照175%缩放，$\frac{dpi}{ppi} = \frac{96 \times 175\%}{163} = \frac{168}{163} \approx 1.03$，非常接近1,所以按照175%最佳
- 按照200%缩放，$\frac{dpi}{ppi} = \frac{96 \times 200\%}{163} = \frac{192}{163} \approx 1.18$，大于1,会导致UI变大
27寸5K(5120 x 2880)
通过计算得27寸(5120 x 2880)的PPI=217
- 按照100%缩放，$\frac{dpi}{ppi} = \frac{96}{217} \approx 0.44$，明显小于1，会导致UI变小
- 按照200%缩放，$\frac{dpi}{ppi} = \frac{96 \times 200\%}{217} = \frac{192}{216} \approx 0.88$，也小于1,导致UI变小，不过可以忍受
- 按照225%缩放，$\frac{dpi}{ppi} = \frac{96 \times 225\%}{217} = \frac{192}{216} \approx 0.99$，非常接近1,所以按照225%最佳
通过上面两个27寸的常规分辨率得出并没有Windows平台最佳的分辨率（整数倍缩放最佳），这也解释了Surface Studio那台显示器非常规的分辨率。
GDI缩放
Window还会提供GDI缩放，过程与MacOS的HiDPI类似，先整数倍缩放，然后再压缩到显示器的分辨率。
MacOS
MacOS为了解决不同尺寸不同分辨率的显示器在显示效果上的差异，提出了逻辑分辨率。UI的物理大小是由逻辑分辨率和屏幕尺寸共同决定的，与显示器分辨率无关。逻辑分辨率是提供给开发者使用的，开发者并不需要关心UI最终渲染在不同显示器上有多大、分辨率是多少，开发者只需要根据pt设计UI界面并提供矢量图或多倍图@1x/@2x/@3x资源，最终显示器的呈现由MacOS自动缩放。至于每pt的实际物理大小是以14寸和16寸Macbook Pro为基准，针对其他不同的显示器，MacOS会通过缩放尽量让UI表现与14寸和16寸Macbook Pro的基准相同。
UI物理大小的基准
以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，并且满足完美的放大整数倍，所以他们的逻辑分辨率是初始分辨率的一半。（后面会讲解HiDPI，目前只需要知道逻辑分辨率*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英寸左右，这样的大小会让UI大小适中，符合开发者想让用户看到的UI大小（因为开发者是以Macbook Pro为开发参照的）
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 |
按照上面的提示，逻辑分辨率*2=屏幕实际分辨率可以达到最好的效果（后面会解释HiDPI整数倍缩放效果最好）可以推出对应的逻辑分辨率。
按照Macbook的计算公式，可以得出这两款显示器中1pt对应的物理大小： \(Studio\_27\_len(1pt) = \frac{27inch}{\sqrt{2560^2 + 1440^2 }pt} \approx 0.009192 inch/pt \\ Pro\_32\_len(1pt) = \frac{32inch}{\sqrt{2008^2 + 1692^2}pt} \approx 0.012187 inch/pt\) 可以看到每1pt对应的物理大小在[0.008inch/pt-0.012inch/pt]范围内，最合适的大小应该是接近0.008inch/pt
到此为止，简单了解了MacOS中UI物理大小（即在显示器上显示的实际大小）是与逻辑分辨率和显示器屏幕尺寸相关的。屏幕尺寸越大，UI物理大小越大；逻辑分辨率越高，UI物理大小越小。
MacOS这样的设计巧妙的避开了显示器的实际分辨率以及PPI，通过MacOS自动缩放来适应不同分辨率的显示器。
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寸5K的2560x1440的逻辑分辨率放大为5120 x 2880，800x600pt的程序变为1600x1200px
这个放大可以理解为 逻辑分辨率 与 显示器屏幕尺寸 决定了 UI的物理大小，但这个逻辑分辨率是低于显示器的实际分辨率的，如果直接用逻辑分辨率渲染对显示器来说是浪费，所以首先放大逻辑分辨率，将放大后的图像映射到显示器的实际分辨率上。
将放大后渲染分辨率的再压缩到显示器的实际分辨率(如果两者相同直接呈现不需要压缩)
以上两个例子27寸4K的1920x1080的逻辑分辨率放大为3840 x 2160和27寸5K的2560x1440的逻辑分辨率放大为5120 x 2880都是放大到了显示器的实际分辨率，直接交给显示器呈现即可，不需要压缩，所以这种模式下是最好的显示效果。
最后计算一下 27寸4K(3840 x 2160)以1920x1080的逻辑分辨率 和 27寸5K(5120 x 2880)以2560x1440的逻辑分辨率 的每pt对应的物理大小： \(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)\) 对于在完美的缩放情况下，27寸4K(3840 x 2160)以1920x1080的逻辑分辨率 会显示的略微偏大，而27寸5K(5120 x 2880)以2560x1440的逻辑分辨率 的显示比较合适，接近0.008inch/pt。
图示总结：
- 屏幕尺寸 和 逻辑分辨率 共同决定UI大小
- 虽然27寸2K(原生渲染)与27寸5K(逻辑分辨率2K)中UI大小是一致的，但渲染分辨率相差4倍，27寸2K的1个像素在27寸5K中用4个像素表示
- 对于开发者，只需要设计程序大小为xx pt，实际显示大小由MacOS决定。例如：应用程序的大小为 800pt x 600pt
- MacOS会提供一系列逻辑分辨率供用户选择，比如 1920x1080,2560x1440等，实际上就是对应的1920ptx1080pt,2560ptx1440pt，比如一个800ptx600pt的应用，会占据1920x1080屏幕宽度的41%，会占据2560x1440屏幕宽度的31% (800/1920 = 0.41, 800/2560 = 0.31)
- 但MacOS的最佳的逻辑分辨率只与显示器屏幕的大小有关，当显示器屏幕大小一定时，最佳的逻辑分辨率就已经确定了(根据14寸或16寸的Macbook为基准)。所以将最佳逻辑分辨率与显示器屏幕结合，就能计算出UI的物理大小，每pt占据的物理大小在任何分辨率任何尺寸的显示器上都是一样的(或者相似，越大的显示器可以让字体稍大)，都接近0.008inch/pt
非整数倍缩放
下面给一个非整数倍缩放，以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寸4K以2560 x 1440的逻辑分辨率每pt对应的物理大小就是0.009192inch，UI的物理大小会更加合适。
根据上面的计算，给出针对MacOS外接显示器的配置推荐：
| 24寸 | 27寸 | 32寸 |
|---|---|---|
| 1920x1080 (不开启HiDPI) | 2560x1440 (不开启HiDPI) | 3840x2160 (不开启HiDPI) |
| 3840x2160 (逻辑分辨率: 1920x1080) | 5120x2880 (逻辑分辨率: 2560x1440) | 6016x3384(逻辑分辨率: 3008x1692) |
| 1080p | 1920x1080 |
| 2K | 2560x1440 |
| 4K | 3840x2160 |
| 5K | 5120x2880 |
| 6K | 6016x3384 |
计算24寸，27寸，32寸在市面上常见的比较合适的逻辑分辨率，最佳的len(pt)约为0.008(inch/pt) \(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{3840^2 + 2160^2}pt} \approx 0.007265(inch/pt)\) 注：上面的缩放倍数都是以2倍进行的缩放，但按照HiDPI的设计，也可以进行3x,4x等整数倍的缩放，比如24寸的逻辑分辨率是1920x1080，但24寸显示器的分辨率是5760x3240，此时MacOS会选择3倍缩放，但目前来说24寸显示器不会达到这么高的分辨率，一般3倍会用在手机上。
总结
HiDPI的设计目标是由 逻辑分辨率 + 屏幕尺寸 决定UI的实际物理大小， 实际分辨率 决定UI的清晰度细腻程度。Window系统的是将UI实际物理大小和细腻程度都交给了DPI，以96DPI的100%缩放为基准设计的。
对于MacOS选择显示器，需要先找出对应屏幕大小的比较适合的逻辑分辨率，然后显示器的实际分辨率最好为该逻辑分辨率的整数倍（一般是2倍），不是整数倍就会牵扯到压缩问题，会出现图像模糊并增加GPU压力。
困惑
看到这里相信不少人会出现这样一个困惑：
- 对于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 实际工作流程：
- 系统分辨率设为 1920×1080 → 整个桌面合成器、所有应用都按 1080p 渲染。
- 显卡/显示器将 1080p 信号拉伸到 4K 物理像素 → 使用插值算法（如双线性）填充缺失像素。
综上可以得出：MacOS的逻辑分辨率只是用来UI布局使用的，真正UI渲染时仍然采用放大后的渲染分辨率来渲染。而Window中UI布局和渲染都是采用的1080p，最后强行拉伸到了4K。
在 Windows 上，永远优先使用显示器的原生分辨率 + DPI 缩放来达到合适UI大小。
4K + 200% 是把 1080p 的画面放大两倍是不完全正确：4K+200% 的 UI 是在高分辨率下按“逻辑像素”绘制（每逻辑像素映射 2×2 物理像素），不是简单的把 1080p 的位图插值放大；如果软件支持 HiDPI，绘制是高分辨率的，细节是原生的。
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 单元，因此理论上清晰度一致(前提是应用都已经适配高分辨)。