以前我们经常会重写控制器的dealloc方法，并且在dealloc方法中加上[[NSNotificationCenter defaultCenter] removeObserver:self];这行代码。好消息是现在的版本，xcode7以上不用重写dealloc方法，在里面加上这行代码了。那么，为什么这么说呢？为了佐证我的猜测，我尝试弄清楚UIViewController的dealloc方法是怎么实现的。
依稀记得xcode5以前(具体版本记不清楚了，反正就是比较早的版本)，那时候系统的控制器dealloc方法中还不会自动调用移除观察者的方法，需要我们手动移除，否则等控制器销毁后，通知没有移除，就可能发生崩溃。
下面写个demo来证明UIViewController的dealloc方法中确实调用了[[NSNotificationCenter defaultCenter] removeObserver:self]方法。首先我们要先建一个NSNotificationCenter的分类，代码如下
属性runtime的同学应该很清楚，这是runtime的交换方法，目的是为了跟踪系统调用removeObserver:，当调用此方法时会打印--my_removeObserver-。
然后我们要写一个控制器的跳转，在DXViewController控制器销毁时，系统会调用控制器的dealloc方法。
新建一个DXViewController类，继承UIViewController，DXViewController.m如下
上面这2步其实就是从ViewController跳转到DXViewController，然后从DXViewController跳回ViewController时，DXViewController控制器会销毁，系统会自动调用[DXViewController dealloc]方法，熟悉mrc的同学应该知道，其实31行代码还有一行隐藏的[super dealloc]方法，也就是我们的UIViewController的dealloc方法，下面我们来看看为什么说在UIViewController的dealloc方法中确实调用了[[NSNotificationCenter defaultCenter] removeObserver:self]方法。
我们故技重施，给UIViewController添加一个分类，目的是交换它的dealloc方法，跟踪它的调用，代码如下(这个类要打开mrc， -fno-objc-arc)
运行项目，我们可以看到打印如下
证明在UIViewController的分类的第29行代码[self my_dealloc]里面确实调用了移除通知的方法，这里的[self my_dealloc]其实就是UIViewController的dealloc方法(不懂的同学可以去弄清楚runtime交换方法是怎么用的)。
问题到这里其实还没完，我们只能证明【UIViewController dealloc】方法里面确实调用了[[NSNotificationCenter defaultCenter] removeObserver:self]方法，但是不能证明一定是UIViewController dealloc】调用了移除通知中心的方法，因为dealloc方法中其实是[super dealloc]。。为了证明移除观察者方法不是在UIViewController的父类UIResponder的dealloc中调用，我们必须还要再做一件事。
给UIResponder添加一个分类，重写dealloc方法，代码如下。原理：(在分类中覆写原有类的方法，系统只会调用分类的方法)
再次运行项目，发现打印跟上面一样。至此，我们排除了UIViewController的父类UIResponder以及其父类的父类等的影响，确定了系统在UIViewController的dealloc方法中调用了[[NSNotificationCenter defaultCenter] removeObserver:self]方法。
结论：只要控制器能正常释放(不出现循环引用控制器，会走dealloc)的前提下，我们不用重写控制器的dealloc方法，在里面加[[NSNotificationCenter defaultCenter] removeObserver:self]代码了。
启发:随着iOS版本的升级,苹果其实会优化UIKit或者其他框架的实现，比如[[NSNotificationCenter defaultCenter] removeObserver:self]系统就帮我们写了。即使强大如苹果，也在一直优化它的框架和代码的实现，我们也应该不断跟苹果学习优化自己的代码。
预告:3种方法探究苹果类的底层实现
网友评论