背景
大概在一个月之前，公司有一个需求需要出一个功能和业务逻辑和当前应用相同的新版本，所有的UI重新设置过而不止是配色字体图标等信息的简单修改。因为当时排期相对的不太紧，所有决定把整个项目做一个重构，为了实现更好的重构，发了点时间看了大概30多篇关于组件化的博客和文章，也会把这些文章的链接贴在底部，然后动手开工了，今天有时间把这次重构过程中的一些想法总结下。
本文主要涉及到以下几个主题：
- 组件化遵循的原则
- 组件化分层模型
- 组件化集成方法
遵循原则
-
高层依赖底层，下层不能对上层有依赖的关系
这点是基本的设计原则，可以通过依赖倒置来设计。 -
同层级的模块不依赖或者尽量少依赖
这点同时也是基本的设计原则，可以通过控制反转来设计，典型的就是使用观察者模式来实现同一个层级模块的解耦。 -
最小知识原则和自完备性
一个独立的模块尽量减少对其他低层模块的依赖，比如一个模块只是依赖低层模块的某个类的方法，不妨把这个方法拷贝到此模块中，如此一来这个模块就具有了更好的自完备性。
分层结构
Ⅰ. 基础底层组件
稳定的、和业务无关的组件，这一层就是传说中的技术组件，这些组件在每个应用中基本都会存在，包含了：- 封装基础的网络操作
- 数据库
- 日志
- 工具类：常用分类、宏定义
- 基础UI组件
- 缓存管理模块
- 其他第三方组件
底层组件-基础网络库
根据输入输出的思想进行封装，封装变化
不封装的不变的部分：
- 输入参数中不变的HttpHeader
- http层缓存的处理
- 二进制数据转换为JSON格式
输入变化的部分包含：
- url
- 参数
- 数据类型
- 其他参数
输出变化的部分包含了:
- 回调（JSON数据，错误码，错误信息）
- 全局的错误处理（发送请求无网络处理，URL加载系统出错的处理，业务错误的处理（授权失败））
其中输入输出部分有的是可选的，除了定义一个全能的外部接口，需要提供若干个简便外部接口提供个客户端使用：
客户端使用的是简单的请求，只需要调用简单外部接口传递 url 和 参数 而不需要传递 数据类型 和 其他参数，数据类型 和 其他参数 这两个参数使用默认值即可。
客户端关系返回数据的错误码或者错误信息，定义一个只包含错误码，错误信息回调的简单接口即可，而不传递JSON数据。
提供给上层的网络请求接口是不变的，用户无需关心网络底层的具体逻辑实现，网络请求底层可以使用系统的URL加载系统，或者使用第三方的封装不会到客户端造成影响。
底层组件-工具类和常用宏
宏定义的分类
字符串处理相关
- 字符串的空处理
- 国际化格式字符串宏
对象处理相关
- 对象模型序列化相关宏
- 对象的单例宏
设备信息宏：
- 屏幕的尺寸、Tabbar高度、NavBar高度等宏
- ios版本宏
- iPad or iPhone 判断宏
DEBUG宏
- 自定义的Log宏定义
颜色宏定义
- 十进制RGB格式的颜色
- 十六进制HEX格式的颜色
宏定义处理注意点
宏定义避免和具体的类有互相依赖的关系
eg. UtilMacro -> UIUtil -> UtilMacro宏定义有间接的依赖
eg. ProductParameter -> UtilMacro -> UIUtil常用的Category
- UI系列：UIXXX-Category UIView/UIColor/UIImage/UILabel/UIImageView/UIViewController
- NS系列：NSXXX-Category NSDate/NSObject/NSData/NSString/NSDictionary
底层组件-数据库模块
数据库的使用在应用中很常见，主要需要实现以下功能：
- 数据库管理者提供外部访问数据库的接口
- 数据库管理者拥有包含但是不限于数据库自动版本升级处理的功能
具体可以参考
底层组件-基础UI组件
基础的UI组件适用于所有的业务场景的并且支持扩展的UI组件，业务的变化，基础UI组件不能有改动但是可以进行扩展和定制，常用的主要有以下：
- 上下拉刷新组件
- 轮播组件
- HUD提示组件
- 滑动返回组件
- 分页组件
- 自定义Tab组件
底层组件-缓存管理模块
缓存管理有很多的应用场景，比如缓存页面列表、详情页的数据，提高加载数据以达到优化用户体验，需要关注以下几个方面：
- 缓存存储策略 缓存数据保存的位置以及缓存保存的名称
- 缓存存储方式 对象归档存储，数据库存储，二进制存储，
- 缓存的查找和取出
- 缓存更新和过期处理
- 提供客户端的读写接口
- 提供客户端清除缓存的接口
Ⅱ. 基础业务层组件
相对稳定的数据提供层，数据提供包含了业务接口或者有包含了缓存读写的服务，这一层就是传说中的业务服务层组件，包含了：- 网络接口的封装（针对业务的，可以包含有数据的缓存读写功能）
- IMSDK的封装层组件
- 第三方分享、登录、支付组件
- 统计打点组件
- 推送通知组件
业务组件-接口的封装
接口的封装提供给上层（一般是表现层）提供数据，中心化的网络接口设计，提供的是一个模型对象给上层
更详细的网络层设计可参考：业务组件-第三方分享、登录、支付组件
提供第三方分享、登录、支付的服务，可以扩展自定义的第三方组件，提供以下功能
- 初始化设置第三方平台的APPID、APPKEY、APPSECRET等第三发平台注册需要的信息
- 处理第三方平台功能的调用
- 处理第三方平台跨进程回调的数据处理
- 支持自定义配置第三方平台的个数 具体详细的信息可以参考：
业务组件-推送通知组件
推送通知在很多业务场景中都有用到，一般滴你的产品有运营管理，推送通知是必须的功能。一个推送管理组件一般包含以下功能：
- 在App启动时候初始化推送通知的设置
- 处理注册Token
- 处理接收消息
- 提供给外部推送消息数据的接口（可以设计为观察者模式，客户端是Observer）
业务组件-统计打点组件
统计打点也是在很多app（基本所有）中有使用到的，如果没有和业务相关的打点统计、页面统计，最基本的用户新增、流程、日活等基本的数据都依赖于统计打点组件。此外一般的统计打点组件都有crash收集系统，所以这同时是一个很好的BUG反馈工具。统计打点组件一般的有以下功能：
- 注册第三方统计平台的key，可多次注册多个平台
- 一组统计接口提供给客户端调用
集成方法
集成方法可以选择主流的cocoapods，cocoapods提供的包管理功能十分强大，在开发阶段，可以选择开发库，即把podfile中的某个pod指向为本地podspec文件，这样方便修改。如果库完善的很好了，可以考虑把库做成私有库提交到自己的git系统以供其他项目和其他成员使用，因为篇幅限制，后续会写一篇使用cocoapods做开发库和私有库集成的文章。
使用cocoapods集成实战演练可以看我的这篇文章：
结束
以上就是我在一次项目组件化重构中总结的一些心得，希望可以对需要的人有所帮助，不妥之处敬请指教。
参考文章链接
以下链接是来自于我的书签