Cocoapods私有仓库封装过程中的思考

背景：随着公司相关APP项目的开展，公用框架的创建与维护越发显得迫切起来。因为工作中经常接触使用cocoapods,也知道她其实可以搞定这件事，所以就首当其冲的选择了基于cocoapods的封装方案。

Why

• 给工作中封装的组件一个沉淀的地方。
• 为新项目的开展提供高效的支撑。
• 框架代码单独维护，功能点升级更新快捷。
• 一定程度督促自己代码的组织与优化。

知识储备

搭建的过程大致参考了这篇教程：使用Cocoapods创建私有podspec
教程非常的细致，很赞的分享。其中有几个地方可能会有点疑惑：

Podfile中specs引入方式

1. :path =>的引入方式

• 会添加到Development Pods中，并且复制整个私有库的文件组织结构（文件夹嵌套关系都会保留）,这种引入方式非常适合于私有库的开发阶段，因为这种方式引入的其实就是实际私有库的源文件，在demo项目中通过这种方式引入，充分测试私有库的相关功能会非常方便快捷。
• 对强迫症患者来说可能会觉得有点不完美的地方，就是当specs中包含subspecs的时候，用这种方式引入时，会出现一些多余的文件层次嵌套。。。感兴趣的患者们可以去试一下。。。

2. 常规的引入方式

常规的引入方式这里就不多说了，它走的是另一个极端，会剔除库中的文件组织结构，而简单的划分了源文件与资源文件，如果包含subspecs，只保留子模块名一级的文件层次，模块内部的文件结构将不复存在，这里暂时没有找到合适的解决办法保留原有组织结构。

222.png

比如上图的结构，发布之后将改变为：

1111.png

子模块划分思路

先说结果，大致是按照这个思路进行划分的：

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群的开发效率与产品质量。