一. 前语
当咱们的项目比较大时，迭代的时间比较长的时分，咱们往往都会对代码进行重构，会对代码进行一次体系的整合和标准的评论，为了之后的开发能够防止写重复的代码，便利代码的维护和扩展等等。咱们会对代码进行清理并规划出一套开发的标准，我想许多公司都有这样的经历。
那资源呢？又有多少人会去考虑对资源怎么进行收拾，便利资源文件的维护和扩展（这里说的资源主要讲的是图片资源）。
二. 为什么要对图片资源进行办理
由于我有触摸过比较小的项目，也有触摸过比较大的项目。假设你的项目比较小，或许涉及引用到的资源不是许多，我也不主张额定花时间对之前的图片资源进行收拾，由于这个流程或许是需求多方进行合作的，简略来说便是杀鸡焉用牛刀。
可是假设项目比较大，不对资源进行收拾，那资源就会比较乱。你想想，比方我涉及的资源，有七八个人碰过这个项目，每个人对待资源都有不同的做法，那得有多乱，到时分一个新入职的一看，都不知道怎么去操作这些资源了，无从下手。
其实这方面最主要的是两个问题，一是标准问题，比方指令，假设有一个灰色的封闭按钮，一个搭档给资源命名grey_close.webp ，别的一个指令close_grey.webp。 然后我新入职的，我写个页面，有个封闭按钮，那我第一反应便是全局选资源文件搜close，然后搜到grey_close.webp和close_grey.webp。并且两个图片，一个略微大一点，一个略微小一点，那我要用哪个，一个个试效果吗？仍是随意用一个？
另一个我觉得比较严重的问题是资源重复的问题。仍是拿上面的比方，我有个close按钮，我写这个页面的时分，我不管三七二十一，我直接再导入一张新的close切图，那项目中就用许多张封闭按钮。我相信有许多人在导入切图之前会去看项目中有没有相同的图片防止重复，但相同也会有许多人为了便利直接导入图片。你能幻想一个项目里面有十几二十张“封闭”的切图是什么体验吗？当然它不影响开发，大不了我要用的时分我再从头导入一张就好（挑选困难症的福音）。
是的，这个问题，不会影响开发流程，但它或许会在某一时刻把你给坑了。 比方我有15个封闭的按钮，我其间5个页面要做换肤。那你是对这5个地方都做操作吗？你必定会想为什么这5个地方的封闭图片长得都相同，为什么其时还要用五张，为什么不共用一张。
三. 怎么做资源的办理
1. 命名标准
我以为每个公司都应该对自己的资源有一套命名标准。假设能够，我希望是整个公司的标准，而不是独自android端的标准，比方一张close切图，android端、ios端、前端都用到了这一张切图，最好便是它们的文件命名标准都相同。
当然命名上也有一些细节要处理，首要你不能独自把一张图片资源直接为了便利而命名close.png。由于我相信你的项目不或许只有一个封闭的款式。你有两张切图
这时分你要只用close去命名，那就很尴尬了，候命那张你就只能玩close2.png这种操作了，一朝一夕，close15.png呈现的时分，你又会陷入懵逼。
然后是款式问题。像上图相同，你或许有不同的图片款式，但他们都表明封闭，你要怎么去命名，这或许不算什么技术，但也算得上一门艺术。比方第一张close，你总不能命名close_in_round吧。
然后是色彩问题。也许你的UI规划师比较喜欢搞活，你的项目集齐了赤橙黄绿青蓝紫黑灰白的封闭按钮色彩。那你要怎么去命名。当然这一块关于Android来说，矢量图是能直接改色彩的。但假设你有引入不同色彩的切图时，你也确实要考虑怎么去命名。
然后是大小问题。或许相同的切图有不同的大小，这个你要出怎么命名呢？这个我其实主张学android的资源文件夹，xhdpi、xxhdpi、xxxhdpi，搞它个几套大小的标准。 你总不能一个项目你的同个款式的大小还能超越六七个吧，那我感觉规划就有问题。
2. 防止重复资源
得尽量防止重复资源，比方说封闭按钮，假定色彩和大小相同的情况下，就这样的
他们基本就长得一个样，假设一个项目里面有个两三张，那我觉得情有可原，或许某些页面特殊要用独自的。可是这玩意长得差不多的你的项目有个七八张，那我觉得过分了，我说的是图中这种差不多的，不算上面那个带圈那种不相同的。
所以开发页面导入切图时，要先去查看有没有相同的图片，防止重复导入。查找图片导入的方法有两种，一是经过查找资源，由于咱们这些搞开发我算3年以上的，至少你命名也和图片有关的吧，比方你总不能搞一张封闭的按钮，和close这些词无关吧。第二种方法比较直观，经过Resource Managaer ,我觉得AS供给这个功能确实用处很大。
用这个必定是能找图片，问题就在于，我上面说的，你一张封闭的切图有十几二十张，我就算用Resource Managaer找到了有封闭款式的切图，我也不知道要复用哪张。
然后上面也有说了，Android的矢量图，是能改变色彩的，所以经过这个方法，相同的尺度和款式，不同色彩的矢量图也是能共用一张的，注意是矢量图。
关于一些款式相同可是长宽尺度不同的图片，便是拉伸的效果相同的图，能够运用.9
3. 切图源头进行处理
其实许多切图的源头，都没处理好，假设说规划师其实知道两个地方的图片是相同的，可是他给忘记了，他也懒得找。所以从头弄了一张切图给你，导致和之前的尺度不同。其实这里图片的源头就出了问题。所以我说这个图片资源的办理是需求多方进行尽力的。
4. 图片办理体系
这一步便是做大了，你的公司有一个图片办理体系，乃至应该叫资源办理体系。当然假设要做这样的体系，也是需求额定的精力和成本。假设公司开发的项目比较小，我觉得花人力物力去做这样一个体系也不值，性价比不高。可是关于一个大公司而言，我觉得有一套这样的体系，仍是挺好的，挺有用的，关于项目的迭代和维护来说。
无论是资源的大小、色彩和款式。咱们假设想仅有标识它，靠谱的不是靠命名，而是ID。没错，假设你要做一个仅有标识，那么ID是最靠谱的。
假设每个不同的切图都有一个ID对它进行仅有标识，然后你有一张表，经过ID能找到对应的资源文件。那你就能办理好资源文件。
从源头UI规划开始，他的每张切图都传到这个体系中，我假定就有3个重要的字段，称号、描绘、文件原。传上去之后体系生成个ID，然后UI规划师传这个切图到规划稿时，就用这个ID命名。之后他做切图能够去这个体系中经过“描绘”去查找有没有对应的切图，有的话就不必从头做，
关于客户端，假设你想要对应的切图，能够经过ID从这个体系中快速的拿到图片。指令时也能够经过ID和描绘命名，比方close_457762.png ，这样就不会有重复的图片资源。
然后假设要做换肤，直接说对哪个ID的图片做换肤，也能很快很清晰的找到。
经过一个资源办理体系，来到达办理一切端的资源绝对是一个很好的做法。可是缺陷便是对该体系的开发和维护是需求必定的成本。
四. 总结
这篇文章主要是想表达出在大项目中资源紊乱的一种常见问题。假设有哪位大佬有比较好的图片资源办理的方法，也希望能共享出来。
