新年第一个项目，没想到又加急了一个项目，一周要完成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<frdmodule>) module
{
if (![self.modules containsObject:module]) {
[self.modules addObject:module];
}
}
// 在AppDelegate生命周期方法中依次调用每个模块的对应方法
- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
for (id<frdmodule> 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。
