讲一讲如何进行模块化开发的

以下分3种做法讲解(每个模块对应一个私有git仓库)

• 1.通过cocoapods拉取模块代码
• 2.使用git拉取代码，通过cocoapods将代码引入到工程
• 3.使用git拉取代码，引入多project

1.通过cocoapods拉取模块代码,如下图所示

通过cocoapods拉取模块代码.png

此种方式所引发的问题就是

1.比如如果我想修改AAAA模块的代码，我只能打开AAAA私有pod的project，然后进行修改，不能在主app(主app即是正在开发的LSAppiPhone)内进行修改，当修改完提交到仓库里还得修改版本号，然后回到主app，通过pod update来获取修改后的新代码，得来回切换多个project，如果牵扯的模块多，那问题更严重了(当然有的人说可以在主app修改，修改完拷贝到私有pod的project项目里，这样是可以但是容易引发一些问题，拷贝遗漏，而且大量拷贝使用起来也比较麻烦)
2.在调试的时候比较麻烦，不能结合主app

2.自己拉取代码到本地，然后将文件引入

图片4.png

图片3.png

此时可以在主app里进行修改home模块的代码，然后提交home的git仓库
会引发的问题

1.如果只是修改已存在的文件还好，修改完提交，其他同事拉取home的git仓库即可，但是一旦牵扯到新增文件，其他同事拉取home的git仓库，只能在finder里看到新增的文件，在主app里看不到新增的文件，因为没有进行重新引用新的文件

1.新增文件，Pods.xcproject也会发生变化，可以将主app的git仓库也进行提交，此时其他人拉取主app仓库和home仓库，就可以获取到工程引用的新文件配置了
2.不提交主app仓库，只提交home仓库，其他人拉取home仓库，通过注释pod 'home', :path => '../home'然后终端执行pod install，在取消注释在pod install即可手动将新增的文件引用到主app(如果不注释，执行pod update也是不好使，因为pod update是检测是否有新版本，没有新版本则啥也不做，当然你可以每次提交都改下podspec里的版本号，但是这样并不现实，也没有这么做的)

如果非要使用第2种方式开发，那么新人到公司拉取主工程，主工程并不包含子模块代码，需要有个配置文件(存放每个模块对应的git地址)，然后写一个脚本遍历文件，git拉取子模块代码，然后执行pod install将子模块代码引用到工程

3.采用多project方式开发

将home.xcodeproj拖拽到主app里，如图

图片5.png

然后还得做如下设置，将主app与home关联起来

图片6.png

图片7.png

图片9.png

此时就可以在主app引用home里的头文件了，此时在用相同办法引入mine模块

图片10.png

此时要在mine模块引用home模块的类
还需要做以下事情，创建xcconfig文件，project不需要设置xcconfig，target设置xcconfig文件即可，如下截图所示

图片11.png

image.png

内容如下，可以从主app的config，拷贝以下内容过来，就可以引用home的类了，当然正常开发是所有模块都创建配置文件，操作相同的步骤，就可以互相引用了

image.png

或者按下图所示从主project里的xcconfig拷贝过来，保证所有的project里的内容都是一样的，且Header_search_paths最全包含所有project里的内容

image.png

正常开发配置是使用脚本将内容统一修改成和主project xcconfig内容一样，仅有一处不同需要特殊处理，具体看下面

子project使用Pods里的代码

• 如果添加的子project想要使用pods里的代码，需要修改对应的xcconfig以下内容，即使不使用，最好也配置一下，以防后续编译报错懵,

• 修完完一处之后将内容拷贝下来，然后将所有的子project的xcconfig(debug,release)内容都统一修改， 粘贴过来

  
  
  image.png

其实就是修改PODS_ROOT定义的目录，因为PODS_ROOT如果直接用从主project拷贝过来的内容的话，${SRCROOT}/Pods的定义是指向当前project目录，而不是主project的目录，而xcconfig里header_search_paths的配置用到PODS_ROOT，所以配置不对的话，就访问不了主project Pods里的内容

image.png

第3种开发方式优点

1.一个窗口开发多个模块
2.修改哪个模块就提交哪个模块，其他人拉取此模块即可(因为提交的时候连xcodeproj也提交了，所以其他人拉下来会看到新增的文件)

tips

HEADER_SEARCH_PATHS 规则：

• 先从target寻找配置
• 如果target中配置了$(inherited)，且存在xcconfig，而且xcconfig中设置了HEADER_SEARCH_PATHS，则$(inherited)代表继承于xcconfig中的配置，xcconfig中配置的$(inherited)代表继承于project，所以配置xcconfig，要确保target中配置了$(inherited)才能找到xcconfig中设置的值
• 如果xcconfig中没有设置HEADER_SEARCH_PATHS或者没有xcconfig文件，则target中配置的$(inherited)代表继承于project
• project 如果配置了xcconfig文件，那么project中$(inherited)代表继承于配置的xcconfig文件中的配置
• project配置的xcconfig文件中$(inherited)代表继承于默认值，当project没有配置xcconfig文件，project配置的$(inherited)`也代表继承于默认值

总结

当然几种方式可以灵活运用，可以先使用第一种方式拉取代码，拉取下来的是framework加快编译，可以切换成源码形式，此时那个模块使用第3种方式，对于图片资源可以有个独立的git仓库管理所有模块仓库图片，因为不需要有产物(framework),使用第2种形式，改完提交，别人拉取即可。

image.png

因为图片资源都是在xcassets里，所以别人拉取代码的时候会看到里面新增的图片，这点和代码不同

注意点 下图xcconfig文件里的内容，在执行pod install后，会被pod移除掉，因为那里只会存放通过pod引入的文件，所以我们目前是自己有个脚本封装了pod install，是先执行pod install，在将该有的内容填充进去

image.png