很多项目一开始没有注意美术素材的规范，这在后期会引起混乱。假如有机会做一个新项目（旧项目会有自己的历史问题，一下子很难改过来），建议设计师和程序员一起坐下来。共同设立一套规范，之后共同遵守。
下面说说我自己用的规范，并解释一下原因。
界面名字
每个界面需定出一个前缀。比如主页，前缀是 home，设置前缀为 settings，课程表是 lesson。
定好前缀之后。设计师就可以建立文件夹：
主页(home)
设置(settings)
课程表(lesson)
课程概述(overview)
共用(shared)
之后将素材放到对应的文件夹下，这样就容易找了。假如很多界面都用到的素材，比如一些按钮之类，就放到shared目录下。
设计师的英文似乎不是很好，他们的喜欢用中文命名，但是程序需要使用英文。假如一开始不约定好，程序员需要使用素材的时候，就很难跟设计师取的名字对应起来，往往会不知道素材放到什么地方。
素材名字
最终的素材名字，只使用小写字母和数字，单词的分隔用中划线 - 分隔起来，不同界面的素材前面加上对应界面的前缀。比如
home-background.png
settings-icon-email.png
settings-icon-help.png
shared-button-0.png
名字使用对应的界面前缀，是为了知道素材原始出处。这样有问题了，可以找到原始文件重新导出。也避免了名字冲突。
只使用字母和数字，中划线，是为避免出现中文、空格、标点、斜杠等特殊字符。在不同的系统上，字符编码会有所不同，而一些特殊字符会有特别的含义。中文或者特殊字符容易出些古怪问题。比如程序员写个脚本去统一拷贝、处理素材，中文或特殊字符就特别容易出问题。
只使用小写字母，是为避免写错大小写。比如 Mac 系统，默认情况下对于大小写是不区别的，假如图片
home-background.png
错写成
home-Background.png
在模拟器中显示是没有问题的。而真机中名字是区分大小写的，这样模拟器跟真机的行为就不对应了。全部使用小写字母就直接杜绝了这问题。
使用中划线 - 而不使用下划线 _ 分隔。是为了将来更好地搜索查找。工程中的程序变量的名字，不会出现中划线，只会使用下划线。当素材名字使用中划线，就可以跟程序变量名字区别开来，以后在工程中就容易搜索。
这些名字规范，看起来简单，但可以杜绝很多问题。项目中，素材名字应该是设计师导出的时候就取好了，这样一旦需要修改，直接复制过来就行了。但现实中，我发觉设计师往往不会注意这些，经常需要程序员重新命名。这样修改起来就多了一个步骤。
尺寸单位
设计师往往使用像素作为设计单位，但是对于 iOS 来说。使用像素来思考是不好的，应该使用点(point)来思考。点和像素的区别，参考我的旧文。
比如
iPhone 6，尺寸为 375 x 667 个点，2x 模式。
iPhone 6 Plus，尺寸为 414 × 736，3x 模式。
iPad，尺寸为 1024 × 768，有 1x 和 2x 模式。
使用点为单位，容易跟程序对应起来。并且每个 iOS 设备，相同的点数，物理上的长度是差不多的。44个点，就是手机上导航栏，工具栏的高度，这样的思考方式可以大致估计到真实的物理长度。而用像素，容易使得做出的图片过大或者过小。
当使用非矢量图片时，将点数乘以对应的 x 模式，就等于需要做的像素大小。
当矢量工具来做素材的时候，应该直接做点那个尺寸。比如44 x 66 个点的按钮。就建立一个44 x 66的场景。之后再导出成 2 倍图，3 倍图，或者直接导出成 svg 的矢量图片。
最终标注设计稿的时候，也使用点作为单位来标注。其实标注的时候，只要导出一个 1x 的预览图，就可以用工具来标注了。当 1x 的时候，点和像素就是直接对应的。
设计尺寸
手机 App 只需要一个设计稿，不需要设计多个。假如平板上的布局跟手机是不一样的，需要再出一个设计稿。假如是基本一样的，连平板的设计稿也不需要。比如微信的的 iPhone 版和 iPad 版，流程布局是一致的，其实只需要出一个 iPhone 的设计稿。
设计的时候，选取一个现在最主流，你最容易获取的设备的尺寸来设计。比如现在 iPhone 最主流是 6 的尺寸，就选择
375 x 667 点，2x 模式
作为设计尺寸。之后整个设计稿就使用这个尺寸来设计，不要一时一个样。假如你是个人开发者，身边只有 5s，就使用 5s 的尺寸来设计。
这样就可以将设计稿截图，放到手机中看效果。适配不能直接按比例放大或者缩小，假如你将 iPhone 6s 的设计稿，放到 5s 中看，图片按比例缩小了，但你看到的并非最终效果。
标注
设计师来标注？
其实我自己觉得让美术标注，是浪费人力的。只要出个 1x 的预览图，再让程序员装个马克鳗、或Pixel Winch、或 PS，就可以让程序员来测量尺寸了。
但很多程序员都会推卸责任，说标注是美术的事情。
还是需要讨论一下如何标注。标注有主要有 3 种，颜色、字体、尺寸。
颜色标注
颜色应该先定义一个色板。比如按照下面方式
[颜色色块] #bcbcbc。用于文字。
[颜色色块] #ff8c0f。主色调，橙色。
[颜色色块] #dddddd。主要用于列表项的分隔线颜色。
其中[颜色色块]，就是一个小色块，用来看颜色的预览。
之后在设计稿的预览图中，就可以使用颜色编号来标注。这样标注比较清晰，一个项目中出现的颜色不会出现太多中，基本不会超过 10 种颜色。这样也容易跟程序对应起来，程序写这些界面，也需要定义一个色盘。这种方式也容易切换主题。比如白天模式和夜间模式。
字体标注
字体也应先定义出一个字体的字体盘，比如：
系统字体，14号。主要用于文字的内容。
系统字体，18号。用于文字的标题。
等宽字体，14号。用于显示时间。
之后在设计稿的预览图中，就可以使用字体编号来标注。一个项目的字体也不会出现太多，大概也就 5、6种。这样也容易跟程序对应起来。
尺寸标注
只需要标注一些不会变化的地方尺寸。比如按钮大小，边距、图标大小等，无论屏幕多大，都是固定不变的。而一些随着会拉伸的地方，就直接注明会拉伸。间距之类就注明，哪几个间距是一样的就行。
有些需要等比例放大或者缩小的，就注明一个比例。
标注就如同程序中的注释，并非越多越好。假如是可以看预览图就明白的，其实是没有必要做标注的。
最后
设计图只是参考，最终以跑到机子上的效果为准。设定规则的时候，需要大家一起参与制定，共同遵守，并解释好为什么需要这样做。
其实我清楚，现实中的项目，是不会这样理想的。往往会相互扯皮，推卸责任。一个项目，需要一个了解设计和程序两方面的强有力的人来协调，并在有纠纷的时候可一锤定音。这个人就是所谓的产品经理。
但现实中的产品经理往往是不了解设计，也不了解程序，并没有决策权，这种所谓的产品经理光有个名字，其实是没有什么用处的。而有了决策权之后，也需要承担义务，当决策错了的时候，最大的责任就在产品经理。而错的次数多了，这个产品经理就不能让人信服，也基本无什么用处了。
