- iOS组件化（一） - 学习和整理
- iOS组件化（二） - iOS本地组件化管理
- iOS组件化（三） - iOS中使用CocoaPods进行私有组件远程管理
- iOS组件化（四） - iOS组件中图片文件资源的使用
一、什么是组件化？
将一个大项目，根据功能属性进行拆解，拆分成独立的功能模块或者组件，然后根据业务需求，组成一个业务完整的项目。
二、组件化要解决的问题
-
项目结构混乱不清晰，模块之间耦合严重
-
对于多个项目，公共代码重复
-
调试要编译整个项目耗时长
-
出现问题，不容易定位
三、无需组件化的情况
团队小，项目小，模块小，模块间耦合小，不需要单元测试
四、组件化的标准
-
模块间没有耦合，修改自己不会影响其它模块
-
模块可单独编译
-
模块间数据传递明确，对外接口清晰易维护
-
模块可随时被相同功能的模块替代，而不影响使用模块的地方
-
模块接口改变时，可以高效重构
五、组件化工具的选择
使用CocoaPods来管理
六、组件化管理
- 本地组件化管理
在主项目下，创建
Framework，通过WorkSpace进行管理。
具体实践查看：iOS组件化（二） - iOS本地组件化管理
- 私有库组件化远程管理
具体实践查看：iOS组件化（三） - iOS中使用CocoaPods进行私有组件远程管理
七、分层
-
业务层 包含各个独立的实际业务模块，比如首页、资讯页等
-
通用层 常用的控件、数据管理、分享、三方登陆等
-
基础层 底层组件、宏定义、分类等
八、组件中资源的使用
具体见文章：iOS组件化（四） - iOS组件中图片文件资源的使用
九、组件间的通讯
参考文章
三种可用方案
URL路由： MGJRouter（蘑菇街） - 4年前断更！！！
JLRoutes - 4年前断更！！！
HHRouter - 5年前断更！！！
JLRoutes 的问题主要在于查找 URL 的实现不够高效，通过遍历而不是匹配。还有就是功能偏多。HHRouter 的 URL 查找是基于匹配，所以会更高效，MGJRouter 也是采用的这种方法，但它跟 ViewController 绑定地过于紧密，一定程度上降低了灵活性。MGJRouter解决了以上问题。
-
target-action： CTMediator - 1年前已断更！！！ -
protocol匹配： BeeHive（alibaba） - 4年前已断更！！！
Swinject - 目前在更新✅，但上次release版本还是在19年！！！
三种方式区别
URL路由: 基于URL匹配或命名约定，用runtime方法进行动态调用。
实现思路：
① APP启动时实例化所有组件，组件向ModuleManager注册url，有时不需要实例化而使用class注册。
② 组件需要调用其他组件时，向ModuleManager传递url，参数以get方式传递，ModuleManager负责处理任务。
优点：
① 实现简单、
② 可以统一管理多平台的路由规则、
③ 可以适配URL Scheme
缺点：
① 需要维护字符串表、
② 依赖于约定命名、
③ 问题在编译时无法暴露只能在运行时暴露、
④ 字符串参数在编译时无法确定类型、
⑤ 不支持storyboard、
⑥ 无法保证使用的模块一定存在、
⑦ 解耦能力有限，字符串url修改导致全部需要修改
target-action: 利用runtime和category特性，动态获取模块
实现思路：
① 利用分类为路由添加新接口，在新接口中通过字符串获取对应类
② 通过runtime创建实例，动态调用方法
模块间关系：
模块A -- Mediator -- target -- 模块B
优点： ① 利用分类明确声明接口 ② 实现方式轻量
缺点：
① 需要在Mediator和target中添加每一个接口、
② category中通过字符串识别，存在和URL路由一样的问题、
③ 无法保证使用的模块一定存在、
④ 运行时才报错、
⑤ 创建太多target
protocol匹配:
实现思路：
① 通过protocol和class进行字典匹配、
② 通过protocol获取class，然后进行动态创建class
