iOS组件化开发架构设计思考（初版）

组件化开发系列：

（一）iOS组件化开发架构设计思考

（二）iOS组件化开发实施一期文档

一. 项目现状

当前iOS端APP项目大概有35万行代码，早期为了iPad和iPhone双端开发的效率，将所有业务模块的网络请求和数据模型统一抽离到DDEngine工程，自定义了私有开发库DDDevLib工程，和第三方SDKs管理库ThirdSDKs工程，和功能相对独立的DDMIX_UI工程。在项目较小时，这个架构是完全可以满足开发需要的，也是容易推进的。但是开发过程中缺少组件化的考量，随着产品线的扩展和人员流动，对项目不熟悉和开发规范不够严谨，造成业务模块依赖关系非常复杂，主要有三类耦合：

工程耦合：某些模块在运行时需要依赖主工程的代码才能运行或实现完整的功能；

界面耦合：App 执行过程中，硬编码的界面跳转行为；

依赖耦合：两个业务模块之间的代码依赖。

现在一处改动有可能造成多处受影响，需要测试同事做大量回归测试，存在重复造轮子、项目编译时间长、开发效率降低等问题。目前还只是基于OC编码，Swift编码也是项目演进的一个重要方向，Swift和OC的相互调用还不是很方便，暗坑无数，需要先对项目进行组件化演进，以便项目向Swift和OC混编过渡。

二. 方案调研

参考业内的流行方案

1、基于 URL Router、ModuleMediator

代表：蘑菇街 Limboy

URL组件化架构图

优缺点：

1、URL Router方案，在使用时需要注册模块类，需要维护一个URL路由表，而且路由表一般保存服务端，拓展性和可维护性降低。

2、非常规对象无法直接参与本地组件间调度，模块之间用URL去完成调度，徒增复杂化。

3、项目中已有URL路由配置，URL Router 开发起来相对比较容易推进。

2、基于 Target-Action、Runtime、Category

代表：安居客 Casa Taloyum

Target-Action组件化架