• 组件化遵循的原则

• 组件化分层模型

• 组件化集成方法

1.遵循原则

高层依赖底层，下层不能对上层有依赖的关系
这点是基本的设计原则，可以通过依赖倒置来设计。

同层级的模块不依赖或者尽量少依赖
这点同时也是基本的设计原则，可以通过控制反转来设计，典型的就是使用观察者模式来实现同一个层级模块的解耦。

最小知识原则和自完备性
一个独立的模块尽量减少对其他低层模块的依赖，比如一个模块只是依赖低层模块的某个类的方法，不妨把这个方法拷贝到此模块中，如此一来这个模块就具有了更好的自完备性。

2.分层结构

58同城组件化设计和实现的思路

Ⅰ. 基础底层组件
稳定的、和业务无关的组件，这一层就是传说中的技术组件，这些组件在每个应用中基本都会存在，包含了：

• 封装基础的网络操作
• 数据库
• 日志
• 工具类：常用分类、宏定义
• 基础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

底层组件-数据库模块

数据库的使用在应用中很常见，主要需要实现以下功能：

• 数据库管理者提供外部访问数据库的接口
• 数据库管理者拥有包含但是不限于数据库自动版本升级处理的功能

具体可以参考iOS 数据库升级数据迁移解决方案

底层组件-基础UI组件

基础的UI组件适用于所有的业务场景的并且支持扩展的UI组件，业务的变化，基础UI组件不能有改动但是可以进行扩展和定制，常用的主要有以下：

• 上下拉刷新组件
• 轮播组件
• HUD提示组件
• 滑动返回组件
• 分页组件
• 自定义Tab组件

底层组件-缓存管理模块

缓存管理有很多的应用场景，比如缓存页面列表、详情页的数据，提高加载数据以达到优化用户体验，需要关注以下几个方面：

• 缓存存储策略 缓存数据保存的位置以及缓存保存的名称
• 缓存存储方式 对象归档存储，数据库存储，二进制存储，
• 缓存的查找和取出
• 缓存更新和过期处理
• 提供客户端的读写接口
• 提供客户端清除缓存的接口

Ⅱ. 基础业务层组件
相对稳定的数据提供层，数据提供包含了业务接口或者有包含了缓存读写的服务，这一层就是传说中的业务服务层组件，包含了：

• 网络接口的封装（针对业务的，可以包含有数据的缓存读写功能）
• IMSDK的封装层组件
• 第三方分享、登录、支付组件
• 统计打点组件
• 推送通知组件

业务组件-接口的封装

接口的封装提供给上层（一般是表现层）提供数据，中心化的网络接口设计，提供的是一个模型对象给上层
更详细的网络层设计可参考：iOS应用架构谈 网络层设计方案

业务组件-第三方分享、登录、支付组件

提供第三方分享、登录、支付的服务，可以扩展自定义的第三方组件，提供以下功能

• 初始化设置第三方平台的APPID、APPKEY、APPSECRET等第三发平台注册需要的信息
• 处理第三方平台功能的调用
• 处理第三方平台跨进程回调的数据处理
• 支持自定义配置第三方平台的个数 具体详细的信息可以参考：
  OS第三方平台集成组件化续集（以插件化的方式添加自定义的第三方平台）
  iOS第三方平台集成组件化

业务组件-推送通知组件

推送通知在很多业务场景中都有用到，一般滴你的产品有运营管理，推送通知是必须的功能。一个推送管理组件一般包含以下功能：

• 在App启动时候初始化推送通知的设置
• 处理注册Token
• 处理接收消息
• 提供给外部推送消息数据的接口（可以设计为观察者模式，客户端是Observer）

业务组件-统计打点组件

统计打点也是在很多app（基本所有）中有使用到的，如果没有和业务相关的打点统计、页面统计，最基本的用户新增、流程、日活等基本的数据都依赖于统计打点组件。此外一般的统计打点组件都有crash收集系统，所以这同时是一个很好的BUG反馈工具。统计打点组件一般的有以下功能：

• 注册第三方统计平台的key，可多次注册多个平台
• 一组统计接口提供给客户端调用

集成方法

集成方法可以选择主流的cocoapods，cocoapods提供的包管理功能十分强大，在开发阶段，可以选择开发库，即把podfile中的某个pod指向为本地podspec文件，这样方便修改。如果库完善的很好了，可以考虑把库做成私有库提交到自己的git系统以供其他项目和其他成员使用，因为篇幅限制，后续会写一篇使用cocoapods做开发库和私有库集成的文章。

使用cocoapods集成实战演练可以看我的这篇文章： iOS 组件化-使用cocoapods集成实战演练