概況

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

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

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

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

1.正在開發(fā)的項目轉(zhuǎn)變成組件

2.空白項目，從0到1構(gòu)建組件

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

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

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

3.主項目使用 Pods進(jìn)行各個組件的集成

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

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

2.主項目使用 Pods 進(jìn)行各個組件的集成

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

搭建簡述

Pods的搭建組件步驟如下：

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

2.創(chuàng)建并配置當(dāng)前的 pod 的 .spec文件

3.驗證當(dāng)前的.spec 的有效性

4.發(fā)布當(dāng)前的 pod 版本(默認(rèn)會推送到遠(yuǎn)端)

搭建詳情

本地創(chuàng)建私有的 repo 倉庫

打開 term 控制臺，通過執(zhí)行如下命令進(jìn)行本地私有的 repo 的創(chuàng)建

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

執(zhí)行完成如下：

創(chuàng)建私有庫

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

cd ~/.cocoapods/repos

結(jié)果如下:

私有庫查看

創(chuàng)建并配置當(dāng)前的 pod 的 .spec文件

在創(chuàng)建私有的 pod之前我們需要進(jìn)入當(dāng)前的模塊所在的文件夾，然后執(zhí)行如下命令進(jìn)行.sepc 文件的創(chuàng)建

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

執(zhí)行完成之后，當(dāng)前目錄下會出現(xiàn)一個.spec 文件，用編輯工具打開它，它是一個ruby格式的文件配置可以按照如 下進(jìn)行配置

Pod::Spec.new do |s|

s.name = "LCModulOne" #當(dāng)前的 pod 名字

s.version = "0.1.2" #pod版本

s.summary = "測試" #描述

s.description = <

模塊化開發(fā)

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 的配置是否正確

這里可以通過兩個命令來進(jìn)行驗證，兩個命令分別針對本地與遠(yuǎn)端的驗證

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

pod spec lint #驗證遠(yuǎn)端 pod 配置是否正確

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

image.png

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

發(fā)布 pod 管理的組件版本

驗證成功之后，可以通過以下命令進(jìn)行當(dāng)前版本的發(fā)布。

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

pod發(fā)布

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

組合不同的模塊進(jìn)行不同模塊的開發(fā)

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

# 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 進(jìn)行組件化，如果是新開發(fā)的某個模塊需要進(jìn)行 pod 組件化，可以通過 pod 自帶的一個命令去創(chuàng)建，這樣創(chuàng)建的組件就自帶 Demo 工程以及配置文件了。命令如下：

pod lib create podTestLibrary

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

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

2.根據(jù)需要選擇一個測試類型

3.是否要基于 View 進(jìn)行測試

4.類的前綴

創(chuàng)建完成以后，目錄層級如下：

使用 pods 命令創(chuàng)建

開發(fā)迭代維護(hù)

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

use_frameworks!

target 'LCModulOne_Example' do

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

target 'LCModulOne_Tests' do

inherit! :search_paths

end

end

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

開發(fā) pods

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

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

發(fā)布環(huán)境與開發(fā)環(huán)境處理

靈活的組件遷移組合方案

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

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

組件化Pods構(gòu)想

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

參考資料：

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。