自从iOS退出依赖，png就被用来制作图标。这已经是如此简单了，那为什么还会有人会要考虑其他的解决方案呢？ 一般的制作图标的工作流程是这样的：“我想要新添加一个按钮，这个action需要一个图标，设计师把图标发email给我，我们就完工了.” 如此设计师把这项工作安排到了他的工作流之中，然后按部就班完成了这项工作，之后你就会受到一封Email，里面有2个png文件(retina 和 非 retina 屏幕)

等等... 这个图标需在改改颜色，以满足我们想要按钮呈现高亮状态的需求. 因此你重复了上述流程，并获得了另外2个png。实际上，我们还会继续需要让这个按钮在某些特定的情况下呈现禁用状态，因此我们又会需要禁用状态的图标. 好吧，iOS现在又支持@3x分辨率的了, 因此我会需要再输出这些图标及其各种状态的文件… 而设计师现在很忙，短时间内不能为我完成这项工作了 ! 如今不能获得这些资源文件的我如何让我的应用适配新的屏幕尺寸呢

任何曾今为那些以开发移动应用为目标的团队工作过的人，好像大都遇到过上述其中一个或者全部的状况. 它可能会是非常令人沮丧的，也会让你的团队白白浪费许多时间. 在Craftsy这里，我们向后退一步，看看我们尝试真正要去完成的是什么，还要看看我们是否错失了另外一种可能的更好的方法. 而当我说后退一步的时候，我的意思是做一次大的退步.

目标：在屏幕上绘制一个图标，使其像素完美的适配那个屏幕的分辨率.

在最基本的层面上，这个目标就是我们现在正在做的. 然后问题就会是，我们是否使用了最有效率和更加务实的方式完成了这个目标 让我们来看看我们的选择。我们可以继续去构建并维护一个相当简单的图像库，并让从开发和设计两头都承担保持图像库更新的工作量. 或者我们还可以采用一种动态的方式，只去踏踏实实的处理绝对必要的变化和工作，并将时间专注的花在其它问题的解决上.

进入PaintCode, 它是一个 OSX 应用程序，其名字正如你所预想的其功能. 它能解析从PhotoShop创建或导入的矢量图片资源，然后将其”绘制“成一个编码库. 我不会花太多时间向你推销 PaintCode, 我会建议你上网试试他们的在线解决方案. 不过未来在完成移除我们对于图像的依赖这项任务方面，会证明使用它是必要的。看待PaintCode及其价格的一个好的方式就是，就好像它是为你的团队雇佣的一个开发者. 你要问你自己的是 “你会需要雇佣一个开发者，它可以编写完美的可控代码，却只需要开发应用成本负担一次性的花费 ” 好了，那就是我所想的.

设计师们其实拥有的大量的诱人数据，这些数据都隐藏域他们的photoshop文件之中。这些数据被称作矢量图形. 为什么矢量图形很重要呢 简单来讲， iOS的世界里现在正面临的，与分辨率和不同状态效果有关问题，在设计界早就都解决了. 当设计团队创建一个图标的时候，他们很可能会采用一种基于矢量图形的，使用了线条和贝赛尔曲线的方法. 这就能很好的解决创建“分辨率独立 ”的问题. 那样如果我们需要适配屏幕尺寸为1000dpi的图标，或者只是20dpi的缩略图，它都可输出来，而且看上去都是像素完美的!

那么我们就要问了，如果开发者可以简单的胜任这种现有的技术，会怎么样呢 那就会使得我们不用再去过多考虑像素问题了. 虽然这常常成为一种可行的方式, 但和只是持续的绘制和输出图形比起来，使用编程的方式用代码绘制矢量图形需要花费更多的时间，直到 PaintCode 出现才让收益大过支出. 并且，大多数的程序员们都没有进行细节设计的好眼力，所以最终的成果大有可能不会符合预期. 因此，设计团队的存在其实可以促进 PaintCode Objective-C 文件的输出.

而通过管理起开发者和设计师间的所有这些代码，PaintCode一举消除了所有这些问题 ! 设计师只要将他的矢量图形从Photoshop导入PaintCode中，做一些小维护以方便同开发者的对接, 瞧, 开发人员现在可以绘制符合任何分辨率需求的图形资源了.

这一功能开始改变了设计师和开发者之间的沟通方式. 标准一旦建立起来，交谈的内容立刻从 “你能把资源发Email给我吗 ” 变成了 “让我知道你什么时候把那个图标迁入了git ”. 有时候甚至都不要交流；设计师调整完图标之后，应用程序就会帮他把新的版本绘制出来.