QCon 全球软件开发大会(北京站)门票 9 折倒计时 4 天,点击立减 ¥880 了解详情
写点什么

从视觉到 App:网易有钱 iOS 项目切图与适配实践

2016 年 5 月 23 日

引言

在 iOS、Android、PC Web 产品开发中,有个步骤基础且重要——切图和适配。在有钱项目开发中,我们参考了诸多流行的切图和适配方案,总结了一套自己的流程和规范。下面以网易有钱 iOS 的开发过程为例,介绍下我们的方法。

切图工具

切图工具五花八门,比较有代表的是 Photoshop+ PxCook +Cutterman 等 Photoshop 配合 Photoshop 配合标记工具、导出工具的方式;另外一种就是 Mac 上的 Sketch+plugins 即 Sketch 配合标记工具、导出工具。下面以 Sketch+Sketch Measure+Sketch Export Generator 为例。

切图需求

传统的切图工作是由视觉设计师来完成的,提供 assets(切图文件夹)的同时还提供了 measurement(视觉标注 )供开发使用。这种方式在我们以前也有使用,但这种方案是有弊端的:

  1. 项目成员里通常是 1 个视觉搭配 1 个 iOS 开发 +1 个 Android 开发 +1 个 PC Web\H5 开发,如果是视觉来做切图(多份适配图)+ 标记,不仅视觉的工作量太大,而且分工饱和度不匹配。如果加上后期需求变更,视觉的工作会暴增,视觉同学不堪重负。
  2. 开发逻辑和视觉逻辑不一致。开发往往会因为切的图和自己实现的思路不一致,而需要进行二次加工或者使用 workround 的方案,非常别扭。如果开发不会切图,可能需要视觉回炉重新切。在我们过往开发过程中明显地感觉到:如果是从 JS 转为专职做页面架构的同学,他们提供的 html 的文件结构层级、切图等让前端开发用起来很舒服——html 结构的层级是匹配实现逻辑的;相反如果是个本行就写页面架构的同学提供给前端开发的稿子,很少会有这样的优势。

在有钱项目开始不久,我们决定对传统的方式做以下调整:

  1. 视觉只需要出规范、Sketch 源文件、关键标记,不需要切图
  2. 开发自行切图,具体元素具体标记

这样视觉同学只需要修改 Sketch 源文件,直接传导给开发同学,开发同学拿到源文件,查看标记 + 切图。以后需求变更,视觉也只需要改 Sketch 源文件和重要标记(大部分是不需要的),就可以直接传导给开发重新切图——之间衔接比较流畅。能够实施这套方案,也得益于 Sketch 的完善和视觉与开发之间的交流深入。

  1. Sketch 比起 Photoshop 更适合移动端(Sketch vs Photoshop 见文末参考链接)。 PhotoShop 在标记方面、导出 1x2x3xPDF 等方面缺乏支持,还有其臃肿的体积、蜗牛般缓慢的打开速度、贪婪的吃内存等问题非常影响使用体验。让开发在切图、看标记的时候,不得不在 PhotoShop、标记工具、插件之间切换,额外消耗精力;相反 Sketch 内置切图、标记功能,开发人员非常容易上手。
  2. 同时视觉同学也从开发这边得到了一些反馈,了解了一些常用的界面的实现原理和逻辑,反馈到视觉设计阶段,作为设计规范和设计原则并遵守。这让视觉和开发对界面布局逻辑有了些许共识,衔接更加顺畅。

下面按照工作流的方式分别说明每一步的规则和规范、同时列一些有钱中的实例,方便读者理解。

第一步——确定视觉规范和基础约定

这部分规范和约定对应传统的 Spec 文件夹的东西。包括但不限于以下:

  1. 约定项目需要的字体字号规范。比如,把普通字符颜色和字号分别定义为 MK_COLOR_TEXT_NORMAL 和 MK_SIZE_FONT_NORMAL,分别对应 0x555555,16f。事实上这只是基础规范。如果考虑到对 iPhone 和 iPad 的版本适配,我们后面有了编号的设计,这个编号代表了字号和颜色。不同的设备下字号是经过适配的,调用者不需要了解具体数值,如 [MKStyleUtil standardLabelStyle:baseInfo withCode:MKFontStyleCode_067];能编号也得益于 Sketch 的 TextStyle 功能,在 Sketch 实现中,叫 SharedTextStyle,精确的表达了其作为规范化的工具的用途。

图 1. 视觉规范,图示为编号为 67 的 TextStyle
2. 约定基础原则。这些原则是开发是否能够在后期快速、准确、高效切图,实现视觉到 app 转换的关键。如:

  1. 约定 Sktech 开发以 Rendered Pixels 的尺寸来做,如 750X1334,而不是 375X667。缺点是,Sketch 在导出的时候,尺寸是偏大一倍的。图 2 是自动生成的导出选项,偏大,图 3 是正确的导出选项,需要手动调整。

    图 2. 错误的,大一倍的导出选项

    图 3. 正确的,导出合适图片的选项

  2. 所有元素的尺寸必须为偶数。
    这个约定可以有效避免当元素位置为奇数的时候出现毛边或者锯齿。具体原因是,图片元素在渲染时,元素边界不在物理像素边界上时,该元素会拉伸或者移动到物理像素边界。长宽是奇数 X 偶数的图片,如果旋转转 90 度或 270 度,也容易出现锯齿。

  3. 字符元素不要有 padding,他的高宽应该完全是字符本身的字体和字号来自动撑开的。
    这个规范的需求来自于,当需要确定字符和父元素或者兄弟元素间距的时候,使用 option+click 显示的尺寸数值或者安装 measure 插件之后 ctrl+shift+3 出现的尺寸数值,可以直接在代码中使用。

    图 4. Sketch Measure 插件测量元素尺寸和边距的示意

  4. 良好的分组。
    如果视觉的设计是边框 + 阴影 + 中间的小树是一个整体,那么视觉应该将这些元素作为一个分组。分组不仅让视觉在设计的时候可以作为一个整体复用,也方便开发快速切图——开发只需要选择边框,就能选择所需的元素。这里还有个特殊情况,如果视觉实现的效果是用自己特殊的字体字号设计的,视觉会使用 Sketch 的 Text on Path 技术,将其转化为一个图片。这样开发不需要安装这种字号也可以显示出来,非常棒。良好的分组在使用 measure 插件的时候,control+shift+3 也会生成合适的边距。

  5. 基础约定中的多态变化。 按钮会有 normal,disabled,selected,highlighted 等状态。视觉和开发约定:文字的 disabled 是 normal 的 0.5 透明;一组元素的 disabled 是 normal 的 0.2 透明。这个 0.2 透明通常是一个背景颜色为#000000 的视图元素覆盖到一组元素的上面,实现 disabled 效果。
    图 5 中,如左图是正常状态,右图是在左图的基础上加了一个 0.2 透明的黑色图层。下图还示例了一个有旋转的图层,切图的时候,有以下原则:如果不涉及到动态旋转,在切图的时候就切出带旋转的图片,目的是避免运行时进行旋转计算,消耗性能。有了 disabled 的约定,很多按钮和图层的样式都不需要视觉出 disabled 的效果(实际中还是有例外)。有了基础的约定,减少视觉和开发的沟通时间,在效果上也保持整个 App 的一致性。切图的第一原则:能不切就不切。

    图 5. 一组元素的 normal 和 disabled 效果对比

  6. 组件之间,一定要有规则的对齐方式。
    左对齐、右对齐、居中、垂直居中、顶部对齐、底部对齐。组件之间的间距可以是任意数值,但组件和屏幕的边距应该是一致的,如 30px。

第二步——视觉和开发的协作

在以前的旧项目开发流程中,为了减少沟通的摩擦,我们把视觉、交互、开发等资料都引入了一个叫一览 query 的工程里,打包为一个 web 服务,在内网使用。这个工程里包括 axure 交互稿的 html 版本、视觉稿 PSD 文件、开发中使用的第三方接口(txt 文件,word 文件),还有项目组的项目列表和对应负责人一览。交互将导出的 html 上传到 query 服务器,生成一个链接,其他人只需要访问这个链接就可以看到最新的交互稿,而且是实时的,不会出现交互和开发看到两个不同版本的问题。

以前是视觉做出一个效果,分别导出 PNG 和 PSD,PNG 作为给产品和 QA 等的参考,PNG 的文件由视觉以 iCloud 里图片共享的方式,供 QA、产品使用,PSD 文件以点对点的(邮件或者 POPO)方式给开发。后期使用过有道云协作共享 PSD。到了 Sketch 时期,我们又使用了百度网盘共享的方式。百度网盘 +Sketch 文件,协作起来容易的多,一是百度网盘可设置为自动同步,没必要每次都手动去 sync,二是 Sketch 文件不大,传送速度也很快。

但是,Sketch 里一个 Page 包含了若干的 artBoard,这些 artBoard 分属不同模块,所以是大家一起共享这个文件。这时候一定要关闭 Sketch 的 autoSave 功能,不然一定会出现一个视觉文件的多个 backup 都在网盘的情况。

所以最佳实践是百度网盘 +sketch without Auto Save + iCloud 的图片共享。

说到视觉和开发的协作衔接问题,不得不称赞 Sketch Measure 插件提供的 Spec export 功能。它的理念:视觉面对 Sketch 源文件,而其它人(iOS,Android,PC Web,产品,QA)直接面对 Spec export 导出的 html 文件。既然是 html 文件,自然可以跨平台,带来的优势是——只有视觉需要购买 Sketch 软件,其它人都只需要浏览器。开发可以在 export 的 html 文件里除了可以查看视觉效果外,还可以看元素的尺寸和间距、元素文字内容、radius、填充色等,还可以导出图片。这意味着什么?一个 iOS 开发完全可以拿 HTML 文件代替 Sketch,因为开发需要的东西都可以在 html 文件里找到。又可以引入到我们的 query 系统,提供在线预览功能,是不是很棒——B/S 模式的精髓!

> 图 6 Sketch Measure 插件的导出效果图

这是理想状态。

现实中,受限于视觉分组的逻辑和开发逻辑的不一致(分组影响导出的 html 里可以导出那些图片),大部分的间距标记其实对开发是无用的。当业务功能较多时,视觉的工作量会变得很重,所以目前 Measure 插件还没用起来。但是如果是简单项目,完全可以达到这种效果——优雅而高效。如果是 PCWeb 项目,用 Sketch 的另外一个插件 marketch 效果更好。Sketch Measure 插件在导出的时候,只能选择当前选中的 artBoard,所以如果需要传导给开发全部的 artBoard,是很麻烦的。我们在 Sketch Measure 的基础上增加了导出选项(当前选中、当页、所有),同时优化了导出页面的左侧导航交互,增加了显示文字的 StyleName 的功能,这就是插件 Sketch Measure Plus。

第三步——开发切图需知和技巧

>> 尺寸的确定,0padding+margin。
宁愿写 magic number 的 margin 值也要保持 0padding。具体体现在文字上,如果是单行文字,设定 padding=0,margin 可采用居中或者和兄弟组件之间的距离为某个具体值 ;而图片呢,则切不包含空白边缘的图标 。

>> 预处理视觉稿
增加容器。视觉稿中有一些相同的东西并排显示, 在视觉设计时,可能不会有容器,但代码实现层面,会用循环来输出这些元素,所以最好的方式是放到一个容器里,这样方便整体定位和更新(如 removeAllSubview) 等。预先判断各个元素的相对定位关系:如按照父容器定位、和兄弟节点定位、居中对齐等;确定定位关系,除了要考虑各元素之间位置有动态变化的情况外,还需要和视觉设计师沟通不同情况下的显示原则,如高度变高后,是所有元素之间的间距平分还是只是撑高某一个间距。

>> 从开发的角度看视觉元素
基本处理元素为图片、文字、容器。开发在拿到视觉稿时,第一时间关注到元素的设计要点,在编写代码的时候注意处理,这样一次 run、build 就能高度还原视觉稿,省去大量重复 run、build 时间。看到图片,关注点:

  1. 是否有圆角,是否需要切图切位圆角(一般切图包含圆角)
  2. 是否有边框,是否要切图切边框(一般切图中包含边框)
  3. 是否半透明
  4. 图片和四周的关系(固定边距或者居中)

而看到文字,关注点:

  1. 字体颜色、字号、字体粗细(font-weight)
  2. 在容器中的对齐方式(居中,居左,居右)
  3. 是否半透明
  4. 图片和四周的关系(固定边距或者居中)
  5. 多行文字还需要注意行距

关于容器,关注点较少:

  1. 是否圆角。
  2. 是否边框
  3. 容器高宽是否自适应。
  4. 背景色
  5. 补白(这个很重要也容易被忽略)

举例说明拿到视觉稿,如何将其分解为一个个小组件,用代码实现。

下图的图分别是理财指南的三种不同情况的视觉稿。当有红包的时候,中间位置被撑开,下半部分向下移;在 iPhone5 以下中显示,警告文字是两行。

图 7 没有红包信息, ‘苹果公司……’的什么没有换行

图 8 有红包信息, ‘苹果公司……’的什么没有换行。

图 9 没有红包信息, ‘苹果公司……’的有换行(实际上是 iPhone4、5 的情况)。

分析一下各个元素的之间的关系。不同的人对各个元素的层次划分,归属关系是不一样的,步骤:

  1. 确定元素个体。分解如下,如果是没有红包则显示编号 3‘的文本元素,有红包则显示编号 3 的文本元素:

图 10 元素分解图,4 是自行添加的元素,用来管理 3 个产品的容器。
2. 确定元素的范围。
注意按照上面的原则,每个元素的尺寸都只包含自己,没有 padding。其中 3 个产品外面的绿色框图(即元素 4)是为了代码实现时方便定位需要的容器,视觉稿里是没有的。所以有了以下的区域划分:

图 11 各个元素区域划分图
3. 确定元素的边界之后需要确定元素的定位。
分析到会有没红包和有红包两种显示效果,差别在于整个 cell 的高度。元素 1、2 保持对容器顶部对齐,元素 8 保持对容器底部对齐;元素 9 是一类元素,和视觉沟通之后,定位原则是:左右和屏幕之间的距离固定,元素之间的间隔相同(之所以没有说固定的值是因为后面有 iPhone5,iPhone6,iPhone6P,iPad 等端适配)。而元素 5、6、7 是 9 的子元素,其中 5 顶部和 9 对齐,6 顶部对齐 5 的底部并偏移,7 顶部对齐 6 的底部并偏移。所以有了以下尺寸标识:

图 12 元素定位图,边距。

图示中,没有标识横向约束的,表明横向宽度和父容器等宽,居中对齐或者左对齐。如元素 5、6、7 是和父容器等宽;8 和父容器横向有 30px 的 margin 等。

可能其他人会有这样的分组。 将 1、2、3 作为一组,让他们有一个父容器 10,让容器 10、4,8 作为兄弟节点,并且 10、4、8 元素依次向下布局。这样带来的问题是,如果有红包信息,需要撑开高度,那么需要修改容器 10 的高度,同时为了向下移动的部分能够显示完整,还需要修改 Cell 的高度。而目前图示的分组(没有包装 1、2、3 为容器 10,并且 4、8 向下对齐),带来的好处是只需要修改 cell 的高度,就可以实现视觉所示效果。

第四步,适配

有了素材有了尺寸,下一步是代码实现,你必须面对一个问题,适配。

如果你还没有感受到适配是个大问题,那么这个图会让你改变想法。

图 13 iPhone 尺寸大全

从视觉稿到一个可拿在手上触摸的 APP,需要处理(iOS7+iOS8+iOS9)*(iPhone4/5+iPhone6+iPhone6P+iPad)种情况(虽然真正需要处理并没有这么多)。基本适配方案如下:

  1. 文字字号大小,以 iPhone6 为准,iPhone5=iPhone6, iPhone6P = iPhone6*1.5,特殊地方特殊处理图片元素。素材,使用 1x2x3x 作为对应设备使用的图片;尺寸,在不同的设备里有不同的尺寸,图片相应等比缩放。
  2. 对齐和间距。 尽量居中对齐,规范间距(如所有的 tableView 的 cell 高度是一致的,只有两种高度),总结起来说,固定不动项,自适应空白。
  3. 不适配。典型的,所有元素和屏幕的边距固定为 30px,颜色不适配。

说到图片的适配,这里需要说一下 PDF 格式的 assets,据说可以只切一份 PDF 的图片而不需要 3 份。从 xcode6 开始支持以 1x 的尺寸切出 PDF 矢量图,xCode 在 complie 的时候,生成对应的 1x2x3x 的 PNG 图片。 经过我们测试结果发现,毛刺严重,而且这篇文章 Why I don’t use PDFs for iOS assets( https://bjango.com/articles/idontusepdfs/)也印证了目前不适合用 pdf 来代替 1x2x3x 的图片的结论。在查阅了一些资料之后,还发现一些其他限制:

  1. pdf 的图,不能使用 slicing(显而易见)
  2. SVG 或 PDF 矢量格式的资源, 这种方式要额外消耗手机的计算资源,特别是在界面跳转时有转场动效的情况下(未验证)

所以我们还在使用 sketch export 来导出 3 份 PNG 图,如果读者有更好的方案,欢迎和我们分享交流。

代码层面适配是如何实现的呢?

  1. 文字字号在不同的设备下有不同的大小。所以我们为某种类型的字体,设置编号。如图示中的字体被编号为 64,这个编号约定了字体和字号(不包含对齐方式)。

图 14 Sketch 里的 TextStyle,用于编号

它代表了这个文字字号的编号是 64,颜色编号是 64。实际上字体编号 64 不是一个固定的值:可见字体适配,而颜色不适配。

实际编码中,如下所示,就可以完成适配。


2. 容器的尺寸和边距。下图分别是 iPhone5、iPhone6、iPhone6P 视觉提供的适配图, 适用大部分适配的原则,标记只列出了几个关键的地方。注意:每个答案文字元素始终是水平、垂直居中对齐的。

图 15 iPhone4、5 的适配效果。图中标出了边距、一个问题行的高度,跳过按钮的尺寸。

图 16 iPhone6 的适配效果

图 17 iPhone6P 的适配,可见问答卡片到屏幕的边距已经不是 45px 了,而是特殊的 102px

看到这么多尺寸,是不是有种要哭的冲动?不过有了 masonry 和 StyleUtil,写起来容易得多。以整个问答卡片的定位为例,关键代码如下:

适配是个复杂的工程,即使有了所谓的规范,也不能覆盖所有的场景。有些很重要的场景还是需要一个像素一个像素的调整,终究是个体力活。

说完了我们最核心的方法之后,为了保持文章的完整性,列出切图时命名规则:模块名 - 页面名 - 图片种类 - 图片名字状态(如果有)破折号 - 表示分组,下划线表示状态, 最长破折号不要超过 5 个,如果还有很多子功能,可以使用驼峰模式。

譬如,投资模块 - 股票列表页面 - 头部的背景。命名

invest-stock-bg-tableheader当总体股票是赚钱的时候,是红色的背景,如果亏损则是绿色,命名:

复制代码
invest-stock-bg-tableheader_green
invest-stock-bg-tableheader_red

买入按钮的图片,正常和 disabled 状态的命名:

复制代码
invest-stock-ico-buy
invest-stock-ico-buy_disabled

公共使用的图片,如查看更多,命名:

ico-viewMore## 最后一步,走查

如果严格的做好上面的工作,做出 100% 和视觉 matching 的 APP 已经不是梦。然而,然而,人都是有惰性的。可能你记得量了一个块级元素的上下间距适配,却忘记了左右边距适配。

所以为了克服人性的弱点,我们在项目开发的瀑布图中加了一环——视觉交互走查。大概的形式是视觉和开发一对一坐在一起,视觉一个界面一个界面地看,那里不对那里要改,这时候不仅改开发不符合视觉的地方,也改视觉当时没有考虑好的地方。这个阶段有时候很耗时。如果是传统的 native 开发,大部分是按照 iPhone5 走查,改动完毕之后再依次安装到 iPhone6、iPhone6P、iPad,看效果。但是后期部分功能采用了 react-native 的模式,可以做到修改之后,各个设备分别摇一摇就能看效果——做到了多端并行走查,提高了效率。

做完了这些步骤,通过测试之后,一个香喷喷的 APP 就可以 deliver 到用户手上了~

结尾

在追求如何优雅高效地切图和适配的探索上,我们才刚刚起步,有些地方还不尽完善。切图时需要手动改导出选项的问题,还在让我们头疼(Sketch export to xcode 的 change base dentist 不能设置 0.5);Sketch 的 measure 插件在测量边距时,还是不能正确地寻找到它的兄弟元素(手动 option+mouse over 是可以的);在开发 native 代码时,多种设备适配走查,效率还是很低(react-native 没有全部替换 native);对于 iPad 端适配,视觉同学苦不堪言——还不如专门为 iPad 设计一套——怎么适配都很丑(在示例代码中,你可以看到大部分 iPad 是按照 iPhone5 来适配的)。

我们希望看到有更好的方案来做适配这种体力活,解放我们的眼睛,解放我们的双手。对于以上内容,如果存在谬误或者有更好的方法,欢迎读者朋友和我们交流。

参考

  1. https://www.designernews.co/stories/46380-sketch-vs-photoshop-for-ui–ux-design 对比才有看头!SKETCH 秒杀 PS CC 2015 新功能的 7 个地方
    3. https://www.zhihu.com/question/27495264 Sketch 有哪些插件值得推荐?
    5. http://antinomy.me/2014_07_16_186/ 移动 APP 图标设计建议和技巧
    7. http://www.shejipai.cn/app-cut-plan.html APP 切图的那点事——安卓与 iOS 平台切图小结
    9. http://www.shejidaren.com/image-slice-for-ios-apps.html iOS APP UI 设计之从效果图到 UI 切图
  2. http://www.ui.cn/detail/48165.html 進擊腾讯の浩男(二)
    12. https://www.zhihu.com/question/25370620 Xcode 6 可以使用 PDF 格式的矢量图作为图片资源,自动适配?
    14. http://youxiputao.tw/articles/3145 iPhone 6/6 Plus 出現後,如何實現一份設計稿支持多個尺寸?

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 5 月 23 日 17:287156

评论

发布
暂无评论
发现更多内容

【架构训练营】第一期

云064

week1《作业二:根据当周学习情况,完成一篇学习总结》

任鑫

食堂就餐卡系统设计文档

JUN

第一周学习总结

G小调

食堂就餐卡系统架构设计文档

AIK

极客大学架构师训练营

架构师训练营第1周作业

无名氏

架构师第一周总结

suke

极客大学架构师训练营

关于架构设计的学习记录

imicode

第一周作业

qqq

极客大学架构师训练营

架构师训练营-Week 01 学习总结

华乐彬

学习 架构 架构师 极客大学架构师训练营

架构师训练营第一周总结

草原上的奔跑

极客大学架构师训练营

食堂就餐卡系统设计

G小调

架构师如何去编写设计文档?

阿飞

架构 架构是训练营

架构师如何做架构(第1周学习总结)

李德政

极客大学架构师训练营

食堂就餐卡系统设计

chinsun1

架构文档

「架构师训练营」作业1:食堂就餐卡系统设计

Amy

极客大学架构师训练营 作业

架构师训练营第一周学习总结

a晖

如何开始成为一名架构师

Ph0rse

极客大学架构师训练营

初识架构师

eazonshaw

极客大学架构师训练营

食堂就餐卡系统设计

imicode

【架构师训练营-作业-1】食堂就餐卡系统设计

Andy

课后总结1-架构师训练营

进击的炮灰

架构师-第一课总结

free[啤酒]

架构师0期 | 食堂就餐卡系统架构设计文档

刁架构

极客大学架构师训练营

架构师训练营-Week 01 命题作业

华乐彬

极客大学架构师训练营 架构文档 作业

第一周作业

Jeremy

第一周-学习总结

molly

极客大学架构师训练营

架构师如何做架构(训练营第一课)

看山是山

学习 极客大学架构师训练营 UML

第一周培训心得

史慧君

食堂就餐卡系统设计

olderwei

第一周感想

数字

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

从视觉到App:网易有钱iOS项目切图与适配实践-InfoQ