“Yeah It’s on. ”
背景
最近项目业务迭代比较频繁，上面要求一周一个版本，手头工作现在是swift跨版本迁移+业务迭代双线进行，我在考虑迁移的工作是重建项目，还是在原有基础上变更。
选择进行组件化的缘由
项目现在使用的是MVC架构，因为项目开始的时候，本着快速上线，并且新来的小伙伴快速上手，在原有已经有内部私有库的情况下，进行包装对快速上线来说使用MVC是最优选择。后面项目越来越大，需求越来越复杂，导致回头看代码的时候，项目内部的耦合极其严重，双向依赖严重。重复造轮子情况也时有发生，并且代码分支很多，发版前大量的时间用在合并代码上面。拆分组件进行解耦成为了必须要做的选择。
重构方案
-
抽象基础服务 首先我们为基础服务的定义为：所有项目都可依赖，并且不需要依赖业务的服务，如：（网络、文件、持久化等）。封装为私有库pod，通过版本号严格控制。
-
业务模块组件化 组件之间不可以存在依赖，建立一个组件管理器，业务组件为和产品强相关的服务，如：（Token、UIBase、配置信息、加解密处理）
-
开发环境动态切换 项目开发环境切换封装成一个组件，不需要不智能的手动修改。
-
各个团队开发互不影响 组件调用解耦，交给中间层组件管理器去调用，每个开发人员要保证，在开发及抽离自己模块的过程中，必须和其他业务完全解耦，在自己的模块调用不到其他模块的任何东西，并且保证自己的模块在自己的测试项目中可用。每个组件都要遵循协议调用组件管理器，每个组件内部都是一个MVC架构,UI层可以调用逻辑层和资源层，逻辑层不可以调用UI层代码，只能通过通知或者block形式，保证每个模块做每个模块自己的事情。
-
统一编码规范 统一项目开发人员的代码规范，类及文件的前缀、缩进注释等
-
封装设备组件与手机服务组件 由于项目的特殊性，需要取得用户信息（合法…）把所有的信息封装使用。
关于组件之间的跳转
- 有两种解决方案
- 第一种使用集中路由管理，通过router统一调度，缺点是集中调度代码量巨大。
- 第二种业务组件自己处理，每个组件注册自己的url,返回对应的vc，中心调度只做传递。
关于组件间服务调用
- 每个组件暴露一个协议接口文件，把需要对外暴露的方法都写在接口文件中。
结束
欢迎一起交流关于iOS的组件化处理。
—— Ade