iOS图片迁移脚本重构

为什么需要进行重构？之前脚本的不合理之处在哪里？

       1、 之前app的项目工程是一个整体，大部分的业务全部在主工程项目中，对于pod的依赖也比较复杂和多样化。其实，这是不太利于项目管理和优化的，而且之前的图片脚本太过于死板，很多地址的配置直接是写死的，这就造成了，如果pods库稍有变动就需要进行与之对应的修改，这样给维护带来很大的麻烦，造成不必要的资源浪费。

       2、由于app6.6进行了拆包，将主体项目工程进行重构，并且把development下所有的本地pods库迁移到远端并且同源，这样就给重构图片迁移脚本提供了足够便利的条件和支持。

       3、图片脚本本身由于app6.6拆包的缘故已经不可用了。

       综上几点，所以决定将图片迁移脚本进行重大改版，并且加入一些其他附带脚本来辅助更好的管理项目。

重构具体做了哪些工作呢？

       第一，去读取podfile文件，然后找到所有pods的podspec文件。

        这个过程中遇到一些问题和疑惑，因为工程项目庞大，依赖的pods库数以百计，这就造成了有相当数量的pods库是隐性依赖到项目工程中，这样带来的问题就是，在读取podfile文件所获取的pods是不准确的，或者说是不全面的，有遗漏。这样就需要去找到具体哪些pods是由于隐性依赖进入工程的。所以就先去解决如何找到隐性依赖这个问题。开始想着是从profile.lock文件里面去读取，后来发现，这个很复杂而且有可能会出问题，所以直接放弃了。仔细读了下ruby 开发文档，找到一个更加简单的方式去找到隐性依赖了。就是先从podfile里面读取所有pods，然后和LocalPods下面文件除了隐藏文件、Header、带有空格名字的文件夹是非pods，其余文件夹均为pods，这样一对照就可以找到隐性依赖pods了。

       第二，去读取所有的podspec文件，将文件里面的内容转换成json，看resources或者resource对应的内容是否含有.png 、.jpg之类的资源，如果含有bundler或者有.casset文件就直接忽略。

        第三，从满足的podspec文件的资源路径去遍历并找到所有的图片。

        第四，去ImageAssetPod去找到所有的图片并存到一个数组中，然后将从podspec文件中遍历的图片进行对比，找到两者重复的图片并物理删除。

        第五，将重复的图片从podspec文件读取的图片集合中移除，将得到的结果进行迁移到主项目工程的ImageAsset下，然后去Pods-Jovi-resources.sh文件下删除所有从podspec文件读取的图片的资源定义行。这样就完成了图片迁移脚本的重构工作。