关于AppDelegate瘦身的多种解决方案
在iOS项目的开发中，AppDelegate是一个耦合发生的重灾地，很多项目的开发时间一长，AppDelegate就不可避免地出现，代码臃肿，调用顺序混乱，逻辑复杂的问题。这个UIApplication的委托类，作为一个常驻内存的单例，它承载了太多太多的功能，连苹果的官方文档都建议应该由AppDelegate来处理这些工作：
1.app的启动代码；
2.响应app的状态，比如app切换到后台和前台等状态；
3.响应外部传递给app的通知，比如说push，low-memory warnings；
4.决定了app的状态是否应该保存或者恢复；
5.响应不是发送给特定view或者vc，而是发送给app本身的事件；
6.用来保存一些不属于特定vc的数据。
不得不吐槽一句，有时候，苹果的官方文档的建议也不那么靠谱啊🤦♀️。
一个业务逻辑稍复杂点的项目，上述6点的所有功能的代码直接一股脑塞到一个文件里，能不臃肿才怪了。
这里介绍三种给AppDelegate瘦身的方式：
NSNotification
我们知道一个app的各种事件发生时除了会调用UIApplicationDelegate中的方法，同时还会发送一个NSNotification，苹果在UIApplication.h中声明了这些通知。但是并不是所有方法都有对应的通知，这时我们可以仿照苹果的命名规范补上未定义的这些方法对应的通知，然后在自己的AppDelegate中显式地发送它们。
比如，定义application:didRegisterUserNotificationSettings:方法对应的通知：
UIKIT_EXTERN NSNotificationName const UIApplicationDidRegisterUserNotificationSettingsNotification;
同时别忘了定义参数对应的key：
UIKIT_EXTERN NSString *const UIApplicationUserNotificationSettingsKey;
然后在AppDelegate中的application:didRegisterUserNotificationSettings:方法里执行：
- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings
{
[[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationUserNotificationSettingsKey object:[UIApplication sharedApplication] userInfo:@{UIApplicationUserNotificationSettingsKey : notificationSettings}];
}
最后在需要响应这个事件的模块中注册通知，处理对应的业务逻辑即可。
ModuleManager
通过实现ModuleManager类，来管理项目中的模块，首先在软件启动时通过读取配置文件（通常用plist）读取模块，在AppDelegate的每个事件接收到响应的时，在对应方法中逐一调用已注册的模块对应的响应方法：
首先在启动时load modules
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[[ModuleManager sharedInstance] loadModulesFromPlist:[[NSBundle mainBundle] pathForResource:@"modules" ofType:@"plist"]];
}
UIApplication event发生时，依次调用每个module的对应方法：
- (void)applicationDidBecomeActive:(UIApplication *)application {
NSArray<id<ModuleProtocol>> *modules = [ModuleManager sharedInstance].modules;
[modules enumerateObjectsUsingBlock:^(id<ModuleProtocol> _Nonnull module, NSUInteger idx, BOOL * _Nonnull stop) {
if ([module respondsToSelector:_cmd]) {
[module applicationDidBecomeActive:application];
}
}];
}
ModuleProtocol继承自UIApplicationDelegate，定义如下：
@protocol ModuleProtocol <UIApplicationDelegate>
//在这里根据自己项目的业务定义模块的共有方法
@end
AOP
AOP在Objective-C中利用method swizzle来实现，例子就不举了，相信有一定经验的同学应该都知道到底要如何实现。
对比
以上三种方法，从结果上来说都可以达成给AppDelegate瘦身的目的，但是各有优缺点，因此也会用在不同场景，我说一下自己的个人看法，抛砖引玉：
NSNotification
- 使用NSNotification的好处在于，如果不需要响应系统未定义的通知，那么你的AppDelegate里甚至可以一行代码都不用写，瘦身瘦成一道闪电！
- 你无法管理通知的注册者的调用顺序，比如说你创建rootwindow的代码如果还依赖读取配置模块，但是分别使用观察通知将实现代码写在了不同模块中，这时候就很难保证读取配置模块在创建rootwindow之前执行。因此为了保证调用顺序，可以保留部分代码在AppDelegate中。
ModuleManager
- ModuleManager更适合高度组件化/模块化的项目，项目到了这个阶段，工程中的任何功能都被封装成了模块，因此可以通过调整plist文件中的模块顺序，来保证模块的执行顺序是正确的。
- 相对的，使用ModuleManager的设计，对工程代码的质量要求也会比较高，如果你的项目还未开始进行组件化/模块化的设计，使用这种方式来给AppDelegate瘦身的难度也会很大，此时选用NSNotification是更好的解决方案。
AOP
- 使用AOP的需要慎重和小心，这一点在很多的技术博客和书籍中都会有提到，AOP用的好会是一把架构的利剑，帮你披荆斩棘，但是用不好的话，也会伤到自己。
- AOP同样很不好控制代码的执行顺序。
- 利用AOP由于可以做到百分百的无侵入，因此很适合在做第三方SDK项目时使用，这样能够尽可能减少SDK的使用者的接入成本。
- AOP可以结合NSNotification或ModuleManager使用，然后者达到完全免侵入（仅仅适合极端的代码洁癖主义者）。
以上三种方法，并没有真正意义上的孰优孰劣，而是需要根据自己项目的特点来选择更适合的方案。
最近在重构项目时，我结合AOP和NSNotification写了一个小功能(https://github.com/jiaopen/AppDelegateExtensions)，几乎无侵入地解决AppDelegate臃肿问题。
Features:
- AOP没有使用category来实现methodswizzle，因为不是所有工程的
AppDelegate起名相同，因此需要在load中显式调用一行注册代码。 - 增加了常用的
UIApplicationDelegate方法对应的通知，可以根据自已业务的情况补充。
欢迎纠错，拍砖。
