概況

眾所周知組件化是個好東西，它把項目拆分成多個模塊，讓每個模塊能夠獨立出來解除各個模塊之間的耦合性，作為每個獨立的模塊不僅僅能夠使用組合的方式去組建各個不同的功能組合(前提是各個組件劃分的顆粒度只要足夠小)，而且能夠獨立出來運行，在開發運行以及測試中極大的提升了開發效率，讓整個項目在維護上變得方便，而且整個項目的擴展性變得更健壯。

在 iOS 中可以通過 Pods 管理各個組件，Pods 的原理不做介紹，重點說在制作組件的方法與實踐。

相信大部分項目在創建的時候，可能都沒有將組件化的工程架構放入其中，因為起初的項目可能并不大，用簡單的多人協作開發模式加上代碼架構模式(如 MVC/MVVM/MVP 等)進行項目的開發，這樣速度快，開發周期短，更符合敏捷開發的原則，所以一開始可能并沒過多的去考慮組件化。但是隨著項目的不斷壯大，項目中不斷加入新的功能，慢慢的就會發現項目的編譯時間越來越長，各個功能的耦合性也變得越來越高，最為頭疼的是，假如有需求要求某個功能模塊抽出來單獨的去集成到公司的另一個產品中，由于一開始的項目架構設計造成的代碼的關聯耦合，根本無法進行模塊化的抽出，是不是得崩潰到哭。每一次痛苦的歷程總會沖擊出新的解決方案，于是組件化的搭建開始了。

使用 Pods 搭建組件的背景分兩種：

1.正在開發的項目轉變成組件

2.空白項目，從0到1構建組件

對于第一種，老項目遷移成組件架構模式，可以分成三步：

1.重構項目，分離出各個模塊，劃分清楚組件構件(可以通過使用路由思想完成組件通信的解耦)

2.抽出組件分離出主項目，將組件制作成Pods 管理的私有庫，并發布模塊組件版本

3.主項目使用 Pods進行各個組件的集成

第二種就相對簡單點了，省去了第一種的第一步(這是個耗時耗力的過程)，直接在創建整個項目的時候構建出各個組件，于是就變成了兩步：

1.將組件制作成 Pods 管理的私有庫，并發布模塊組件版本

2.主項目使用 Pods 進行各個組件的集成

由于 Pods在創建私有庫的管理時候需要綁定git實現創建，所以整個項目需要依托于 git 管理。以下的搭建是在當前項目處于 git管理中的操作。由于 github 創建私有庫需要 money，所以這里我選用了其他的git托管，有很多代碼托管網站可以使用，我用的是 Coding。

搭建簡述

Pods的搭建組件步驟如下：

1.本地創建私有的 repo 倉庫(需要與遠程 git 托管地址綁定)

2.創建并配置當前的 pod 的 .spec文件

3.驗證當前的.spec 的有效性

4.發布當前的 pod 版本(默認會推送到遠端)

搭建詳情

本地創建私有的 repo 倉庫

打開 term 控制臺，通過執行如下命令進行本地私有的 repo 的創建

pod repo add LCProjectSpecs https://git.coding.net/lccdl/LCModulLearnDemo.git

執行完成如下：

創建私有庫

執行命令之后，我們可以打開本地的 repo 查看私有的庫是否創建成功，使用如下命令：

cd ~/.cocoapods/repos

結果如下:

私有庫查看

創建并配置當前的 pod 的 .spec文件

在創建私有的 pod之前我們需要進入當前的模塊所在的文件夾，然后執行如下命令進行.sepc 文件的創建

pod spec create https://git.coding.net/lccdl/LCModulLearnDemo.git

執行完成之后，當前目錄下會出現一個.spec 文件，用編輯工具打開它，它是一個ruby格式的文件配置可以按照如 下進行配置

Pod::Spec.new do |s|

s.name = "LCModulOne" #當前的 pod 名字

s.version = "0.1.2" #pod版本

s.summary = "測試" #描述

s.description = <

模塊化開發

DESC

s.homepage = "https://coding.net/u/lccdl/p/LCModulLearnDemo"

s.license = { :type => "MIT", :file => "LICENSE" }

s.author = { "lccdl" => "lcc_dl@163.com" }

s.platform = :ios, "8.0"

s.source = { :git => "https://git.coding.net/lccdl/LCModulLearnDemo.git", :tag => s.version.to_s }

s.source_files = "LCModulOne/LCModulOne/Classes/*"

end

驗證 specs 的配置是否正確

這里可以通過兩個命令來進行驗證，兩個命令分別針對本地與遠端的驗證

pod lib lint #驗證本地 pod 配置是否正確

pod spec lint #驗證遠端 pod 配置是否正確

這里有一個坑點，就是可能在本地驗證 pod lib lint 的時候一點問題沒有，但是在進行遠程 pod spec lint 驗證的時候會出現如下的錯誤提示：

image.png

這個問題可能是source_files對應的遠程的路徑沒有填寫正確造成的，本地驗證的時候，source_files對應的路徑的起始路徑是當前路徑，而source_files在遠程驗證時對應的目錄的根目錄是 git 的根目錄(不是當前的 spec文件所在的目錄了)，所以可能在驗證當前的遠程的目錄的時候可能會出現問題，只要把目錄的路徑寫對就好了。

發布 pod 管理的組件版本

驗證成功之后，可以通過以下命令進行當前版本的發布。

pod repo push LCModulDemoSpecs LCModulOne.podspec #LCModulDemoSpecs 是本地的私有庫 LCModulOne.podspec 當前的管理模塊的 pod

pod發布

當驗證 pod 配置文件沒有問題之后，會將當前 pod 發布到當前的私有庫LCModulDemoSpecs中，同時此時會默認推送到 git 的master分支中(無論當前處于哪個分支下，都會推送到主分支)。這一步完成之后，我們就可以通過搜索 pods來進行正常的 pod的模塊依賴了。

組合不同的模塊進行不同模塊的開發

一旦發布各自的模塊版本之后，那么參與項目的其他的人就可以通過 pod 來加載不同的模塊功能進行開發了，不過因為是私有庫，所以在進行pod安裝的時候，需要指定私有庫的地址，使用的時候編輯 podfile，內容如下：

# Uncomment the next line to define a global platform for your project

platform :ios, '9.0'

source '[https://git.coding.net/lccdl/LCModulLearnDemo.git](https://git.coding.net/lccdl/LCModulLearnDemo.git)'

target 'LCMainRootModul' do

# Uncomment the next line if you're using Swift or would like to use dynamic frameworks

# use_frameworks!

# Pods for LCMainRootModul

pod 'LCModulOne'

end

以上說的是已有項目的使用 pod 進行組件化，如果是新開發的某個模塊需要進行 pod 組件化，可以通過 pod 自帶的一個命令去創建，這樣創建的組件就自帶 Demo 工程以及配置文件了。命令如下：

pod lib create podTestLibrary

創建的時候會問你幾個問題，直接按需要回答就好了，四個問題如下：

1.是否需要例子工程(建議保留，開發組件的時候需要用到)

2.根據需要選擇一個測試類型

3.是否要基于 View 進行測試

4.類的前綴

創建完成以后，目錄層級如下：

使用 pods 命令創建

開發迭代維護

在開發組件過程實際就是迭代 Pods 庫的過程，我們在每個組件的實例工程中進行當前的開發，開發完成后通過發布組件的版本既可。在開發的時候由于組件在開發過程中，所以我們在開發自己的組件的時候，可以通過設置本地路徑的形式去關聯正在開發的組件文件，如下：

use_frameworks!

target 'LCModulOne_Example' do

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

target 'LCModulOne_Tests' do

inherit! :search_paths

end

end

當前的工程 update之后，例子工程中就有了正在開發的pod了，如下所示：

開發 pods

這里要注意，每次在往開發的 Pods 中添加文件的之后都需要通過 pod update 命令更新本地的正在開發的 Pods, 否則實例工程中可能出現找不到當前的文件。

在利用 pod 進行組件化的遷移過程中，由于在進行組件發布的時候會默認推送到當前組件所在的 git 的 master 分支，如果此時 master 分支作為線上發布版本的分支的話，我們是不希望該分支有任何的代碼入侵的，響應的我們可能希望當前的pod 發布只在當前的開發環境分支進行，master 不摻雜任何開發過程中所出現的代碼，為此，可以通過創建兩個 git 的方案去解決這樣的問題，一個 git 作為組件的開發版環境，另一個 git 專門作為發布環境只進行組件的集成與發布。如下圖展示：

發布環境與開發環境處理

靈活的組件遷移組合方案

相信在進行組件化的工程項目一般都已經很龐大了，如果進行全盤遷移的話，時間上可能很長久，再者伴隨的不定風險或許很大(涉及到項目的重構)，所以結合之前各自項目的架構特點再去聯合組件化思想對項目進行遷移是明智之舉。組件化的根本目的是解耦項目各個模塊間的耦合度，所以順著這個思想，找出項目中耦合度最高的模塊進行遷移才是重中之重。

其實在一般工程在起初創建的時候都已經做到了降低耦合度的構建方式，例如將一些工具類、或者通用的模塊設計成項目的底層構件服務于上層模塊，這些底層構件不依賴與上層模塊，就已經做到了很好的降低耦合的目的，這樣的設計有著層級架構的特點，所以通過層級架構+組件化構建的方式靈活的去降低項目的模塊間的耦合性也是很實際化的選擇，而且對比全盤遷移組件化時間維度與可控性上要占據更大的優勢。總之，對于不同的項目要合理的利用當前項目架構特點再去與組件化思想相結合來進行才是靈活變通的根本。

組件化Pods構想

一旦使用了 pod 構建自己的組件之后，會發現真的停不下來，正式因為組件化的構建思想，就會很自然的想到利用 Pods 去將自己工程中通用的模塊做成一個組件，然后通過 git 進行管理，一旦去接受一個新的項目的時候，完全可以通過pod將需要的不同模塊的東西引入到新的項目中(例如網絡庫的封裝、基本工具類的封裝、常用的宏腳本)，開發效率也就得到了大大的提高，而且體現了一種前期積累后期建樓的生活哲理不是。

參考資料：

總結

以上是生活随笔為你收集整理的android pod 组件化_使用 Pod 实现私有模块化管理（组件化 Pods 实现方案）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。