ios pod组件化和本地私有库的利弊

项目在告一段落的时候，我想把已经拆成模块的项目文件

拆分到pod库里面去

当初我没拆分到pod库 ，最开始是因为pod库要上传到公开

后来知道了码云，知道了可以上传到私有的服务器，

但是公司的项目是svn维护的，并没有这样的权限，自己擅自做也不太好。

再后来偶然发现 pod库其实是支持本地pod的

创建一个pod库 只需要 编写命令

pod lib create

这时候 按照官方的提示 创建一个模板就好了，

会发现里面的路径就是本地的路径

  pod 'LDSBase', :path => '../'

比如说上面这个，就是说这个base的模块 的路径就在当前的上级文件夹。

pod 是一个一个的组件 ，每个之间存在相互依赖的关系

这些依赖关系 改怎么添加呢

这就提到了

.podspec

这个文件， 创建pod库的时候会把这个添加出来，

如果没有在这个文件夹中添加依赖关系，就算你pod 了 masonry 类的库，

但是你的pod 是找不到 masnory 的路径的，会爆红，编译不过。因为lib search path 里面没有

这层关系，所以必须在 .podspec 中写这个依赖s.dependency 'Masonry'

我们由此可以知道 这个 .podsepc的文件 是cocopod 在xcode 编译阶跑自定义shell脚本的阶段

需要用户自定义的一些参数设置，如果没有这些参数设置，那xcode 自然不会注入这些关系

你可以理解为 配置表，针对你要创建的pod库的单独一份的表

而你的资源 就放在source_files 这个文件夹下 也是配置表来决定的

我这里展示一个我的配置表的部分参数

  s.ios.deployment_target = '9.0' // 9.0以上的系统
  s.source_files = 'LDSBase/Classes/**/*' //资源在source 文件夹下
  s.resource_bundles = {
    'LDSBase' => ['LDSBase/Assets/*.{png,xib,plist}'] //bundle 资源包含了png xib plist
  }
    s.dependency 'Masonry' //依赖了第三方库 masnory 和beehive 
    s.dependency 'BeeHive'
    s.libraries  = 'icucore' //依赖系统的资源icucore

如果遇到问题 可以看看是不是参数配置出错了

注意到bundle 里面包含了png xib plist 文件，是因为pod库的xib 不会出现在mainbundle 里面了

所以需要 用 当前class 的bundle 里面去找，而xib 这些东西都需要打到bundle 包里面，才能在项目里

被识别，我讲这些 是粗略的思路 ，具体代码建议去搜索一下、

做pod库尽量减少xib ，避免过多的处理xib的工作。

 s.source_files = 'LDSBase/Classes/**/*' 

就是你pod库的文件夹 ，你的这里面的文件会被编译到pod里面，当然你可以自己改写这个路径，最好

统一按照这个格式来

接下来就是漫长的迁移过程，你需要不断的创建pod 库 然后 把代码移动过去，然后编译通过，再pod

到你的主工程目录，直到 主工程目录只剩下appdelegate 文件夹，这个过程大约需要3 天，因为 会遇

到各个pod 之间存在相互引用的情况，xib的修改。pch 因为无效了，所以需要到处添加masnory头文

件。然后迁移回去需要在主工程里面全部测试一遍。

pod库 首先是需要先创建 pod 的base库 的 这些包含了socket afn 弹框基础类， uibase类等等，其他

pod库需要依赖这个base pod库再继续使用，不然每个库自己折腾一份，会非常麻烦。

至此 整个本地库的迁移就完成了。

迁移完成的下一步 是将各个模块之间的耦合 改成 target action 来处理。

再谈一下 pod组件化的一些弊端

组件化最初出现的目的是 解除耦合，让团队的成员 各自维护自己的pod库，来避免相互依赖

从而做到不熟悉整个项目，而能够开发的目的。

我认为存在的弊端：

1.如果没有每个人懂得pod 组件化的过程，就很难各自维护，除非把整个pod的过程写成自动化脚本。

2.基础通用的base 类的艰难维护， 我们知道base类是增长型的，比如会增加很多不可预知的分类。

或者增加一些新的 网络协议的封装，而这些都是依据业务需求来建立的，像弹框可能存在多个版本，

这些不会在项目初期就建立起来。而是边做边出现的，遇到这种情况，就必须增加base 的部分，重

新pod install base 类 这时候，所有的业务pod 就都需要pod install 一遍 才好继续使用，这样base 类

就变得牵一发而动全身的问题。
3. a库放在那里的问题，通用的png 文件放在哪里的问题，有些。a的静态库 一开始 只是一个模块在使

用的 这样打到业务pod就好，但很有可能后期就需要打到其他业务里面，这样不得不打到base pod库

里面，这样会造成base pod库 越来越大， png 文件放在base pod里面其实不太好，可能下一个项目

变了，那应该怎么办呢，目前我也没想到合理的解决方案。

4.除此之外，最重要的一点是pod 拆分力度的问题。 pod 拆分如果过细，那就会造成 tabbar/ login/

home/甚至两三个页面就做成一个pod了 ，为啥呢，因为要各自开发各自的模块呗，一般团队开发各自

模块都是很小的部分了。这样会让整个pod 结构看不出来层次划分， 因为pod 都是平级的。但是不

划分，只划大的模块，那团队之间的项目 还是一个团队维护一个pod结构，和直接维护整个工程都没啥

不同，我认为应该是大模块再拆分小模块，就是pod 库套用pod库的方案，而从外层看不出来里层结构

来解决。

5.之前svn 上是不存pod 的文件的，做了本地的组件化，必须上传所有的pod文件夹，当然这是细节。

我的观点：

其实说到这里我已经说得差不多了，组件化要大团队大项目，然后从一开始就需要开始做起pod 化的部

分 target action 的部分，才能够后续良好的维护。并且要持续做脚本化整个过程的部分。

小团队 费力做这个 实在是吃力不讨好。组件化开发确实是趋势，但是很多我看到的都是伪组件化，或

只是个demo。真正要做好这些还需要很多的工作和心力。后续我还会继续做组件化的工作，也希望

看到这个文章的人想一想我上面提到的问题，不必过度迷信组件化，忘了使用时候带来的阵痛。就像

mvvm 固然好，但也增加了消息传递的成本，mvc 固然不够美感，但用起来顺手是一样的，mvvm 的跨

层通信需要引入 kvo 或者 rac来解决问题，如果rac使用不当 或者理解不深入，还是会引入更多问题，

好的方案 一定是侵入性小，改动小 而带来的效用巨大的，而不是需要耗费大量的人力 做出来 还需要

持续维护的，以上是 我对pod 组件化的理解