关于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方法对应的通知，能够根据自已业务的状况补充。

欢迎纠错，拍砖。