Cocoapods多模块开发

阅读此文章之前你需要对cocoapods有基本的了解，这里给大家附上几篇文章：

• IOS依赖管理 - CocoaPods（PS：就在前几天安眠重装了系统，重新安装cocoapods发现跟以前有点点不一样，所以顺便对文章做了更新）
• CocoaPods官方文档－Podspec配置格式

一. 前话 安眠是从去年后半年开始投入到现在的产品当中，前期该款产品只有国内一条产品线，之前搭的框架一直顺顺畅畅也没什么问题，中途公司决定要拓展国际产品线，考虑到业务逻辑的差异化会趋于明显大家讨论后决定国内国际分开两个产品线进行开发，于是直接把当时的代码放到新的代码仓并且开始在这一套代码上面做改动（等我知道的时候其实内心是拒绝的）然后问题就来了。。

当前代码改成国际版也是需要时间的，导致后面国内版跟国际版中间差了几个版本，这种差异引出的问题是，对于通用的模块业务中存在的隐性bug，国内版在后期迭代中逐步修复，但国际版无论如何跟当前的国内版都无法同步，修复或者业务逻辑调整都需要从国内版的某一个或者甚至多个版本中进行选择性同步，这种做法简直丧尽天良毫不优雅！但是有什么办法呢？拆分模块。

二. 拆分模块准备工作 1.cocoa pods安装完毕

2.对podfile文件和podspec文件有大致了解，可参考本文一开始贴出来的附文

3.充分了解产品业务逻辑，找出通用部分以及通用部分的差异处，想不通的最好尝试着画业务逻辑图，这里安眠就不细说，以后有机会可以给大家分享一下

4.准备好新的工程git仓以及各模块的git仓

三. 拆

通过拆分之前的考量，安眠是这样决定的：每个工程都会有一些基类或工具类等在不同工程里都可以复用，把这些代码移植出来做为基类模块，这样以后开发新的产品线可以直接引入该基类模块，对于架构的前期准备工作会节省一些时间；针对安眠开发的产品而言，编辑器是产品里最重要也是可以独立开来的一个工具业务，所以这一块被做为编辑器模块移植出来。开动。

1.代码拆分，新建模块项目，把相关代码移植出来，编译通过

2.模块项目中创建podspec文件 参考CocoaPods官方文档－Podspec配置格式

• 声明依赖第三方库

  s.dependency '＊第三方＊'

• 声明包含代码路径

  sp.source_files = '＊路径＊/*.{h,m}'

• 声明引用头文件

  sp.prefix_header_file = '＊路径＊'

• 声明资源引用路径

  sp.resources    = '＊路径＊'

• 整体podspec格式如下 ```Pod::Spec.new do |s| s.name = '＊名字＊' s.version = '1.0.0' s.license = 'MIT' s.requires_arc = true s.default_subspec = 'Core' s.ios.deployment_target = '7.0'

  s.dependency '＊第三方＊' s.dependency '＊第三方＊', '~> 3.7.3'

  s.subspec "Core" do |sp| sp.source_files = '＊路径＊/*.{h,m}' sp.prefix_header_file = '＊路径＊' sp.framework = '＊系统库＊' sp.resources = '＊路径＊' end end

3.编辑podfile文件

• 本地引用：

  pod '＊podspec的名字＊', :path => '＊路径＊'

4.终端更新cocopods文件引用，这时项目应该大概能跑起来了，跑不起来再找具体问题挨个修复

pod update

四. 遇到的问题

[!] [Xcodeproj] Generated duplicate UUIDs:

解决办法：
终端：export COCOAPODS_DISABLE_DETERMINISTIC_UUIDS=YES

五. 收尾 安眠这里分享的是本地引入，本地引入成功后程序能够跑起来的话，就是完成了一了大半部分，这时可以把本地的模块工程上传到代码仓之后再慢慢修改优化 至于接下来你的主体工程是要通过本地引入还是通过代码仓地址引入就看你们需要喽～

六. 后话 前面有讲到多语言，早在最开始搭框架的时候其实有问过产品是否需要考虑多语言，产品坚决SAY NO，回想起来如果当时的架构坚决采用多语言的话之后就不至于全部重新整理，悲了个催喽。。所以，产品说的话不能全信啊。。