AppDelegate解耦

方案一：FRDModuleManager

FRDModuleManager 提供了一个统一的接口，让各模块知晓应用的生命周期。在 AppDelegate 中留下钩子，在特定的生命周期调用模块的对应方法。这样将使得 AppDelegate 更简单。对于应用生命周期的使用也更清晰。 evernotecid://6F55E44D-BBC1-43F1-9310-4138A0D19764/appyinxiangcom/11652118/ENResource/p18418

使用：参考github文档

优势：

• 一、简单，只须要几行代码就能够解决。
• 二、被添加的每一个模块均可以“享受”AppDelegate的各个生命周期。

缺点：

• 一、每一个模块都要初始化并分配内存，当FRDModuleManager里注册了大量模块时，会建立大量对象并影响App启动速度。
• 二、缺乏模块初始化优先级，当有三个模块A,B,C时，正好C依赖于B，B依赖于A，若是在配置文件中配置A，B，C的顺序又是打乱时，初始化会出问题。

其实第2个缺点是能够避免的，咱们能够调整plist文件中的类的顺序，来实现模块的调用顺序。咱们拿FRDModuleManager的demo中的plist文件来验证一下。

顺序一：FRDGroupModule在上面

对应下面的调用日志

顺序二：FRDGroupModule在下面

对应下面的调用日志

方案二：JSDecoupledAppDelegate

JSDecoupledAppDelegate是由JSBadgeView的做者开发的一款轻量级的AppDelegate解耦工具。它将AppDelegate各个功能点独立出来，并经过代理的方式将控制权下发。实现原理，利用Objective-C的消息转发机制，转发AppDelegate的各个方法来实现AppDelegate的解耦的

使用：参考github文档

优势：

• 一、JSDecoupledAppDelegate自己对于AppDelegate各个功能的拆分对咱们理解AppDelegate有必定帮助——AppDelegate确实承载了太多的功能。
• 二、因为各个子代理对象的执行顺序是肯定的，所以基本能够解决FRDModuleManager中相互依赖的问题。

缺点：

JSDecoupledAppDelegate的缺点很是明显：使用它必须废弃原生的AppDelegate，所以咱们不能经过((AppDelegate *)[UIApplication sharedApplication].delegate).window来获取window，以及window的rootViewController。

方案三：AppDelegate分类(Category)

优势：

不须要添加任何三方库，咱们就能够给AppDelegate添加不少方法，而且能轻松控制方法的执行顺序

缺点：

添加新的属性比较繁琐，只能经过runtime或者BlocksKit等三方库实现

参考： DelegateDietDemo