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

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

Why

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

知识储备

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

Podfile中specs引入方式

1. :path =>的引入方式

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

2. 常规的引入方式

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

1.png

比如上图的结构,发布之后将改变为:

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

Leave a Comment

Your email address will not be published. Required fields are marked *