Swift - 记一次对延迟释放对象的探索

在使用微信朋友圈时，我发现朋友圈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世界里也适用~