AppDelegate 解耦
**AppDelegate** 控制着整个应用的生命周期,在应用开发中的重要性不言而喻. 随着业务的增长,会发现越来越多的业务的加入, `AppDelegate` 中的代码量急剧增加, 变得难以控制, 解耦也就迫切起来.
AppDelegate 控制着整个应用的生命周期,在应用开发中的重要性不言而喻. 随着业务的增长,会发现越来越多的业务的加入, AppDelegate 中的代码量急剧增加, 变得难以控制, 解耦也就迫切起来.
AppDelegate 解耦是一个很好的学习设计模式的场景. 下面是我总结的别人的经验,如有侵权,请联系我:
分类解耦
这种解耦方式只是利用分类的特性, 将业务代码分离到不同的文件中, 但是还是需要在 AppDelegate 中添加很多业务逻辑的调用, 简单应用推荐此方法, 完全可控, 且没有太多坑
命令模式解耦 参考地址
成员
- 不同的命令
Command - 统一的命令
CommandManager负责执行命令 AppDelegate负责在具体的地方Method方法实现中 嵌入CommandManager的 方法调用
优缺点
好处:
- 将不同的业务封装成命令对象, 统一命令的接口, 面向接口调用, 管理方便
- 扩展性较强, 只需要新建
Command对象, 在CommandManager中接入即可
不足:
AppDelegate需要处理的代理方法过多,Command只能解决一些常用统一的处理方法, 适用范围不足Command对象 需实例化, 一直贮存在内存中
组合方式 参考地址
成员
- 多个 实现
UIApplicationDelegate等协议的对象 - 管理上面👆对象的
Manager AppDelegate在适当的地方 调用 协议对象
优缺点
优点:
- 组合的方式实现多样
- 因为 实现了
UIApplicationDelegate协议, 所以基本适用AppDelegate任何地方
缺点:
- 太多协议对象 导致内存驻留
- 不好处理依赖关系
- 需要在所有的
AppDelegate实现UIApplicationDelegate方法的地方调用 (其实也不太算得上 😆)
消息转发方式
成员
- 多个可以处理某些
UIApplicationDelegate的 代理对象 - 使用
runtime管理 代理对象的管理者 AppDelegate被 上面 管理者 接管
优缺点
优点:
- 业务处理覆盖面广
- 解耦性强
缺点:
- 使用运行时, 有时候坑比较大, 比如覆盖系统方法, 这个可能性谁也不能保证, 比如是多代理还是单代理处理
UIApplicationDelegate协议方法
参考
基本上应该就这些方式, 其他的应该是在这些方式上增减,比如增加模块优先级,增加模块中某些方法优先级 (这个维护性也不会怎么样就) 等等
Member discussion