前情提要:
知识解答:基础知识学起来!为设计师量身打造的DPI指南(上)
本文是为“初学者”或者作为从一开始就想要学习更多跨DPI和跨平台设计知识的中级设计师准备的序言读物。 没有复杂的计算和不可分析的图表,只是按照划分直截了当地将内容呈献给读者,便于读者理解或是直接运用到设计过程中。
在昨天上篇中我们讲解了设计师们介绍DPI与PPI的基础知识以及数字设计的入门规范。
本篇我们将为设计师们带来PPI在iOS与Android平台上的实操处理知识。
原文:DESIGNER'S GUIDE TO DPI
来源: w3ctech
数英网对原文有删减
八、iOS上的PPI处理
让我们花点时间看看2014年年初时的iOS设备。 从屏幕大小和DPI的角度来看,iOS有两种类型的手机设备和两种类型的笔记本/台式电脑屏幕。对于手机,有iPhone和iPad。 在手机分类中,有过去的3GS(iOS6依旧支持)和更高版本,其中只有iPhone 3GS是非Retina。iPhone 5以及后来的都用了和iPhone 4/4s有相同DPI的更好的屏幕。让我们来看看下面的列表:
2014年9月Apple宣布,现在又有2个新类别的iPhone:iPhone 6和iPhone 6 Plus。iPhone 6比5要大一点(0.7英寸左右),但是PPI相同。iPhone 6 Plus由于它的尺寸,5.5英寸,产生了iOS上新的像素比,@3x。
相较于其他iPhone,iPhone 6 Plus控制展示比较特殊的是:视觉效果降频。以为iPhone 6设计为例,设计的画布为1334750px,手机上就呈现1334750的物理像素。当为iPhone 6 Plus时,手机的分辨率小于渲染的图像,因此你设计的分辨率为22081242px,展示时降频为19201080px。如下图:
物理分辨率比渲染分辨率小15%,会造成一些细节问题,比如半像素使得精细的地方变模糊。分辨率如此高也是很微妙的,除非你近距离观察。因此,在2208*1242px的画布上设计,需要注意设计中真正精细的地方,像是分隔符。模拟如下:
在iPod touch分类中,iPod第四代出来的时候使用的是iOS6非Retina。iPod第五代以及后面的都使用Retina屏幕并且兼容iOS7,它的屏幕大小与iPhone 5相同。
最后说说iPad。除了iPad 第一代,其余的都用的是iOS7,同时只有iPad2和iPad mini是非Retina屏幕。从设计的角度来看,iPad mini只是普通的iPad(一样的PPI屏幕),但是物理体积更小,也就是说它们拥有相同的分辨率,只是大小从9.7英寸减小到了7.9英寸。保持同样的比例,便会相应地增大像素点的密度,你的虚拟资源就会显得更小了。
至于台式机和笔记本,我们不会全面讨论Apple提供的各种尺寸的屏幕。在今天,Apple提供的几乎都是1x像素比的Retina屏幕(Macbook,Macbook Air,旧版Macbook Pros,台式机显示器),Retina只应用于13和15寸的Macbook Pro。iPad和iPhone像素比是2x。为台式机设计与手机设计不同的是,你需要以相同方式设计来覆盖这两种不同类别的屏幕。
当只使用一种像素比时,基于iOS和OSX的设计是非常简单的。我建议开始设计时先用基础的PPI(例如,100%/1x)然后增加到2x并在2x的屏幕上校验你的设计并且生成2x的资源。当你熟悉在1x和2x之间切换设计后,就能够直接在2x上进行设计了,低分辨率时资源更小。如果你正在为Retina屏幕设计的话(Macbook Pro),这就特别有用。
引入资源,chrome为例
如图所示,每次请求资源需要传送两张图片。非Retina下图片名为name.png,Retina的图片增加到@2x命名为@2x.png,这是iOS开发约定的命名规范。
如果你创建了一个图片只用在iPad上,我们在.@2x后面加上~iPad,这仅仅只是chrome的约定。对需要的资源都这样处理,不要只用一个版本的资源来覆盖所有DPI。
iOS规则集:
@2x的资源必须始终是1x资源的两倍。
Retina资源加上@2x.
始终创建100%和200%比例的图片。
1x和2x的资源始终要保持名字相同。
在100%比例下开始设计,然后做乘法。
传递.png格式的图片。
使用pt创建规范而不是px。
九、Android上的PPI处理
Android平台的设备种类比iOS多,因为任何OEM都可以生产设备并且几乎没有比例的限制,然后加上自己版本号。结果就是生产出几乎无限制的屏幕大小和DPI种类,电话和平板电脑一样大,或者电话和平板电脑一样小的情况比比皆是。为此,你的设计总是需要做适配。
在这个部分,我们将采用不同于iOS的方法,我们先来讨论下像素比和DPI分类。
Android设备可以分为两类:手机和平板电脑。这两种设备又可以按照不同DPI分为:ldpi、mdpi、 tvdpi、 hdpi、 xhdpi、 xxhdpi和xxxhdpi。
首先我们要找到等价于iOS上1x的基础单位。在Android上,这个基础单位就是MDPI。
让我们看看下面列表的像素比。
是的,很多,而且还没有完,还有一个落下了。
实际上,目前正在使用的DPI有4个:MDPI, HDPI, XHDPI和XXHDPI。 LDPI是过时的DPI,现在已经不再使用,TVDPI是TV UI的特殊例子,在2012年版的Nexus 7中短暂使用过,在手机和平板电脑的使用中没有考虑的必要。尽管如此,TVDPI的像素比(1.33x)还是被用在一些安卓系统的设备上,像是LG G手表,我们后面来讨论这个。
以下是带着各自DPI的Android手机和平板电脑,相当直观:
引入资源,chrome为例
每次请求资源都需要传递一组4张图片,从MDPI到XXHDPI,无需考虑LDPI。注意,在下面的chrome版本中,TVDPI的输入在这个例子里的5张图片里也很清楚。和iOS一样,我建议把100%或者1x的像素比作为你设计的基础,这会让设计在适配其他像素比的时候容易一点,特别是在像素比为1.33和1.5的安卓系统上。
看看下面安卓上chrome的返回按钮的例子:
DPI后面跟着的建议名称不是安卓官方指南强制要求的,这是我们为资源取名的方式,因为现在有限的设计工具很难给每个资源定义一个路径。 考虑到一个资源有时有上百个资源文件,站在设计师的角度来说这是使输出过程不那么痛苦以及避免重命名错误的一个途径。资源在资源仓库里面的存储方式是有结构的,例如:
drawable-mdpi/asset.png
drawable-hdpi/asset.png
etc...
如你所见,资源被截成了3232dp的正方形,Android像素比也会是小数。当用1.33或者1.5乘以一个数的时候,最后的结果很有可能就是小数。在这种情况下你需要通过四舍五入来让数字变得有效。在这个例子中,321.33=42.56所以四舍五入之后是43px。
你需要注意以像素为单位的元素,比如笔画。你需要确保你的笔画既不是1px宽也不是2px同时也不像屏幕分辨率部分描述的那样模糊。
Android规则集:
Android有7种不同的DPI,你需要关注其中的4个:mdpi,hdpi,xhdpi,xxhdpi,如果希望你的app面向未来,可以关注XXXHDPI。
MDPI是基础的DPI或者1x像素比
Android使用dp代替pt当作参数规格,但是他们是一样的。
用你最好的判断来处理小数像素比。
使用.png格式图片。
十、Mac与Chrome OS上的PPI
Mac(OSX)和Chrome OS在处理PPI方面是十分相似的。 两个OS都支持常规的PPI(100%)和hi-res/retina PPI(200%)。像iPhone和iPad,就只有2x像素比。
即使大多数的用户都使用Mac和Chrome OS,但是也有用户会在低分辨率的设备上使用,我强烈建议将你的app面向未来的高端屏幕。面向未来对于ChromeOS意味着为Web-app或者网站创建hi-res资源,那绝不是浪费时间。当前有3种笔记本处理PPI,13寸、15寸Macbook pro以及Chromebook Pixel。除此之外,Chromebook Pixel还处理了touch。
引入资源,chrome为例
Chrome的工具栏按钮资源就是相似性最好的例子。我们在两个平台上使用完全相同按钮,即使代码不同,视觉上也是一样的。看下面这个chrome菜单按钮的例子。
十一、可拉伸资源
不管你的app是在桌面或者手机上。你通常都会引入可拉伸资源。
可拉伸资源的建立会使代码在没有减少渲染的情况下比实际需要的多。
他们与可重复资源即使有的时候展示结果一样,工作方式也是不同的。
看看下面这个Chrome的例子。iOS上的工具栏在整个屏幕上只用了一个在x轴上平铺的超细资源。
现在这种方式已经过时了,让我们来看看不同平台如何处理可拉伸资源。
iOS上的可拉伸资源
对iOS的设计师来说这个很简单,因为拉伸在代码里面定义比资源片段或者标记方式好。所有需要做的就是提供一个基础图片,如果你自己还没有实现这个,可以将你的资源规范定义为水平或者竖直可扩展,或者两者均可。看看下面这个iOS上Chrome的默认按钮的例子。
Android上的可拉伸资源
Android有和iOS不一样的处理可拉伸资源的方式,它更依赖设计师一点。
在这个平台你将采用九宫格,这些辅助线包括了4条围绕资源本身的线。他们必须被当作资源的一部分来传递片段/图片,用它来准确的呈现视觉规格。
他们定义了两个区域:可拉伸区域和填充区域。一旦定义好,代码就只会拉伸可拉伸区域,并把内容放在你定义的填充区域。
看看下面的例子,就是你前面看到的Chrome默认按钮的Android版本。为了演示,我把他放大了。
如你所见,这个九宫格是一组4条纯白色的bar。他们在任何DPI下都是宽1px,这是代码表示的。可拉伸区域不包括圆角因为圆角不能平铺开(否则看起来很难看)。在这个例子中,我们给按钮添加了规格允许范围内10dp的padding。.9也需要平铺并且截断部分要100%透明。
使用九宫格要求在名称后面加上.9,和在iOS资源上添加@2x的方式一样。重命名按钮的例子如下:
现在你需要非常注意你的资源大小。如果我在演示中放大了它,你就需要通过减小它的尺寸到一个最小限度来优化资源,如后面所示。保持了圆角的原样,但是将可拉伸和内容区域减小到最小限度。
需要注意的是九宫格的标记不会和设计重叠,并且资源切割是合理的。.9需要尽可能靠近资源并不与之重叠,试着不内置padding。前面的例子因为阴影而内置了padding。
九宫格不会代替你导出每种DPI的资源。它需要在每个资源版本都实行。
最后一点,.9可以有许多可拉伸区域(上面和左边),虽然我没有经常遇到这样的情况,但它也是很值得尝试的。
十二、Touch和触摸目标
首先需要知道的是做触屏相关的准备和DPI一点关系也没有。但是当涉及到设计UI或者创建资源,弄清楚触屏和DPI的关系就很重要。
选择触屏或者非触屏很大程度上取决于app的适用范围,它被部署在哪里以及希望得到怎样的用户体验。 我们可以简单地将他们分为:非触屏的桌面应用和手机app。
非触屏台式机
直到2005年,触屏才开始出现在计算机技术中。 我们使用鼠标和键盘,它们能够非常准确的操作UI。鼠标光标的精度是1pt,也就是说理论上你可以创建一个能让任何人点击的1*1pt的按钮。
这是个Chrome OS光标的20x版本。 红色区域是能在UI上触发一个事件的实际区域,十分准确。 什么是不准确的呢?手指。
那么如何为触屏设计呢?最好的办法就是让所有东西变得更大。
手指大小
这里有交互中最常用到的两根手指(食指和大拇指)的平均大小,这代表了触摸区域和被手指遮挡了的区域。实际的触摸区域(你手指接触屏幕的那部分)当然会小一点并且更准确,除非你把你的手指压在屏幕上。
在设计触屏的时候,放大触摸目标的尺寸比低估更安全。
各平台推荐的触屏目标
在像素世界英寸或者厘米并不是一个好的计量方法,即使是像素也不是真正好的计量方法。所以你怎么确保你的设计是可被触摸的呢?我虽然讲了很多理论知识,但是更重要的是自己试着在目标设备/台式机上设计。 但是为了避免浪费更多时间,有一些基础的像素的大小使用起来是比较安全的,并且被推荐使用在每个OS上。
需要注意的是,这些大小都是为了方便,都不是现实生活中的测量单位,他们依赖于OEM和各厂商遵守这个指南来生产屏幕,使之保持大小、dpi比例一致。
每个OS都有一系列自己的推荐规范,但是都在48pt左右。Windows的规格是包含了padding的,所以我把它加到这里。
尺寸的不同是源于不同的因素。 Apple可以控制它的硬件,因此知道触屏的质量并且能够控制这个确切的比例,它可以触摸更小的目标,另外,本身的物理尺寸也更小。另一方面,Android和Windows有不同的OEM,都各自生产自己的硬件,有更大的触摸目标会更“安全”。他们的UI更加无规范(特别是Windows),物理尺寸也越来越大了。
Chrome
这是在Chrome上的应用,编码使触摸目标呈蓝色。
如你所见,两个平台上工具栏都是被推荐的触摸目标的高度。可视范围在iOS和Android上分别是4444pt和4848pt的正方形,这不仅使得UI在大小方面和其他OS保持一致,而且也能让与用户交互的部分都保持最小的规格。
Windows 8以及Chrome OS
Windows 8和Chrome OS都支持触屏和非触屏的接口。如果你在为Windows 8 设计app,我强烈建议按照它们guidelines for touch targets来做。
Chrome OS准则目前尚未发布,但是Pixel使用问题不大。因为所有Chrome OS的app都是基于web开发,我的建议是按照触屏设计并且遵照Android touch targets guidelines来进行开发。
web,混合设备和未来
如果你在为手机设计,触屏是不二选择。如果你在设计桌面应用,参照非触屏。这听起来很简单但是在混合设备兴起的时候很容易被忽略。
混合设备是一种既支持触屏又支持非触屏的设备。Chromebook Pixel,Surface Pro和Lenovo Yoga就是很好的例子。 在这样的情况下,我们该做什么呢?没有简单的答案,但是我会首先给一个答案,触屏方向,因为那是未来的发展趋势。 如果你为web或者其他相关的设计,首先考虑触屏。
十三、设计软件
软件不能制造设计师,但是在完成任务时选择使用正确的软件可以提高效率,更快完成工作。不同的软件采用不同方式在设计界面处理DPI,在特定任务中有些软件比其他的更好。下面是最常见的:
Photoshop
界面设计工具之母。也许也是如今使用最广泛的工具。关于它的资源、教程、文章数不胜数,Photoshop几乎贯穿界面设计的每一个阶段。
正如其名,软件最开始的目的并不是界面设计而是图像或者位图处理。随时间推移以及界面设计的产生,设计师们再次使用起来。部分人是因为他们以前就用并且是那时仅有的能够把事情做得足够好的软件。
在今天,Photoshop是主要的位图编辑工具,也是UI设计中使用最广泛的软件。数十年的积累使得它成为学习和使用比较困难的软件。作为软件中的瑞士军刀,你可以用来做任何事,但是并不总是最有效的。
因为最初是基于位图的,所以Photoshop十分依赖DPI,与之相反的Illustrator和Sketch。
Illustrator
Illustrator的矢量是基于同级的。顾名思义,它重点在插画,但是也可以作为界面设计工具。
Illustrator也很适合平面设计,因此它的界面,颜色管理,缩放,标尺和单位首先就吸引你,只需要一些补丁就会更便于使用。和Photoshop一样,他也是一款很强大的工具,同时也需要付出努力去学习。
和Photoshop不同的是,图像生成采用矢量图,依靠数学公式计算,以编程方式重新调节大小并且不会损失图片质量。了解栅格化和矢量化图片的不同是建立可扩展视觉设计和资源的关键。
如果你想学习使用Illustrator来进行web/界面设计,我推荐你阅读@janoskoos的"My vector workflow"。
Sketch 3.0
与Photoshop和Illustrator比起来,Sketch还很年轻。虽然只产生了四年,但它在UI设计行业里面引起了巨大的反响。因为从一开始,Sketch的目标就是供界面和UX设计师使用,没有Photoshop和Illustrator的历史积累,Sketch把自己定位成针对小众用户——界面设计师的一款完美的调整工具。
Sketch适合快速设计框架以及复杂的视觉设计。它像Illustrator一样是完全基于矢量的,简单轻量化同时还拥有美观的UI。它结合了铜版纸使用方便和灵活的资源生成系统,让它成为跨DPI、跨平台设计最快的工具。最近发布的3.0版本也是可以用来替代Photoshop的产品。
但是也有不足的地方,Sketch是小团队开发的,而且出来得比较晚。尽管它的团队能够积极响应需求的变化,但是也没有Adobe(Photoshop和Illustrator)公司这样的规模。在位图编辑时,Sketch只能满足(设计时)最低的需求,但是Photoshop的功能就更加全面。同时,因为它的年轻,在源文件、教程和社区方面在数量上也远少于Photoshop,不过,社区用户都很积极上进。
如果你想了解更多关于我的特别的经验,建议你阅读我的"A month with Sketch 3.0 "或者"Sketch tutorial_01"。
想要了解更深入以及矢量是如何在sketch工作的?去看@pnowelldesign的文章 "Harnessing vector awesomeness in Sketch"。
附加: 并没有完美的工具但是有最适合你的。如果你有足够的时间和钱,我建议你都试试,然后再决定。
十四、文档和资源
平台文档
Android UI guidelines
Google Material guidelines
iOS7 UI guidelines
Windows UI guidelines
Google dev Principles of site design
速查表和模板
iPhone 6 Screens Demystified
Ultimate guide to iphone resolutions
Screen sizes, ratio and PPI
iOS7 designer cheat sheet
iOS7 design resource (requires Apple account)
App icons template, Android and iOS
Bjango blog
iPhone GUI and iPad GUI(.psd)
工具
Density converter
Android asset generation
Android design tips
9patch creation in Android
Android asset studio
转载请在文章开头和结尾显眼处标注:作者、出处和链接。不按规范转载侵权必究。
未经授权严禁转载,授权事宜请联系作者本人,侵权必究。
本文禁止转载,侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权,侵权必究。
评论
评论
推荐评论
暂无评论哦,快来评论一下吧!
全部评论(0条)