苹果为什么自身SDK不使用继承来添加方法，而是使用Category呢？
主要是为了减少继承的层级，让业务层做业务的时候可以脱离App环境，减少不必要的负担，花更少的时间搭建环境。
因为业务层上继承的越多，编译的无用的代码越多，花费的编译时间也就越长。
其次让功能更透明，符合业务方在开发时的第一直觉。例如有一个SDKManager，可以新建两个类别来区分业务，一个是SDKManager（Network），另一个是APIManager（Store），看起来就更容易理解。
————————————————————————————————
有的程序员会新建一个BaseViewController，然后在它的基础上派生所有的业务ViewController，但是否有这个必要？
其实是没有必要的，原因：
1，使用派生比不使用派生更容易增加业务方的使用成本。（这个应该很好理解，例如NavigationBar的左右BarItem定制）
2，不使用派生手段也可以达到统一设置的目的。
第一个问题，使用派生，业务增加的成本包括：集成成本，上手接受成本，架构的维护难度。
第二个问题，用什么手段达到目的？使用AOP。
使用AOP要达到的目的是：
1，业务方不使用继承的方法，然后框架能够做到对ViewController的统一配置；
2，业务方即使脱离框架，不需要修改任何代码也能跑完代码（这也包含Category的一部分功劳），框架能够起到它应该有的作用。
要实现不通过业务代码对框架的主动迎合，使得业务能够被框架感知这样的功能。细化下来就是两个问题：
1，框架能够拦截到ViewController的声明周期；
2，拦截的定义时机。
对于方法拦截，使用Method Swizzling，在App启动时实现对ViewController的方法拦截，这是一种做法。另一种是在NSObject中的load函数里启动监听。
另外需要考虑的事情就是，原有的BarViewController是会提供额外方法供子类使用的，Method Swizzling只支持针对现有方法的操作，要拓展的话，当然是用Category啦。
——————————————————————————————————
综上所述，Category的好处：
1，减少业务层的成本，让业务更简单；
2，结合AOP解决业务派生的成本问题。
