移动端UI设计研究

前情提要

半年前公司设计组要求重新定制一套新的规则以适配越来越多的手机分辨率

同时也是为了解决原本多个设计师为了方便，各自用自己的设计习惯，有的用1080P设计（安卓的基础分辨率），有的用640P设计（iOS的最小分辨率），导致混乱不清的问题

调研

iOS这边由于逻辑分辨率即使在18年9月推出完整的plus分辨率新机（1242x2689，目前的8p分辨率是1242P缩小成了1080P），iOS也还是只有3个逻辑水平分辨率（320，375，414），由此，iOS更希望设计图分辨率能满足640P或者750P这两个值，但640又太小，所以最终希望能以750P为效果图，实现后只需要检查一下4英寸iPhone会不会UI错误，如果有调整就行。

安卓虽然分辨率众多，但大致都可以通过1080P乘上某个倍率得出，所以安卓组为了简单，只要求满足1080P这个就行

接着我们在百度谷歌能搜索了一阵子，发现国内大部分的设计规范的确都是用750P做一套，iOS和安卓公用

不过测试过后安卓那边还是说希望能以1080P为基准，否则导出素材后，资源管理会出现性能问题（大概是这个原因？年代久远我忘了），即使上传矢量图，蓝湖也不能自动导出1080P为基准的素材（...）。而如果用1080P的话，iOS这边适配又有问题。由于人力不够，设计师也不能针对每个新界面设计多套图，甚至如果有必要，这套图后面还得给前端使用（小公司没办法），如果是大公司完全可以安卓一套，iOS一套，前端一套不重样的，甚至可以按照DPI划分区域，一种一套来适配以保证最佳显示效果。所以讨论下来都没有好的结果。虽然最后我还是想到了一个挺好的办法以最低的成本协同两个移动端

先说一下讨论后的方案

方案1

用750P做设计图，这个已经说过了，安卓组不肯（其中一个同事原话是：用750P这种奇葩分辨率不想写）

方案2

用1080P作图，iOS这边不好用

方案3

做多套图，设计组人手不够时间不够

那既然这边嫌太大，那边嫌太小，那就拿1125（750x1.5，@3x,iPhoneX的分辨率）作为水平分辨率，然后以2208（8P的垂直分辨率）作为垂直分辨率，大概感觉如下：

移动端分辨率.jpg 1125x2208.jpg

可以看出，1125P和1080P的差距实际上不到5%，设计师可以用1125P作矢量图，然后作为@3x图上传给iOS，再直接缩小为1080P上传给安卓组

看到这里可能有同学要问了，既然传@3x图了，为什么不直接拿1080P做@3x图给iOS呢？

这是因为我们公司的一个设计师是用iPhone6s，她严格要求做完要在她手机上过一遍和设计图一模一样才行，而且如果用1080P做@3x图的话，以360PX作为逻辑分辨率，在另一位设计师的手机（7p）上，又会介意字体偏小。所以讨论下来后我们决定用这样简单的缩小作为成本，给两个端上传不同的分辨率。

但后来发现，这位设计师实际上是用1080P作图给安卓，然后放大到1125P传给iOS。这也是可行的，因为虽然是做成1080P，但测试的手机还是6s（...）

至于为什么要拿8P的2208P作为垂直分辨率，主要是因为设计师里面有的是用plus，为了方便她在自己手机上测试（通过PS play在手机上看，满屏幕的时候就是她手机显示的实际效果）

同时，用1125P也是为了偶尔极少数存在非矢量图的情况，设计师可以以全分辨率的形式上传，对应的@3x素材也不会因为通过750P上传，导致过于模糊

至此实践了大半年，就目前使用下来的情况看，还是稍微存在的一些问题的

一是由于要分开上传，有时候设计师在上传iOS版本的时候，总会会忘记勾选某些素材，尤其是来回确认修改的时候更为明显，然后她又没有空，就会为了等待这份素材等好久，或者为了节省时间她会让我们干脆在安卓版本那边拿（但这个问题也不是不能接受）

二是一次性上传多个页面时，iOS这边有小概率会漏传，这个问题和一类似。设计师通知后，我们会以为设计图都好了导致误判数量导致工期把握出错（比如以为2个星期做5个页面，实际上有6个），当然这其实也是我的锅，交接的时候没有确认清楚，现在已经没有这种事情发生了