iOS 组件化构想
组件化这两年听得很多了，各大厂的团队也都在陆续的推出自己的组件方案，如美团、阿里、蘑菇街啊等等。
尽管每个公司的目标是一样的，但是实现方式确是相去甚远，不论是依赖注入，SPI中间层机制，还是通知、runtime消息机制，都各有所长。最重要的是，合适自己的才是最好的。
一、组件化的必要性
为什么要做，适用于当前的小团队么？
1、梳理APP的逻辑，使功能更清晰，透明
2、提高代码复用率，减少重复造轮子 don't repeat yourself
3、APP模块间解耦，业务隔离
4、对开发人员有更大的挑战，提升自身
5、模块化是趋势，是功能越来越复杂时的必然结果
组件化在起步时，肯定是降低了开发效率的，需要把之前的代码梳理清楚，所以我觉得反而小项目起步会比较容易，更容易上手。
二、涉及到的人员
1、通用层:
目标：
可以直接移植到到任何APP，不做定制化内容
允许上层业务强依赖
一般由业内通用的第三方和团队内部达成共识的基础封装组成，如Masonry、AFNetworking，和我们的FBDevelopKit，通用base
2、通用业务层：
APP的定制化封装，如统计、crash收集、loading（一般来说每个APP的loading都有所差别）、无网UI等，AppInfo
3、业务模块：
APP内的主要模块，卡片业务，IM，iVoice，登录注册等
4、中间层：
这一块比较重要，我初步是构想为业务模块解耦服务
通用层和通用业务层可以被直接依赖，但是模块之间不能耦合，只能通过中间层进行消息的传递（组建通信）
三、实施步骤
1、抽离现有库
项目中common和tool等工具类，进行优化再封装
2、细粒化模块中的使用库
平移、下沉、回接，内部消化对齐
3、模块分离
4、建设中间层（router、server、notification）
因为每个人都会参与进来代码的封装，所以先达成以下共识：
1、尽量遵循几大原则：
单一职责原则告诉我们实现类要职责单一；
里氏替换原则告诉我们不要破坏继承体系；
依赖倒置原则告诉我们要面向接口编程；
接口隔离原则告诉我们在设计接口的时候要精简单一；
迪米特法则告诉我们要降低耦合。
而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。
相关文档
2、代码规范化，Mogo iOS代码规范
3、使用pod管理
？依赖注入，方便移植，远端管理...
4、复杂的封装需要文档输出和demo
组件通信的几种方案：
模块间相互解耦，那么他们之间该如何回调（跨模块、多层），通用Domin如何传递，如何调用其他模块的API？
1、依赖注入
典型的如Objection框架，我大概看了一下，基于面向接口编程的思想，暴露出category
因为项目中基本是基于MVC开发，所以这种方式暂不考虑
2、基于SPI机制（中间层）
大概看了下MGJRouter，是比较好理解的一种方式
3、通知中心
4、iOS消息机制
runtime方法直接调用，缺点很明显，不好调试，代码分散；但的确很强大
四、终极目标
1、提高参与人员的规范、架构意识
2、提高并行开发效率、维护效率
