背景：随着公司相关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群的开发效率与产品质量。
网友评论