AppDelegate瘦身摸索

新年第一个项目，没想到又加急了一个项目，一周要完成70%。。。。。这不明摆着要加班的节奏吗？？？还好，项目中的模块大多数都用过，又是独立开发，三天完成所有界面。这个项目是用组件化开发，但有个问题想拉出来说说，就是如何对AppDelegate进行优雅瘦身，针对这个问题也翻了网上的很多资料，思路大同小异。

先介绍一种开源工具：

FRDModuleManager

FRDModuleManager是豆瓣开源的轻量级模块管理工具。它通过减小AppDelegate的代码量来把很多职责拆分至各个模块中去，这样 AppDelegate 会变得容易维护。其主要类FRDModuleManager只有300多行代码，使用方式也很简单：

FRDModuleManager 是一个简单的 iOS 模块管理工具。FRDModuleManager 可以减小 AppDelegate 的代码量，把很多职责拆分至各个模块中去。使得 AppDelegate 会变得容易维护。

如果你发现自己项目中实现了 UIApplicationDelegate 协议的 AppDelegate 变得越来越臃肿，你可能会需要这样一个类似的小工具；或者如果你的项目实施了组件化或者模块化，你需要为各个模块在 UIApplicationDelegate 定义的各个方法中留下钩子（hook），以便模块可以知晓整个应用的生命周期，你也可能会需要这样一个小工具，以便更好地管理模块在 UIApplicationDelegate 协议各个方法中留下的钩子。

FRDModuleManager 可以使得留在 AppDelegate 的钩子方法被统一管理。实现了 UIApplicationDelegate 协议的 AppDelegate 是我知晓应用生命周期的重要途径。如果某个模块需要在应用启动时初始化，那么我们就需要在 AppDelegate 的 application:didFinishLaunchingWithOptions: 调用一个该模块的初始化方法。模块多了，调用的初始化方法也会增多。最后，AppDelegate 会越来越臃肿。FRDModuleManager 提供了一个统一的接口，让各模块知晓应用的生命周期。这样将使 AppDelegate 得以简化。

严格来说，AppDelegate 除了通知应用生命周期之外就不应该担负其他的职责。对 AppDelegate 最常见的一种不太好的用法是，把全局变量挂在 AppDelegate 上。这样就获得了一个应用内可以使用的全局变量。如果你需要对项目实施模块化的话，挂了太多全局变量的 AppDelegate 将会成为一个棘手的麻烦。因为，这样的 AppDelegate 成为了一个依赖中心点。它依赖了很多模块，这一点还不算是一个问题。但是，由于对全局变量的访问需要通过 AppDelegate，这就意味着很多模块也同时依赖着 AppDelegate，这就是一个大问题了。这是因为，AppDelegate 可以依赖要拆分出去的模块；但反过来，要拆分出去的模块却不能依赖 AppDelegate。

这个问题，首先要将全局变量从 AppDelegate 上剔除。各个类应该自己直接提供对其的全局访问方法，最简单的实现方法是将类实现为单例。变量也可以挂在一个能提供全局访问的对象上。当然，这个对象不应该是 AppDelegate。

其次，对于 AppDelegate 仅应承担的责任：提供应用生命周期变化的通知。就可以通过使用 FRDModuleManager 更优雅地解决。

这两步之后，AppDelegate 的依赖问题可以很好地解决，使得 AppDelegate 不再是项目的依赖中心点。

使用方式也很简单：

加载模块：

NSString* plistPath = [[NSBundle mainBundle] pathForResource:@"login" ofType:@"plist"];
FRDModuleManager *manager = [FRDModuleManager sharedInstance];
[manager loadModulesWithPlistFile:plistPath];

在 UIApplicationDelegate 各方法中留下钩子：

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
 
  NSString* plistPath = [[NSBundle mainBundle] pathForResource:@"login" ofType:@"plist"];
  FRDModuleManager *manager = [FRDModuleManager sharedInstance];
  [manager loadModulesWithPlistFile:plistPath];
  [manager application:application didFinishLaunchingWithOptions:launchOptions];
  return YES;
}
 
- (void)applicationWillResignActive:(UIApplication *)application {
  [[FRDModuleManager sharedInstance] applicationWillResignActive:application];
}
//...这里省略其他的多个生命周期方法

实现原理:

FRDModuleManager的实现很简单，其内部数组持有注册的模块的引用，通过依次调用数组中的每个模块的特定方法来达到解耦的目的：

// 添加一个模块即是往数组中添加新的元素
- (void)addModule:(id) module
{
  if (![self.modules containsObject:module]) {
    [self.modules addObject:module];
  }
}

// 在AppDelegate生命周期方法中依次调用每个模块的对应方法
- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  for (id module in self.modules) {
    if ([module respondsToSelector:_cmd]) {
      [module application:application willFinishLaunchingWithOptions:launchOptions];
    }
  }
  return YES;
}

优点：
简单，只需要几行代码就可以解决。
被添加的每个模块都可以“享受”AppDelegate的各个生命周期。

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

MGJRouter

MGJRouter是一个高效/灵活的iOS URL Router,解决了JLRoutes查找URL不够高效，通过遍历而不是匹配的问题。这里不多做介绍了,大家可以自行Google。