最近iPhone15系新品已经发布，很快就要正式开始出货了。

出乎意料的是，今年iPhone15的屏幕分辨率居然改了，和 iPhone14pro、15pro 用了相同的尺寸（2556 * 1179 , 460ppi），意味着未来苹果阵营的主力机型尺寸要统一了，而过去我们主要使用的iOS画布分辨率也成为过去式。

iOS 以后设计要开始用新分辨率了，也趁这个机会，来做一篇关于 UI 设计中画布创建尺寸的汇总，一次性解决你们所有画布创建中的疑问和难题。

很多人以为的画布创建参数就是根据设备、系统的类型，列个清单就行了，以后跟着这个清单创建即可。

想起来很美好，但却难以实现，原因是画布会受到很多外部条件的影响，即使是相同的设备和系统，都可能在不同的项目场景中使用不同的分辨率。

专业的设计师必然会根据实际的场景做分析，决定使用什么分辨率创建画布，而不是死记硬背直接照搬。

所以，我们先理解画布的创建受哪些条件影响，以及应该遵循什么原则：

• 设备的物理和逻辑分辨率
• 系统规范的分辨率定义
• 适配和响应式原则的兼顾
• 目标用户群体设备的定位
• 设备显示方案的特性
• 团队的工作流和历史包袱

1.1 设备的物理和逻辑分辨率

第一个概念，就是分辨率本身包含两个层级，物理分辨率和逻辑分辨率。

物理分辨率指的是显示器硬件上搭载的像素数，比如 iPhone15pro的分辨率2556*1179，就是在这个6.1寸的屏幕中，垂直方向有2556个像素点，水平方向有1179个像素点。

这些像素点是物理单元，在制造过程中就集成到屏幕中，无法被更改。所以物理的分辨率是由屏幕的参数决定的，每台设备的物理分辨率是固定的。

而逻辑分辨率，则是软件在渲染到屏幕上时应用的分辨率。比如你在电脑上打开分辨率设置页面，可以更改屏幕的分辨率，从而影响显示的效果，这就叫逻辑分辨率。

以移动端开发为代表的平台，从代码设计的层面上就全部避开对物理分辨率的定义，无论在 iOS 或者安卓开发中，都是使用逻辑单位（PT、DP等）而不是像素单位。而这些逻辑单位也是矢量单位，所以在UI类矢量设计软件中，使用的画布分辨率和官方屏幕硬件的分辨率不一样。

系统会根据特定的算法，对逻辑分辨率创建的内容进行解析和渲染，作用到显示器上。所以有了 1x、2x、3x 的倍率概念，意思就是系统根据显示器的分辨率密度，对逻辑分辨率的数值进行对应比例的放大。

比如iPhone15 的逻辑分辨率是 393*852，使用了 3x 的倍率，就成为 2556 * 1179 像素。

而以 PS 为首的位图软件则不具备相应的矢量的特性，所以无法使用逻辑分辨率，而使用物理分辨率来创建画布。

同理，很多电脑使用的 4K 屏，仅仅是提升显示的精度，并不是容纳的内容直接达到4K级，而是使用更小的逻辑分辨率进行显示，确保内容是可以看清的。所以 Windows 有个界面放大的设置，本质上就是减少逻辑分辨率的尺寸，让内容可以显示得更大。

所以，在UI的设计中我们创建的画布可以直接理解成是基于逻辑分辨率创建画布，而我们必须要提前搞清楚的，就是针对指定设备设计过程中，逻辑分辨率和物理分辨率之间的换算关系，是1：1，还是1：N。

1.2 系统规范的分辨率定义

前面已经说过，逻辑分辨率和物理分辨率是两码事。但是逻辑分辨率麻烦就麻烦在 “逻辑” 上，只要系统开发者能搭建出一套合理的逻辑，那么像怎么换算成物理分辨率都可以。

所以当我们针对一些特定的系统进行设计时，开发者往往会给出指定的逻辑分辨率尺寸，且不对标固定的屏幕或硬件。

最典型的就是小程序，它之前指定的基础画布是 750*1334 rpx，这是一个小程序特有的单位，我们可以选择直接创建这个尺寸的画布，也可以使用 375 * 667 进行设计后面再转换成 2x 格式输出或标注……而rpx这个单位就会自动换算适配到不同屏幕中去（和iOS和Android不同，暂不解释）。

其它的开放平台如支付宝的、智能家居的、私有云系统等，都可能包含类似的画布指定参数，在这样的前提下，就直接使用官方指定的数值即可。

而没有官方要求的场景，则需要进一步根据后面的条件判断。

1.3 适配和响应式原则的兼顾

为什么很多界面的设计无法获得官方指定的尺寸，原因就是要兼顾的情况太多，比如网页或者桌面端的程序，要适配各种各样的桌面分辨率，界面的窗口还要支持各种缩放。

所以，只要不是只在同一种规格屏幕上运行，且不变更窗口大小的话，那么就一定要考虑软件的界面适配问题，要确保它们在多种环境下都能正常显示。也就是界面的显示尺寸不是固定死的，而是 “活的”，会根据一定的逻辑进行缩放。

这些缩放的方法包括等比缩放、自适应、响应式等方案。具体的不在这里介绍，可以看我之前解释响应式的干货分享。

文章链接：B 端响应式界面应该怎么做？

而自适应、响应式的应用逻辑里，有个不可逆的特征，就是从小的尺寸往大的适配容易，而从大的尺寸往小的适配难。

也就是如果你做了一个800px宽且填满内容的页面，要放大到2560px 适配起来是很容易的，而如果反过来，则会出现一堆的问题。因为简单的自适应规则是不可能在缩小画布的情况下还容纳那么多信息的，就必然要通过更复杂的规则对界面布局做调整，比如换行、折叠、隐藏等等。

尤其在B端领域，很多前端摆烂完的结果，就是大屏幕显示还正常，一缩放就直接崩盘了。比如下图，是前面改版案例中的原页面，在1920px、1280px宽下显示的效果，也就是如果用户用小屏幕上网本访问，接近没法用的状态。

文章链接：实例改版 | 一次完整的交互优化可以这么做

所以在面对这种尺寸不会固定，需要做多设备适配的场景中，官方没办法强制你用某个尺寸（还有别的因素），且不是适合直接用较大的尺寸去设计。

通常会选择中等偏小的尺寸开始设计，等于从一开始就在考虑小尺寸的兼容，那么进行放大的适配就非常轻松，大幅度降低出错的概率。

也强调一点，如果在这种场景中，领导还是程序员没有任何理由的让你用 1080p的画布做设计，只能有一个可能，就是他们对适配兼容性和画布的关系缺乏正确的理解。按这个尺寸做没问题，只要确认窗口缩小时的适配出问题，锅由谁背即可。

1.4 目标用群体设备的定位

这个意思就是搞清楚项目面向的客户端设备，屏幕规格是不是固定的。虽然有些系统和设备可以产生很多不同的分辨率，但在一些特定情况下可以人为做出统一，拒绝多样性的可能。

比如做门店的定制平板，如果定制的设备规格完全一样，只定ipad9，那么其它ipad什么尺寸就暂时不需要操心了。或者给客服中心定制了相同的台式机和显示器，所有客服用的都是一样的显示器且全屏运行，那么其它设备和分辨率也不需要考虑了。

所以前期的设计需求分析中，一定要搞清楚是不是只面向一种规格的屏幕运行，如果是得话，它的逻辑和物理分辨率换算的规格是什么样的。

1.5 设备显示方案的限制

设备显示方案指的是怎么把你的UI界面给展示出来的方案，这个听起来比较拗口，最常见的应用场景就是在大屏的展示。

大屏本身有很多方案，单投影、多投影组合、大型LED定制设备、多台显示器拼接，不同的显示方都会影响项目的前端开发方案。

并且，不同的显示方案会构成不同的拓扑关系，比如电脑要通过显卡视频端口输出到分配器，分配器可能再转接更多的分配器后再实现画面的拼接。

在这个拓扑体系中，有一系列的问题要探究，比如显卡视频口输出的分辨率上限（高端显卡支持8k120，低端可能只支持4k30），分配器的支持上限，拼接屏幕的分辨率规格等。

拼接大屏的显示分辨率不可能是把所有显示器的分辨率集合起来显示，比如拼了12个4k的屏幕，如果完整显示的话像素总量就是 4k*12，没有任何显卡可以支持这种分辨率的输出。所以必须把它们整合成一个更小的画布分辨率进行显示，而这个更小的分辨率上限就是拓扑关系中涉及到的设备的上限。

而具体的长宽分辨率参数，也不一定是主流的数值，比如720、1080、2k、4k这种，因为很多大屏的比例很奇葩，所以分辨率一定是自定义的，而自定义的分辨率逻辑像素总量也不能超过前面的上限。

这样解释下来新手可能会看晕，但这是做大屏必须掌握的能力。虽然理论上设备的供应商会给一些基本的解决方案，和给你个可用的分辨率参数，但一些复杂的场景里，必须由设计师根据对项目的理解定义（比如使用的3D引擎在高分辨率下的运行效率）。

总结起来，就是类似大屏这种多屏幕组合的显示场景中，每个项目的情况完全不同，设计师要自己定义画布的逻辑分辨率，用于正常显示在最终的显示设备中。

1.6 团队的工作流和历史包袱

这点本来不是特别想讲，但想了下似乎是绕不过去的话题，那还是得谈一谈。

前面举出的例子都是基于合理的、有效的项目画布创建目标为准，而部分项目中并不会太关心你用的画布标准是不是正确的，或者说有其它的原因导致使用正确的画布比错误的画布成本还高。

比如还在用 PS 做界面而且不打算换软件的，且积累了不少源文件，那么你要动尺寸就得在每次调用过去的组件时全部手动修改一遍，以及要让其他同事全部更改自己的习惯。

类似的问题还有很多，就不多做解释。要强调的是，你要自己分的清楚当前画布的定义，是合理的，还仅仅是一种惯性依赖，因为改起来太麻烦所以宁愿用不合适的。

以上就是定义分辨率所需掌握的主要原则和要点，更细节的内容需要你们自己去查看相关资料做积累，包括像素的显示逻辑、显示信号输出、倍率转换原则等等，全都是作为专业 UI 设计师最最最最基础的知识点。

2.1 移动端APP画布制定

移动端目前主要的变化是 iPhone15也应用393宽的分辨率，390的设备开始慢慢进入淘汰阶段，所以不再像iPhone14时期还是推荐390宽作为APP界面创建标准。

2.2 小程序画布制定

小程序应用了 rpx 的自适应单位，会针对基础的画布进行比例缩放，来实现在不同手机屏幕的适配。而小程序不是只在手机上显示的，还可以在电脑端运行，进行特定的适配。

同时，官方文档内的描述从 375 变成了414……官方源文件内既有 375 的组件也有 414 的，主打一个混乱和抽象……

页面地址

2.3 Pad 端画布设置

Pad 的平板也包含 iOS 和Android （鸿蒙……），比较奇怪的是iOS 的尺寸，如果做苹果的平板没有制定设备，则根据官方的尺寸定义即可。

2.4 网页的画布设置

网页的设置包含定宽型战士网页和响应式类网页，以版心为准的单屏分辨率尺寸建议，包含高度中大致减去浏览器和系统栏的部分，单屏高度仅用于做屏高预判，实际设计超出一屏很正常，高度最终根据内容决定。

而响应式优先建议使用中尺寸进行设计，同时复杂的项目最好挑选2-3个页面输出3个尺寸的版本，用于和开发确认响应式逻辑的应用。

2.5 桌面端程序画布设置

桌面端的程序设计很难有标准的规则，这和程序类型有很大的关系，可以是腾讯柠檬这种小工具，也可以是类似 Adobe PS 这种专业软件。

但是同理，桌面端的软件更注重小屏幕尺寸的兼容，不像网页可以在浏览器左右滚动，所以没有外部影响的话建议最大做到 1280的尺寸。

2.6 大屏端画布设置

大屏端前面也说过，每个项目差异都很大，往往每个项目用的分辨率都不同，得设计师自己解决。

但这里还有个比较蛋疼且常见的场景，就是无法计算出具体分辨率的情况下，就要求先输出设计稿，那么我们就可以以 1080 高作为标准，根据空间的比例设置宽度。

比如 21：9 的宽高比，那么宽就是 1080 / 9 * 21 = 2560，画布的分辨率就是 2560 ：1080，要是连比例都没有，那就使用最基础的 1080P来完成。

2.7 定制化设备

最后就是纯定制化设备，这个就属于我完全没办法给出建议参数的类型，因为定制化的显示器尺寸和规格实现是太多了。

画布的定义需要设计师去和硬件供应商进行沟通，了解物理分辨率大小，以及判断显示场景下是否需要使用和物理分辨率不同的逻辑分辨率，再和团队讨论并最终确定。

结尾

以上就是关于画布定义中你们该了解的一切，希望你们看完了之后，可以忘记具体的数值，再每次项目设计前，去思考一遍项目面向的场景需要定义什么样的尺寸，并能和团队做出高质量的、有效的画布定义的沟通。

而不是针对固定场景就背一套数值用一辈子，这种不动脑子的做法实在是太外行了……

后面我会把尺寸的设计做成一份 PDF，整合更多的尺寸要素进来，大家有别的想要看到的内容可以在下面留言。

我们下篇再贱~~

Powered by Froala Editor