此系列文章均整理、精簡自pluto-y大神的博客，感謝大神~

一、隨便聊聊
年前到現(xiàn)在大部分時間都在整理和抽象之前項目的代碼，那酸爽，真是夠夠的。主要是公司產(chǎn)品是做定制版的本需求，而前期對定制的內(nèi)容需求太不明確了，導(dǎo)致領(lǐng)導(dǎo)先說前期就用不同代碼管理不同的定制版。最后我們這里中英文版就有6套代碼，導(dǎo)致管理起來特別不方便。而之前在寫代碼的時候完整體的框架是寫好的，可是在細節(jié)上的封裝來說就差太遠了。導(dǎo)致整個代碼的耦合度太高了，這段時間抽象起來相當(dāng)痛苦。所以現(xiàn)在就開始對項目進行模塊化管理，保證各個模塊之前可以重用和替換，并且之后根據(jù)客戶需求只加載用戶需求的模塊。
最后我決定采用Cocoapods對各個模塊進行管理，采用公有庫和私有庫共存的狀態(tài)。然后在添加配置文件以及一些Runtime的機制進行管理。
而對于一個公司的核心代碼來說，當(dāng)然不可能采用公開的形似來進行管理對已的框架。所以在Cocoapods中，還有另一種方式提供給公司內(nèi)部管理進行管理代碼，那就是私有庫(Private Pods)。
二、知識點
1. 創(chuàng)建私有倉庫
a. 不管是私有庫還是公有庫，關(guān)注點都在于Podspec文件的書寫。
b. 在創(chuàng)建私有庫之前，需要先創(chuàng)建一個倉庫(Spec)存放私有庫。
i. 先創(chuàng)建一個私有倉庫 - pod repo add '倉庫名' '倉庫地址'
ii. 通過cd ~/.cocoapods/repos這個目錄里面檢查是否創(chuàng)建好具體的私有庫
c. 寫代碼->寫Podspec文件了->檢查項目和Podspec文件->打tag
d. 提交項目到自己的倉庫里面 - pod repo push '私有倉庫名' 項目名.podspec
2. 私有倉庫的其他操作
a. 刪除私有倉庫:pod repo remove [name]。
b. 在普通項目中如何使用私有倉庫，可以在Podfile里面的開頭聲明所有包含的倉庫名,即利用source參數(shù)
3. 開發(fā)模式
a. 意義：不用每次更新私有庫都提交tag + pod update更新
b. 方法：將引用路徑修改成本地路徑 -> 將Podfile中的pod '庫名', :path => '本地路徑'
c. 通常的修改代碼中不需要執(zhí)行pod update，但是如果修改了目錄結(jié)構(gòu)（添加、刪除或者移動文件文件）、Podspec文件配置的話，最好是打個tag運行一下pod update
d. pod 'iOS-Echarts', :path => '../iOS-Echarts'
4. 使用私有庫兩種情況
a. 正常使用私有庫：在Podfile中引用私有庫
i. # Podfile文件
# 公有倉庫
source 'https://github.com/CocoaPods/Specs.git'
# 私有倉庫
source 'https://192.168.0.100/TestPrivate/Specs.git'
b. 私有庫中使用私有庫：在Podspec文件中依賴(dependency)私有庫
i. Podspec文件中沒有指明所依賴私有倉庫的存放地址
ii. 需要在驗證和上傳私有庫的時候進行指明，命令：
1) （可以采用開發(fā)者模式方法）pod lib lint 項目名.podspec --sources=https://github.com/CocoaPods/Specs.git,192.168.0.100:Plutoy/Specs.git
2) （不能采用開發(fā)者模式，只能通過打tag之后才能進行使用方法）pod repo push --source=https://github.com/CocoaPods/Specs.git,192.168.0.100:Plutoy/Specs.git

三、CocoaPods用在模塊化管理
關(guān)于模塊化管理，其實對于一個人力資源特別緊缺的公司來說還是挺有必要的。特別是遇到我這種需要定制版本的管理的公司，如果對于模塊管理比較妥善的情況下，其實會為公司的人力資源和時間資源節(jié)省非常多的時間。本人確實有親身經(jīng)歷，在經(jīng)歷了6個版本，可是核心功能相同的情況下，公司之前采用的是6套代碼進行管理。從而產(chǎn)生了很多不必要的重復(fù)工作和人力資源的浪費，因此特別有必要對項目的各個模塊化進行拆分和管理。 其實也有小伙伴跟我提過說用framework或者.a等框架形式不就好了么？可是對于framework要進行版本管理以及多地方引用的管理情況下，很多情況下都會忘記了當(dāng)前大的包對應(yīng)的是倉庫管理里面的哪個版本，因為有可能我們經(jīng)常打tag的時候，小修改還是會用同一個版本號，所以會出現(xiàn)很多誤差性的情況。而通過Cocoapods進行管理的話，就可以追蹤到倉庫管理里面的具體提交號、版本號、branches等情況。
對于我們公司來說，由于有定制版的存在，所以我們基本上是封了很多小的私有庫，如藍牙模塊，訪問服務(wù)器模塊，一些視圖、第三登陸分享等。當(dāng)然也有對于大的核心版本封裝，如果整個App的核心功能的分裝，當(dāng)然通過模塊也有可能分為秤的模塊、手環(huán)的模塊、血糖計血壓儀的模塊等等。當(dāng)然這些大的模塊中也都會引用小的模塊然后最后根據(jù)Cocoapods配置以及plist文件進行掃描之后產(chǎn)生需要對應(yīng)模塊的版本，最后在通過代碼掃描機制進行初始化項目。當(dāng)然項目中還用到一些“黑魔法”和Runtime的一些知識，有興趣的小伙伴可以去看看資料，或者聯(lián)系我。
不過在進行模塊化管理的過程中需要注意一些點：
? 模塊中不能出現(xiàn)循環(huán)依賴，即A依賴B，B依賴C，C依賴A的情況
? 如果一個子模塊引用，需要填寫完整的模塊名，如在Core模塊下面有Controller模塊下面有個Setting模塊，并且整個庫的名字為TestProj的話,則依賴的名稱需要這樣寫s.dependency 'TestProj/Core/Controller/Setting'的形式
? 如果出現(xiàn)模塊特別多的情況下，在驗證過程中，竟然采用--subspec=子模塊名來進行一個模塊一個模塊驗證，特別是對于如果只改動了一個模塊的情況下，這里所說的字模塊名也和上面一點異樣，要填寫完整的模塊名
? 在寫私有庫的過程中，竟然不用prefix header的形式，因為在分子模塊的過程中很容易出現(xiàn)忘記引用header而出現(xiàn)的Error
? 最后一點，多google，少百度，太多資料只能通過google查到，而在百度里面完全查不到
寫在最后
到此為止，關(guān)于Cocoapods的使用，從使用者到最后的自己開發(fā)自己的庫的教程就到此為止了。里面包含了很多內(nèi)容，有些內(nèi)容可能寫的不夠清楚，不過大體上這個也是說說我使用Cocoapods的教程，如果中間出現(xiàn)什么疑問或者錯誤，歡迎小伙伴留言或者聯(lián)系我。 當(dāng)然除了Cocoapods外，還有另外兩個Carthage以及Swift Package Manager依賴管理工具，有興趣的小伙伴可以研究一下。這兩個管理工具都是針對動態(tài)庫，所以一般都是在iOS8以上，對于要兼容iOS7以上的小伙伴(包括我)來說是一個不利的地方，但是Carthage的使用比Cocoapods方便。你只需要保證你的代碼能編譯通過即可。至于Swif Package Manage本人沒用過，不敢多說什么。不過竟然學(xué)了這么多的內(nèi)容，希望小伙伴們還是可以學(xué)以致用，即使不能用在公司的項目，也可以考慮用在為開源的事業(yè)盡一份力的程度上，至少讓中國的開發(fā)者能在開源的方面不落后其他國家的小伙伴。

此系列文章均整理、精簡自pluto-y大神的博客