移动端开发尺寸规范

本文所讲的关键字：像素密度PPI;逻辑像素；物理像素（实际分辨率）；倍率；

像素密度Pixels per inch：每英寸长度上排列的像素点数量，1英寸是一个固定长度，等于2.54厘米，大约是食指最末端那根指节的长度。像素密度越高，代表屏幕显示效果越精细。Retina屏比普通屏清晰很多，就是因为它的像素密度翻了一倍。像素密度为120左右的屏幕为1dpi，160左右为mdpi，因为Android屏幕尺寸实在太多，分辨率高低跨度非常大，不像苹果只有那么几款固定设备、固定尺寸。所以Android把各种设备的像素密度划成了好几个范围区间，给不同范围的设备定义了不同的倍率，来保证显示效果相近。像素密度概念虽然重要，但用不着我们自己算，iOS与Android都帮我们算好了。

如图所示，像素密度在120左右的屏幕归为ldpi，160左右的归为mdpi，以此类推。这样，所有的Android屏幕都找到了自己的位置，并赋予了相应的倍率：

ldpi [0.75倍]

mdpi [1倍]

hdpi [1.5倍]

xhdpi [2倍]

xxhdpi [3倍]

xxxhdpi [4倍]

就目前市场状况而言，各种手机的分辨率可以这样粗略判断。虽然不全面，但至少在1年内都还有一定的参考意义：

ldpi 如今已绝迹，不用考虑

mdpi [320x480]（市场份额不足5%，新手机不会有这种倍率，屏幕通常都特别小）

hdpi [480x800、480x854、540x960]（早年的低端机，屏幕在3.5英寸档位；如今的低端机，屏幕在4.7-5.0英寸档位）

xhdpi [720x1280]（早年的中端机，屏幕在4.7-5.0英寸档位；如今的中低端机，屏幕在5.0-5.5英寸档位）

xxhdpi [1080x1920]（早年的高端机，如今的中高端机，屏幕通常都在5.0英寸以上）

xxxhdpi [1440x2560]（极少数2K屏手机，比如Google Nexus 6）

自然地，以1倍的mdpi作为基准。像素密度更高或者更低的设备，只需乘以相应的倍率，就能得到与基准倍率近似的显示效果。

不过需要注意的是，Android设备的逻辑像素尺寸并不统一。比如两种常见的屏幕480×800和1080×1920，它们分别属于hdpi和xxhdpi。除以各自倍率1.5倍和3倍，得到逻辑像素为320×533和360×640。很显然，后者更宽更高，能显示更多内容。所以，即使有倍率的存在，各种Android设备的显示效果仍然无法做到完全一致。

不难发现，真正决定显示效果的，是逻辑像素尺寸。为此，iOS和Android平台都定义了各自的逻辑像素单位。iOS的尺寸单位为pt，Android的尺寸单位为dp。说实话，两者其实是一回事。

单位之间的换算关系随倍率变化：

1倍：1pt=1dp=1px（mdpi、iPhone 3gs）

1.5倍：1pt=1dp=1.5px（hdpi）

2倍：1pt=1dp=2px（xhdpi、iPhone 4s/5/6）

3倍：1pt=1dp=3px（xxhdpi、iPhone 6）

4倍：1pt=1dp=4px（xxxhdpi）

单位决定了我们的思考方式。在设计和开发过程中，应该尽量使用逻辑像素尺寸来思考界面。设计Android应用时，有的设计师喜欢把画布设为1080×1920，有的喜欢设成720×1280。给出的界面元素尺寸就不统一了。Android的最小点击区域尺寸是48x48dp，这就意味着在xhdpi的设备上，按钮尺寸至少是96x96px。而在xxhdpi设备上，则是144x144px。

无论画布设成多大，我们设计的是基准倍率的界面样式，而且开发人员需要的单位都是逻辑像素。所以为了保证准确高效的沟通，双方都需要以逻辑像素尺寸来描述和理解界面，无论是在标注图还是在日常沟通中。不要再说“底部标签栏的高度是96像素，我是按照xhdpi做的”这样的话了。

Web怎么办

移动端页面的绝对单位仍然是px，至少代码里这么写，但它的道理也和app一样。由于像素密度是设备本身的固有属性，它会影响到设备中的所有应用，包括浏览器。前端技术可以善加利用设备的像素密度，只需一行代码，浏览器便会使用app的显示方式来渲染页面。根据像素密度，按相应倍率缩放。

以iPhone 5s为例，屏幕的分辨率是640×1136，倍率是2。浏览器会认为屏幕的分辨率是320×568，仍然是基准倍率的尺寸。所以在制作页面时，只需要按照基准倍率来就行了。无论什么样的屏幕，倍率是多少，都按逻辑像素尺寸来设计和开发页面。只不过在准备资源图的时候，需要准备2倍大小的图，通过代码把它缩成1倍大小显示，才能保证清晰。

物理分辨率与逻辑分辨率：这两者很容易混淆，下面举例说明：

众所周知，手机屏幕分辨率是手机的重要参数之一。

大家都知道移动端设备屏幕尺寸非常多，碎片化严重。尤其是Android，你会听到很多种分辨率：480×800, 480×854, 540×960, 720×1280, 1080×1920，而且还有传说中的2K屏、4K、5k等。近年来iPhone的碎片化也加剧了：640×960, 640×1136, 750×1334, 1242×2208。

解释一：俗话说物理分辨率是硬件所支持的，逻辑分辨率是软件可以达到的。

我们先来看看ios客户端的尺寸分辨率表：

物理尺寸是指屏幕的实际大小。大的屏幕同时必须要配备高分辨率，也就是在这个尺寸下可以显示多少个像素，显示的像素越多，可以表现的余地自然越大。

解释二：如同上图所对应的英文单词一样。

640*960、640*1136等这些都是物理尺寸或是物理分辨率。

而下面的320*480、320*568等这些都是逻辑分辨率或是逻辑尺寸。

解释三：从另外的角度来说：分辨率就是屏幕上横、纵的总象素点数。

如果我们设计的时候用单位px，可以说是物理分辨率尺寸。

如果我们设计的时候用单位pt，可以说是逻辑分辨率尺寸。

下面拿iphone 6 plus详细分析：

1、iPhone 6 Plus 的逻辑point分辨率用 360×640，也不是不可以，也即上面图表中的 iPhone 6+ (b)方案，那么 scale 用 @3x，最终像素分辨率 360×640@3x 正好是 1080×1920，完美1:1映射，无需缩放；但缺点就是：iPhone 6 Plus的逻辑pt分辨率 360×640 就会比 iPhone 6的 375×667 还低，这天理不容啊，一个Plus的大屏幕虽然很精细，但是可显示的实际内容比 iPhone 6 还少。完全不符合 Bigger than bigger 。

打个比方就是：相同字号的情况下，iPhone 6如果一行显示了25个字，而 iPhone 6 Plus 按这个逻辑pt方案，一行就会只能显示24 个字了。

2、那如果逻辑point分辨率用 540×960 呢，也即图表中的 iPhone 6+ (c) ， scale 沿用老的 @2x ，最终像素分辨率 540×960@2x 不正好是 1080×1920 吗，也是完美1:1映射，无需缩放，还不需要多余做 @3x 素材； 而且这个方案的优点也很明显： pt 面积是 iPhone 6 的两倍 (540×960 = 375x667x 2)，这样屏幕可显示的内容一下就增多了 ； 但这个方案的缺点就更明显了: 所有 iOS UI 元素尺寸在屏幕上的实际物理面积一下子就变小了，比如标签栏或导航栏按钮的物理高度只有原来的 81.5% ，

点击面积就只有iPhone 6的 0.815*0.815=66.4%，用户点击就困难了，总不至于苹果考虑触摸手指操作，为