图片,对于界面来说是非常关键的元素,一个优质的UI框架有时也需要图片加持。所以UI在工作中几乎无时无刻没在和图片打着交道。
区别于平面设计师和美工,UI设计师对于图片的处理可不单单只到视觉设计这一步就结束了,UI价值的体现也表现在图片线上使用的场景当中。
UI对图片的处理,一方面是考虑到数据流量成本——懂得如何做到视觉美观的同时,也要把控好文件的大小;另一方面图片的适配方案也是UI必修的一个知识点。
iOS 人机交互准则与 Material Design 就图片控件专门抽出了一个版块进行讲解。那么这次「耍好控件」专题我就来给大家理一理UI对于图片处理应该注意的那些问题。
做UI的朋友应该都知道移动设备是有像素倍率之别的,标准分辨率的显示器具有1:1的像素密度(即@1x),其中一个像素占位一个点。高分辨率显示器具有更高的像素密度,存在1.5倍、2倍或3倍的比例系数(即@1.5x、@2x、@3x)。
当我们在@1x下使用一张10px*10px的图片,到比例系数为2倍或3倍的设备上,将会展示为20px*20px 和 30px*30px。
所以为了保证高分辨率显示器下的图片不失真,我们需要具有更多像素数的图像。
iOS人机交互规范指导设计师:为应用中支持的所有设备提供高分辨率图像。
但位图区别于矢量图的关键就在于此,不论是放大还是缩小一张位图,图片都会发生损伤(即失真)。但由小尺寸图片放大适应大尺寸,会发生肉眼可见的失真;而大尺寸的图片缩小适应小尺寸,失真并不会极端到让人无法接受,至少肉眼看上去还是比较清晰的。
所以我们也常用@2x或@3x来切图,以保证图片的显示质量。
@3x毋庸置疑是像素数最多的切图尺寸,向下适配@2x和@1x都不会使图片被损伤到糊掉的程度,但缺点也正是在于像素数多,文件尺寸相对较大。
@2x可向下适配@1x,但向上适配@3x时可能会出现图像边缘糊掉的情况,在对视觉要求颇高的项目当中不被允许。但@2x是一个可平衡图片质量和线上文件大小的一个优质方案,这也是为什么UI出稿、切图习惯使用@2x稿的原因所在。
决定用哪一个倍率交付图片文件各有利弊,就看项目侧重点在哪一个方面。
但如果你要问我,线上文件大小至于那么重要么?那你是应该了解一下为什么我说UI的价值体现之一在于控制线上文件大小了。
在我的过往职业经历中,曾被要求填过一个公司前UI留下来的坑:项目经理要求我批量压缩一下线上图片文件大小,因为图片文件过大,导致公司浪费很多财力在服务器的数据请求上。
所有做互联网项目的人都应该了解一点:从服务器请求线上的文件数据,每一个单位流量都是要付钱的。所以公司老板和项目经理是很care这一点的。那么UI在处理图片时应该如何控制文件大小呢?
我曾经在《了解图标落地》一文中提到过,我常使用 tinypng 压缩处理位图文件,但“压缩”这一步已经是对于处理图片大小比较后期的做法了。前期我们可以通过决策图片格式来达到控制位图文件大小的目的。
对于位图,我们在线上场景中最常使用的文件格式无非是PNG和JPEG(对于动画也会使用到GIF)。
根据iOS人机交互准则的指导建议:
对于UI来说,图片的适配是必须掌握的一个知识点,因为我们经常会面临给前端提出各种图片适配方案的情形。如果这一块存在知识盲区,很可能造成图片适配不和谐的效果。(比方说我在《聊聊加载等待的那些事 之 启动页 》中提到的闪屏适配方案,很多UI因为存在适配知识盲区,很可能因为找不到合适的适配方案,导致闪屏页被强制拉伸变形。)
常见的图片适配的方案总结下来主要分为以下十二种:
对于不同的布局适配场景我们可能选择的适配方案不同。
对于可以前期进行干预的场景(例如用户更换头像),我们可以直接强制要求上传者进行裁剪,而不用再进行不必要的适配,并且可以帮助我们控制线上图像文件大小。
既然来了,说些什么?