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 协议方法

参考

基本上应该就这些方式, 其他的应该是在这些方式上增减,比如增加模块优先级,增加模块中某些方法优先级 (这个维护性也不会怎么样就) 等等

• AppDelegate解耦
• AppDelegate瘦身| 一水的技术博客
• AppDelegate的模块化+瘦身