背景：隨著公司相關APP項目的開展，公用框架的創建與維護越發顯得迫切起來。因為工作中經常接觸使用cocoapods,也知道她其實可以搞定這件事，所以就首當其沖的選擇了基於cocoapods的封裝方案。

Why

• 給工作中封裝的組件一個沉澱的地方。

• 為新項目的開展提供高效的支撐。

• 框架代碼單獨維護，功能點升級更新快捷。

• 一定程度督促自己代碼的組織與優化。

知識儲備

• 搭建的過程大致參考了這篇教程：使用Cocoapods創建私有podspec。

• 教程非常的細致，很贊的分享。其中有幾個地方可能會有點疑惑：

Podfile中specs引入方式

1.:path=>的引入方式

會添加到DevelopmentPods中，並且復制整個私有庫的文件組織結構（文件夾嵌套關系都會保留）,這種引入方式非常適合於私有庫的開發階段，因為這種方式引入的其實就是實際私有庫的源文件，在demo項目中通過這種方式引入，充分測試私有庫的相關功能會非常方便快捷。

對強迫症患者來說可能會覺得有點不完美的地方，就是當specs中包含subspecs的時候，用這種方式引入時，會出現一些多余的文件層次嵌套。。。感興趣的患者們可以去試一下。。。

2.常規的引入方式

常規的引入方式這裡就不多說了，它走的是另一個極端，會剔除庫中的文件組織結構，而簡單的劃分了源文件與資源文件，如果包含subspecs，只保留子模塊名一級的文件層次，模塊內部的文件結構將不復存在，這裡暫時沒有找到合適的解決辦法保留原有組織結構。

比如上圖的結構，發布之後將改變為：

子模塊劃分思路

先說結果，大致是按照這個思路進行劃分的：

1. 網絡（剔除具體API調用部分）

• 添加樣例

• 包含常用插件（network狀態標識等）

• 緩存

2. 模型映射

• 統一API調用規則

• 封裝公共響應處理邏輯

• 對於錯誤類型的統一處理

3. Hybrid

• 資源的預加載（js, css等）

• native能力開放

4. UI

• HUD

• Tab

• 側邊欄

• Nav常用操作

• 下拉上拉

• Autolayout封裝

• datasource封裝

• 常用動畫轉場

5. 安全

• 加密解密

6. 統計

• swizzling添加打點入口

• 日志記錄模塊封裝

• bug收集分析

7. 動態性

• 熱部署方案

主要基於目前涉及項目主要關注的部分進行了一些拆解，每個模塊直接可能存在依賴關系，這塊cocoapods也貼心的幫忙搞定了，例如:

s.subspec 'APIModule' do |ss|
    ss.source_files = 'Classes/APIModule/**/*.{swift,h,m}'
    ss.dependency 'Moya', '~> 6.5.0'
    ss.dependency 'HanekeSwift', '~> 0.10.1'
    ss.dependency 'NetworkActivityIndicator', '~> 0.1.6'
    ss.dependency 'MonkeyKit/UtilModule'
    ss.dependency 'MonkeyKit/ModelMapperModule'
    ss.dependency 'MonkeyKit/SecurityModule'end

框架會根據將來的實際使用情況再進行優化調整，逐漸完善起來。

下一步

本輪主要是基於基礎功能模塊的拆分封裝，其實對於APP群常用的業務模塊也可以做相同的工作，比如登錄驗證模塊或者邏輯的封裝等。通過對於公用業務場景的思考，逐漸提煉出可以產品化的地方，然後塞入公用庫，將大大提升相關APP群的開發效率與產品質量。