Method Swizzling和分类的妙用–从AppDelegate轻量化处理说起

简介

在iOS工程中，AppDelegate往往会有上千行，甚至几千行，这样就会给维护AppDelegate带来诸多麻烦。比方说，老板想在出现HomeViewController之前弹出广告并停顿几秒，这样你就要加入插入广告的逻辑；又比方说，老板想在开始做个请求，判断某个开关是否打开。这样就会在AppDelegate中插入很多相关的不相关的代码。

在AppDelegate中，- (BOOL)application:(UIApplication )application didFinishLaunchingWithOptions:(NSDictionary )launchOptions是“Tells the delegate when the application has launched and may have additional launch options to handle.”，即在app开始运行时会调用里面的方法。在didFinishLaunchingWithOptions中，我们往往会渲染window，注册第三方监控库，加入基本页面跳转逻辑。

下面是一个常见项目中的didFinishLaunchingWithOptions：

下面我们就来看看，有什么好的办法可以对AppDelegate进行瘦身，加强代码的可读性和可维护性，并将代码放到适当的地方。

函数模块化

上述didFinishLaunchingWithOptions中可以按照功能逻辑划分为：处理启动逻辑，注册第三方库，处理其他逻辑三类。这样就可以优化为：

模块化后，代码瞬间变得易读很多，而且需要改什么可以直接去相应的模块添加。但是这个仅仅是将代码的顺序变化下，相同功能的代码抽到一个函数中，代码行数没有减少，所有的功能还是糅合在一个.m中。

类模块化

很多其他逻辑是业务逻辑的，可以抽离到业务Model中，通过类模块化便捷使用。这样就可以优化为：

分类模块化

先抛个问题：分类中是否可以定义变量？

如果不知道可以参考：iOS分类中通过runtime添加动态属性

分类能够做到的事情主要是：即使在你不知道一个类的源码情况下，向这个类添加扩展的方法。这里我们主要是将对外开放的方法和一部分变量拿到分类中处理。这样进一步轻量化AppDelegate本身进行代码量。

这样代码结构会更加清晰明了。 抽出来的AppDelegate只剩下注册第三方库了，因为第三方库很多是需要在didFinishLaunchingWithOptions中运行，正常的方法就很难。

Method Swizzling化

Method Swizzling是改变一个selector的实际实现的技术，关于Method Swizzling的概念、原理谷歌一堆。

Method Swizzling中以viewWillAppear为例，讲解了Method Swizzling的基本用法。

这下再去看下AppDelegate文件，代码不超过200行了。

小结

Method Swizzling常见的应用场景：

1.用于记录或者存储，比方说记录ViewController进入次数、Btn的点击事件、ViewController的停留时间等等。 可以通过Runtime获取到具体ViewController、Btn信息，然后传给服务器。

2.添加需要而系统没提供的方法，比方说修改Statusbar颜色。

3.用于轻量化、模块化处理，如上面介绍的，代码轻量化处理。

Method Swizzling是把双刃剑，需要正确理解它的使用。

分类增加变量的使用场景：

1.过多继承时，可以通过分类减少继承层级，清晰流程框架。比方说，ViewController可能需要相互冲突的事件，单一父类会导致逻辑复杂。这时候可以通过分类简化逻辑，不同的ViewController引用不同的分类。

2.扩展类属性。

上面我们学习了一些瘦身的技巧，希望通过这些方法写出更可读性更高，可维护性更高的代码。

提醒：

本文涉及到的Demo已经放到GitHub上了。Demo可能与本文有点出入，部分函数命名跟文章中不一致。