在使用微信朋友圈时，我发现朋友圈ViewController在pop后再进入，列表内容依然是和我pop前的内容一样。这引发了我对微信对朋友圈优化的猜测：延迟朋友圈ViewController的释放。
无庸置疑的是微信iOS用Objective-C，至于还是不是MRC，我就不知道了。Swift没有MRC一说，只能ARC，对象的释放是引用说了算。接下来的探索是一次失败的尝试，但是非常有趣。
首先，我写了一个测试对象。我希望在它deinit中，增加对它的引用，以此来尝试阻止它的释放和销毁。
class TestObject: NSObject {
deinit {
print("Test Object deinits: \(self)")
DelayDeinitManager.append(self)
}
}
在DelayDeinitManager中，我保存对这个对象的引用，并在5秒后尝试再次释放它。
class DelayDeinitManager: NSObject {
static var objects = [AnyObject]()
class func append(_ obj: AnyObject) {
objects.append(obj)
Timer.scheduledTimer(withTimeInterval: 5, repeats: false) { _ in
print("5秒后释放对象...")
DelayDeinitManager.objects.removeFirst()
}
}
}
上面这样的写法“貌似”没问题，让我们来run一下。
override func viewDidLoad() {
super.viewDidLoad()
TestObject()
TestObject()
TestObject()
}
我希望看到三行“5秒后释放对象...”。但事实上我们很快迎来的crash。
我们开启Zombie Objects后再run一次，就会发现原因了。
嗯，我们向一个已释放的对象发送消息了。这说明，在deinit中增加对象引用是留不住它的，该走的还是得走。如果我们
print(DelayDeinitManager.objects.count)，会发现确实有3输出，而且不会crash。这是因为我们此时访问的是DelayDeinitManager.objects这个容器，该容器里确实有3个指针，只是这3个指针都是躯壳，它们所指向的对象都已经在接收到deinit消息后，释放掉了。这也是我们知道的“野指针”。
这再次证明了Swift的ARC是不允许我们随意控制对象的释放的，轮不到人类来干预。“生死有命，富贵在天”，在Swift世界里也适用~
