Deinit never called

问题:

I'm creating a ViewController object an pushing it to a navigation controller. When the object is being popped from the stack - it is not being release and Deinit is not being called. What can be the reason for that?

Here's the code that pushes:

self.navigationController?.pushViewController(CustomViewController(), animated: true)

And here's the code that pops:

 self.navigationController?.popViewControllerAnimated(true)

回答1:

I had similar problem. I added empty deinit method to my class and added breakpoint:

deinit {

}

As result it's never called.
As soon as I add some code to the body it started working as expected:

deinit {
    print("deinit called")
}

So be sure that your deinit method isn't empty.
PS. I am using Swift 2, Xcode 7.1

回答2:

Do any of your classes, or properties they contain make a reference to the view controller you've popped?

If your UIViewController has created an instance of an object, which in turn makes a 'strong' reference to that view controller (e.g. a reference that's not explicitly declared 'weak' or 'unowned'), and your view controller keeps a strong reference to that object as well, neither will be deallocated. That's called a strong reference cycle, documented here (a must read for serious Swift developers):

The Swift Programming Language (Swift 3.0.1): Automatic Reference Counting

Closures are a more insidious case where you can get into trouble.

One thing you might try as an experiment is pushing the controller and popping it before you do anything in viewDidLoad or in the initialization, and see if the deinit method is being called. If it is, then you should be able to incrementally discover what you're doing that's leading to the symptom you're seeing.

Another thing that can thwart diagnosis (as other answers have pointed out), which I learned the hard way, is that the debugger breakpoint won't be taken for deinit() if the deinit method contains no executable statements, because the OS or compiler optimizes the deinit invocation away if it's empty, so at least put a print statement there if you want to verify deinit() is getting called.

回答3:

I was using this tutorial Custom TabBar with a custom seque on the given page. The memory problem was due a subview which had a strong reference the the parent viewcontroller.

class WBMNewsFeedV: UIView
{
   var parentVC:WBMHomeTabVC!
}

WBMNewsFeedV - subclass

parentVC:WBMHomeTabVC - parent class ViewController

I changed it to :

class WBMNewsFeedV: UIView
{
    weak var parentVC:WBMHomeTabVC!
}

So, the strong reference was nested inside a subviews and not visible at first. Hope this helps anyone. After the change deinit was always called in

WBMHomeTabVC

回答4:

I had the same issue when the NotificationCenter was holding a strong reference to the presented view controlled and thus it was never getting released. So I had to add [weak self] to the block like this:

(in the viewDidLoad)

NotificationCenter.default.addObserver(forName: .showFoo, object: nil, 
  queue: OperationQueue.main) { [weak self] (notification) in
    if let foo = notification.userInfo?["foo"] as? Foo {
            self?.afooButton!.setImage(UIImage(named: "foo"), for: .normal)
    }
}

回答5:

I had a timer in my view controller, running every minute to update a label. I put a call in deinit to invalidate the timer, which I'm pretty sure is what I've always done in Objective-C (in dealloc) and it's worked. But it seems a little different in Swift so I moved the time creation/invalidation code to viewWillAppear/viewWillDisappear (which makes more sense really) and everything seems fine now!

回答6:

add some line code of in deinit. If You put breakpoint at Empty deinit ,compiler will not stop you there put this:

deinit {
print("any thing")
}

It will work ;)

回答7:

I just ran into a similar issue. My problem appears to have been caused by a strong reference to a control that had delegate assignment not specified as 'weak' with a class type protocol.

回答8:

I faced the same Problem. In my case a never ending cycle of UIView.animateWithDuration... holds the ViewController in Memory and blocks the call of deinit. If you use something like this you have to stop it first bevor you remove the ViewController. Hope that helps.

回答9:

Just to add an edge case which I found very difficult to detect:

If you allocate any UnsafeMutablePointers and provide self (the UIViewController) as pointee inside of your view controller, make sure to call pointer.deinitialize(count:), not just pointer.deallocate().

Otherwise, the reference to self will remain and the UIViewController will not deinitialize.

回答10:

First of all make sure to define deinit

deinit {
    print("OverlayView deinit")
}

Use Xcode's object graph to check number of instances being created and if they are not getting deallocated then they will keep growing. I was creating property of another ViewController on top of the file so i move it and place it in the scope it was being used that solved my problem. And its deinit started calling.

Moreover i was using a uiview property to show a overlay that need to be accessed from my viewcontroller at some places i make it optional and set it nil when after calling removefromsuperview on it.

var overlay: OverlayView?
overlay = nil

If still dealloc not calling then there could be a retain cycle issue as described above in that case you will have to check another viewcontroller(B) too if its calling back this controller(A) then set one of them as a weak variable.