iOS组件化内容拆分

对于公司项目的组件化工作已经做了个把月了, 现在来整理一下对基础组件和部分业务组件的拆分

组件结构的分层

由于还是处于组件化的初始阶段, 我们简单的把组件内容分为三个层次, 既基础层,通用层和业务层

基础层

金字塔
所谓的基础层, 既是一个构成APP最基础, 适用性最广泛且最稳定的功能模块, 比如网络请求模块, 图片缓存模块, 分类扩展等; 类似于金字塔的最底层.

基础层是具有普适性的, 因为基础层是存在于每个我们App的最底层的结构, 是构成APP最基本的内容.

基础层必须是最稳定的, 因为它存在于每个app的最底层, 如果频繁的改动基础组件, 可能会导致上层的app出现无可预料的问题, 也增加了测试成本.

通用层

通用层带有一定的业务性, 因为公司虽然有着很多不同的APP, 但是因为公司的发展方向以及发展理念, 会使得不同App也会有一些类似的业务模块, 比如启动页, 分享, 视频播放功能等.

这些内容可能相似度在99%, 仅仅需要配置少量的内容即可适应不同的App使用, 所以把它们归类为通用层.

业务层

业务层就是设计到不同业务内容的模块, 不同的App有不同的业务模块, 比如有的App可能存在商城, 有的可能存在直播, 有的可能存在浏览器等等.

甚至同样的模块由于不同的业务导致其所呈现的内容以及方式也会大相径庭.

总结:
组件化结构总结

管理私有库

CocoaPods是时下比较流行的组件化管理工具,将我们的基础组件放在CocoaPods上对增加复用率降低主工程复杂度更好的管理基础层代码都带来了巨大的帮助。

如何搭建远程私有库, 请看这里iOS搭建远程私有库

私有库配置

当基础内容从业务中划分出来放到组件库中的时候会有一些可配置的需求. 比如: 不同的App使用同一个基础库中的网络请求组件, 但是它们的header内容却不尽相同;

这个时候就需要网络请求组件有可配置header的功能, 满足不同App的需求;

我们的做法是为可配置的内容设置一个分类, 在业务部分去实现这个分类; 这样在组件内部就可以使用业务中实现的分类方法;

配置关系

组件之间通信

目前业内比较成熟,使用比较广泛的方案有三种.

方案一: 中间件转发(Mediator Manager Router)

Mediator
我们可以做一个中间件, 去处理各个组件之间的信息转发;

中间件通过runtime接口解耦, 实现各组件间的互不依赖

方案二: 注册表方式(URL Router)

注册表方式使用URL表示接口, 在模块启动时注册模块提供的接口, 结构和方案一类似;

方案三: protocol-class方式

仍然是需要一个中间件Mediator, 不同的是它是用来注册公共的protocol; 在这种方案中会有一个公共的protocol文件, 定义了没一个组件对外提供的接口;

在模块里实现这些接口, 并在初始化的时候调用Mediator中的register方法来注册;

最后调用者通过protocol从protocolMediator中拿到提供这些方法的Class, 进行调用;

我们使用第三种方式来实现组件间通信.

-------------感谢您的阅读-------------
0%