转载

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

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

Why

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

知识储备

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

Podfile中specs引入方式

1.:path=>的引入方式

会添加到DevelopmentPods中，并且复制整个私有库的文件组织结构（文件夹嵌套关系都会保留）,这种引入方式非常适合于私有库的开发阶段，因为这种方式引入的其实就是实际私有库的源文件，在demo项目中通过这种方式引入，充分测试私有库的相关功能会非常方便快捷。

对强迫症患者来说可能会觉得有点不完美的地方，就是当specs中包含subspecs的时候，用这种方式引入时，会出现一些多余的文件层次嵌套。。。感兴趣的患者们可以去试一下。。。

2.常规的引入方式

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

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

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

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

子模块划分思路

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

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

正文到此结束