專案在告一段落的時候，我想把已經拆成模組的專案檔案

拆分到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 元件化的理解