UI素材与代码解耦的讨论与思考
个人对UI素材和代码的解耦的一些粗浅的看法。比如：解耦方案、是否该解耦。
起因
群里听到有人讨论这个话题，当时觉得比较新鲜，就十分好奇的请教了两位经验丰富的@kkk、@AK，虽然未得其中真髓，但是也得到一些自己的思考。总结一下两人的方案，以及自己的思考，
问题
代码内部引入的素材属于设计管理，代码则是码农管理，从这个角度来说两个工做都有码农管理则是一种耦合，为了减轻设计师频繁更换素材而带来的码农的无休止的协作，所以可以进行着方面的解藕。
解决方案
哪坏哪补。有问题就会有解决方案。群中说的方案一由于当时不方便，所以并没有弄明白。方案二、方案三是自己的一些解决方案。
方案一
群中讨论的是素材、代码放在一个仓库，分支不同，使用脚本进行整合(其实并没有想明白怎么弄。。下周请教一下)。另外，@夏汁泡泡 还有一个简化就是这个处理的脚本可以放在Add Run Script Build Phase，暴露出来已知的问题：
- 操作麻烦
- 图片可能重复
- 命名规范
方案二
按照Pods的集成方式，可以将素材看作一个第三方库，直接将素材做成一个bundle，采用Pods私有库或者其他方式放入工程。暴露出来已知的问题：
- 什么时候更新这个bundle
- 多人合作时这个bundle冲突问题
- 命名规范
方案三
工程使用xcassets进行素材打包，然后使用子库进行持续集成。这样，设计师的素材可以放在另一个独立素材仓库，内含更新脚本，直接将素材生成对应的xcassets结构，并上传至子库。这样设计师做完素材直接扔在文件夹中，自动或手动跑一下脚本即可更新到素材仓库。暴露出来已知的问题：
- 由于没有测试过，不知道如果素材比较多的话会不会发生冲突。因该不会吧，都是加文件或者修改😂 (有时间去研究一下之后更新)
- 命名规范的问题依旧存在
方案四
__ 字体库 __。最近同事提出关于用字体库去存储素材图片的方案。感觉非常的赞，虽然并未实践，但是这种方案就像emoji一样，不但减少了相同图片内容之间存在多个不同尺寸版本的问题，也能够比较好的进行压缩管理。设计师需要做的就是做出一套字体库，然后将所有的素材图全部按照设计字体的方案进行设计和制作，这样在使用的时候只需要导入一个字体文件就好了。对于这个字体文件如何管理都好说，毕竟只有一个字体文件。字体库的制作方面还不是很了解，所以只提着么一下吧嘿嘿。。
思考
好了，重要的问题来了，上面的问题都是存在命名规范的问题。此问题如何化解呢？
素材的引入需根据素材名写入代码中，那么如何才能不用素材名呢？那时不可能的😝，毕竟你要有一个唯一标识符去标志着一个素材。可能有的人说可以做一个json用来保存代码的命名和素材的命名呀，我只想说MDZZ，那不是有两套需要维护的命名规则么。。得不偿失。
这个命名的问题其实不能复杂化。参看iOS的项目国际化操作，使用一个key作为文案的唯一标识符，需要显示该文案，通过这个唯一标识符就能直接取到。回头看下素材，是不是也能炮制一个呢？
如果素材名字有统一的规则，就不需要这样的key作为统一标识符，直接使用素材名字即可，这样维护一套素材命名规则总比两套更容易维护。所以，直接使用素材名即可。
如果素材不能统一命名规则，那么这样的对照文件存在也是很不错的。话又说回来，要进行UI素材和代码的解耦，素材名都不能统一，还如何解耦，此问题也不存在了。。
退一步，我们的目的是让素材让设计师自己维护，代码不去维护素材。设计师和码农的耦合在于图片本身的交换比较烦。不论采用哪种解耦方案，都是把图片的耦合转换为图片名字的耦合(也可以理解为素材对应的KEY的耦合)。结果是 __ 为了解除一个耦合,而引入了一个新的耦合 __ 。个人认为这样是不靠谱的。。除非有强力的人去推动设计师走标准的命名。
结论
其实这个问题大可不必纠结，如果有强力的人去推动这个标准持续走下去那么这个问题才有价值。如果真的要进行题中说的代码解耦的话，我认为第三种是比较靠谱的。 __ 命名标准、命名标准、命名标准… __。
说明
经验有限，如果有更好的方案，望告知。拜谢！