nevoui

前言

恩，没错上几篇的概念稿就是iuni os的。

去年入职，当时刚好启动iuni os2.0。背景不说，各种原因。

其实整个公司，从推广、运营、rom这几方面讲，rom一直是最稳定的一块，无论设计还是开发。

OS2.0是基于大屏单手操作和谷歌material design的设计为理念修改的。所以很多设计都可以看到MD的影子。

这个rom我负责的是联系人、短信、备忘录、邮件、设置、控件、以及各个手机设配。（其实我也很诧异我负责了这么多模块OMG）。

但这篇文章只说“控件”和“各个手机适配”这块。

文章目的

1是个人历来习惯的项目总结

2国内做rom挺多的，但是如果说要在这方面做交流，就几乎很难。所以这篇主要是我总结一些经验，如果同行愿意交流当然最好(我也不希望闭门造车)。后面如果有人要做新的ROM，那么也可以参考参考。大家多多交流。

一、控件简介

控件就是指整个rom每个app都会用到的组件。比如弹窗/tab/action bar等，短信联系人备忘录等等都会出现这些组件。就叫控件。

同时控件也是用户最不可感知、最不起眼、最基本但是却是非常重要的版块。

二、控件交互篇（如何启动控件）

我们是先做csp（电话联系人短信），这三个也是rom最基础不可或缺的模块。这三个做出来后，提取基础通用控件。

(从csp提取的通用控件action bar、tab、list，图传上来就特别模糊了...）

然后开始做设置和文件夹管理（因为这三个用到控件是最多的），把csp整理出来的控件放到这2个地方去验证，如果这个过程交互没有出错，那么控件问题就解决了大部分。

控件方面的交互对逻辑要求没有做一个app强，主要考验交互设计师对全局各个应用流程理解、大局观（尽可能想象哪些app会出现通用的控件），以及对控件兼容性进行把控。做控件初期切记不要过早陷入细节，应该快速出快速检验快速修改。

后面当然会有漏掉的控件，可以在后续做其他app时候再补充上去。所以控件是一个持续性大工作连的模块，要不断完善和更新。

三、控件视觉篇

我觉得控件主要工作量是在视觉部分。对原生控件的思考（后面会说）和重新定义规范。所以这里拿几个模块说一下。

控件视觉方面没有太多特别设计。毕竟控件的视觉不是区分rom特色的主要地方（应该是天气时钟音乐等app），如果在控件过于突出特色，视觉很容易失控。

控件是一个让用户完成任务的模块，他应该是简单的、低调的、不让用户注意到他的存在，辅助用户完成任务的模块。（当然负责小部分的特色创新还是可以的，靠把控~）

控件这次的视觉方面这里会更简化一些元素比如线，可以用留白体现行列关系的就不用线条。但是全部都用留白区分，虽然视觉上更好看，但是对于长久使用来说（耐用），保留一些必要的还是很必要的。所以还是那句话，看经验看把控。

1布局

总布局直接用了material design的布局，左右各16DP也很适合，左侧距离titile的距离改为52DP（缩小了20）。因为MD的有些元素过于分散，没有体现出元素间关系。图片比例也是直接用了谷歌规范

（图片上传后依旧模糊...）

2层级 

尽可能减少了视觉层级，首先需要一个全局通用的底层（确定颜色），然后区分好actionbar，tab，和文字内容展示层的关系。（这里本来有图的QAQ）

3控件主要部分之action bar和tab

这个部分csp做出来也就基本成型了。这里的tab和actionbar和大部分rom有区分度，可以成为区分特色之一，但又低调简单，所以满足控件主要需求。

这里actionbar提供了两种模式，纯白和多彩两种切换。这个设计和公司宣传定位有关，不表。

4控件主要部分之list

list分为单行/双行/多行，带头像的单行/双行/多行，带icon的单行/双行（如果有）。这里主要考验视觉设计师大局观、基础功。然后标注每个部分。

5按钮

（按钮规范）

（使用案例） 

按钮部分主要也是看全局思考，什么时候用纯文字按钮，什么情况要用色块，什么时候用线条按钮等。基本上，纯文字和色块按钮可以应对大部分情况。辅助色/点亮色都出现在这里。

6弹窗/menu

iuni os2.0的弹窗都是由底部出来的，为了单手操作便捷，这里也和miui一个思路。

弹窗是一个主要问题所在。问题就出在标题大小的把控。

标题大小是通用的，从一致性来说，也应该是通用大小才对。问题就在于如果设计时没有一开始大局思考，很容易就会在局部搞混。

案例：比如下图的“通知”和“添加更多选项”“分享至”其实是共用大小（设计时候会觉得“通知”和“分享至”不是一个类型，一个是大标题一个提示，于是用了不同大小）。这里要在全局时就考虑权衡一个最佳尺寸。

 

另外，弹窗分为有标题弹窗和无标题弹窗。分为这2种弹窗意味着开发工足量也更大。但是为了用户体验（尽可能减少重复不必要文字，很多弹窗一句话可以解决），还是有区分更好，无标题弹窗的正文可以与有标题的弹窗的正文大小不一样。

6.1弹窗文案问题

弹窗文案应该让用户更少思考

 

删除按钮右边用“确定”的话，用户需要思考是“确定”什么事情。

 

按钮文案是“删除”的话，用户则无需看细看弹窗文案，直接可以知道这个弹窗是删除。

当然，如果可以做特殊处理，删除弹窗文案可以更简洁。eg

 

魅族的删除弹窗我很欣赏，简洁干脆没多余文字。

7其他

icon啥的就不说了，制作一个icon库给大家方便使用。控件视觉部分出了就剩下标注了，然后给相关人员解说等，这里就不细说这些了。

四、细节

这章应该属于控件视觉篇的子模块，但是我觉得挺重要的，所以开了一个章节

以列表为例

（网上某作品的列表）

（网易云音乐的列表）

列表你说与每个APP/ROM的大的区别在哪？没有。

因为全宇宙的列表都是这个样，不然也不叫列表了。但是最简单的地方，却是最考设计师基本功的地方。这里细节好坏会影响全局。字体大小间距留白比例等处理。

设计基本原则：

亲密性、对齐、重复、对比。一个列表占了3个点（对比、对齐和亲密性）。另外还有一点留白的处理。

名字是一级，正文是二级，第一第二级要表现出层次关系，另外第一级和第二级又要尽可能紧凑（又保持该有的距离），也就是亲密，第一级和第二级紧凑那么每行的留白也就会增加(仅限列表，正文间距又是一种处理方式)

这个看似很简单大家都懂，但是我观察其实蛮多设计师没太在意这方面，因为有时候一不小心也能做成一个很好的列表，但有时也会做成一个看得过去但其实很多小问题的列表。

紧凑处理从实现角度讲，也是如此，并且后期出现问题也会更少。

图是原生系统列表。一级和二级文字没有间隔，所以第一行和第二行留白更多，看起来也更舒服。如果第一级和第二级间距过大，那么就要标注一级和二级文字的间距，以后对设配各个手机、出现多行文字、大中小文字切换的时候，会相对有很多麻烦事情（比如程序实现会把列表高度拉高，行间距标注数字要有各种变换。标注没那么优雅~）

原生的行距、字体、比例都处理很漂亮（miui的也是）

（原生案例）

对留白的把控可以看下面这个案例

从左到右分别是微博、脸书、推特。微博密密麻麻占了一个屏，而脸书和推特看起来都相对舒服，因为脸书和推特在字体大小，正文辅助文大小对比（层级）、字体颜色，行距、还有留白都更加讲究。当然，差别不是太明显（分别在手机上看区别会大点，因为这时候还会与手机尺寸对比），只是在细微之间。这些都能看出一个设计师的基础功。

PS英文下微博表现其实还好，但是中文基本就差了，图是以前版本的，现在版本可能因为手机变大关系我觉得好了点比以前版本

五、适配

手机适配主要是大屏（5.5和5.5+）和小屏（5.5-）的适配。因为iuni只做了个尺寸的手机（5寸和6寸），所以这里说的是以这2个尺寸的下经验总结。

大小屏适配第一次做，也没有经验借鉴，所以我感觉做的比较死板，不过结果我们对适配还是满意。

第一步我们使用小屏手机为基准做的，在5寸基础上适配大屏。主要要点就是所有的标注（行间距、字体大小等）在大屏下都要缩小，因为不缩小就相当于等比放大，大屏手机可以显示更多信息的优势就没有发挥出来，所有元素过大，也就是我上文细节说的说的，元素和屏幕比例会失调，视觉上看也很难看，和老人机一样。

比如5寸手机单行行距48dp，在6寸手机就变为44dp（物理尺寸大致不变），再比如5寸手机正文大小16sp，到了6寸手机就变为14sp。

基本上适配原则是保持物理尺寸不变（小屏到大屏就是每个元素缩小，缩小值自己定反复对比）

如果是图片就相对复杂点，这里借鉴了以前我适配苹果6到6+的方式，也就是文字流式，控件弹性，图片等比缩放。

下图是当时iphone6适配方式（图片源于知乎pigtwo）

至于控件标注需不需要修改，后来我就干脆直接做了这种大集合，然后直接标注

再后来，我们用了一种根据手机DPI适配的方式（也是为什么我会觉得之前适配有点死板）

因为一个ROM，如果只是自己应用做好看了，但是第三方手机适配不好（第三方在大屏手机元素过大）是不够的。直接修改手机DPI，便是一个第三方app都能一起缩放的方式。同时也能减少很多视觉上的工作量。

从愿景来说是对的，但是会不会出现新的问题（比如有些第三方app是自己做了适配），就不知道了。因为用这种方式开始适配时候，IUNI OS已经不做了。。

六、适用性/补充控件等

控件是一个不断更新持续性的工程，也是一个不断迭代纠错的过程。比如还有空状态等等，这里不细说了。

 

（空状态设计，防止用户发呆迷茫用，需要提示当前状态，告知原因并提供解决方案）

七、其他

为了方便其他设计师，会做控件的PSD，我用1X做的。也就是说720P手机，psd大小就乘以2,1080P手机就乘以3，2K屏幕就乘以4。

如果以720/1080位标注做控件，以后做适配切图是按照除法或者乘以0.5倍数的，这样很容易出现虚边，会加大很多工作量。乘以整数倍数就没有这个问题。这是以前做ios适配遗留经验，后来研究谷歌psd，他们也是这样做的~

输出格式为svg矢量图，所以1倍的切图给开发也很方便他们。

Icon的话可以做一个icon控件库，但这又是一个大的工程了~

关于原生规范思考

做这套规范的时候很多参考了谷歌规范，一开始用了很多他们规范。后来体验中这些搬过来的规范被慢慢优化了或者说更适合iuni os了。

其实MD的设计规范只是一种建议，目的是为了开发者设计app能在一个比较好的水准，实际项目要结合实际情况，比如原生有些元素过于视觉元素分散会显得不精致，比如有些交互不好用（隐藏式边栏汉堡宝等，后面谷歌有更新了一个bottom bar也说明这些问题），这些都要辩证去看。

另外做自己的产品和rom需要一套自己逻辑，谷歌md规范很好，他能帮我们少走一些歪路，但也不能迷信和固执~

关于自己产品的逻辑案例：比如修改联系人人后，正确交互应该是左上返回就自动保存，但是全局考虑，右上加个保存返回弹窗全局兼容性更好，加上修改联系人也不是高频操作，权衡一下，于是返回有了弹窗提示保存而不是直接保存。

最后说句，控件的视觉方面miui做的还很好的~所以也要感谢miui。。。

最后

做控件前期需要大局观，后期需要的是耐心和细心。大致想法也这么多，虽然也没有全部放上来，全放上来太啰嗦了，现在也够多了。。也希望可以更好交流。

这里最后放上一部分控件整理。