Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Saagar Jha <email@hidden>
- Date: Fri, 14 Jul 2017 08:37:05 +0000
I don't think view controllers are actually unloaded under memory pressure
anymore. I think I remember reading about that somewhere, but I'll have to
go hunt for it again.
On Thu, Jul 13, 2017 at 12:29 Alex Zavatone <email@hidden> wrote:
> One thing that I had to learn was to break my expectations of when a view
> controller (one that is tied to a navigationController) is deallocated.
>
> My expectations initially were “oh, we’re closing it and going to another
> screen, it will just be deallocated.”
>
> Weeellll, no. It’s part of a stack of view controllers if it’s in a
> navigation controller and the entire stack is what is needed for the user
> to be able to travel back and forth within the list of controllers that are
> “under” that nav controller.
>
> I expect that if the app comes under memory pressure, the instantiated VCs
> will be faulted to disk and if even more pressure, they may be deallocated.
>
> But I’m not really sure about that.
>
> The one thing that I am aware of is that, “just because the user moves on
> to another view controller, that doesn’t mean that the one they left is
> deallocated. I leave that to the OS to figure out. If I have a set of
> view controllers that act as a module, I open a new storyboard, with a new
> nav controller, so that I when complete, I can close the whole thing by
> dismissing it and since there are no more references left, all the memory
> for the whole section is just returned as everything deallocates. This
> approach has worked worked pretty well for me for about 4 years now in
> iOS. It’s not applicable everywhere though.
>
> Cheers,
> Alex Zavatone
>
> > On Jul 13, 2017, at 4:57 AM, Jeremy Hughes <email@hidden>
> wrote:
> >
> >> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
> >>
> >>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <
> email@hidden> wrote:
> >>>
> >>> I’m trying to understand memory management so I can avoid retain
> cycles and other issues.
> >>
> >> That’s fine. But using a weak reference to try to detect when an object
> gets dealloced is fraught with peril, viz. this entire thread :)
> >
> > That was some test code I wrote to investigate a situation I noticed
> while debugging. The actual issue is whether an object (view controller) is
> deallocated rather than when it is deallocated.
> >
> >> On 13 Jul 2017, at 01:32, Jens Alfke <email@hidden> wrote:
> >>
> >> If you want to find out if your code is leaking by creating reference
> cycles, just run it and ask either Instruments or Xcode to find leaks.
> >
> > I was hoping to avoid creating cycles in the first place...
> >
> >> On 13 Jul 2017, at 00:15, Quincey Morris <
> email@hidden> wrote:
> >>
> >> I may be overlooking something important, but I see basically three
> tasks you need to handle to avoid memory management bugs:
> >>
> >> 1. Strong references.
> >>
> >> 2. Weak references.
> >>
> >> 3. Unowned/unsafe references.
> >
> > I’ve abbreviated this summary - but the things that I find confusing are:
> >
> > 1. When to use unowned rather than weak. I’ve read Apple’s Swift book
> and other discussions, and one explanation I found is that unowned is a bit
> like forced unwrapping - you can (or should) use it when you’re sure that
> the reference will always be valid, and it saves you from having to use an
> optional. According to Greg Parker’s email there is also unsafe unretained
> which is different from unowned. I think that unsafe unretained is the same
> as unowned(unsafe) in Swift, but I could be wrong.
> >
> > There is a thread on Stack Overflow where people are confused about the
> difference between unowned and unowned(unsafe).
> >
> >
> https://stackoverflow.com/questions/26553924/what-is-the-difference-in-swift-between-unownedsafe-and-unownedunsafe
> >
> > According to a comment from Dave Abrahams (who I think works at Apple):
> >
> > "unowned and unowned(safe) do incur reference counting cost—that is the
> cost of safety, and why even make unowned(unsafe) available otherwise?—and
> it’s currently worse than regular strong reference counting cost because
> ARC isn’t optimizing for it. Neither throws an exception; they trap when
> misused, permanently stopping the program”
> >
> > But if unowned is a synonym for unowned(safe), I’m not sure what
> “Neither” means in the last sentence - is he talking about safe and unsafe
> unowned, or just unsafe unowned?
> >
> > Apple’s Swift book says:
> >
> > "The examples above show how to use safe unowned references. Swift also
> provides unsafe unowned references for cases where you need to disable
> runtime safety checks—for example, for performance reasons. As with all
> unsafe operations, you take on the responsiblity for checking that code for
> safety.
> >
> > "You indicate an unsafe unowned reference by writing unowned(unsafe). If
> you try to access an unsafe unowned reference after the instance that it
> refers to is deallocated, your program will try to access the memory
> location where the instance used to be, which is an unsafe operation.”
> >
> > At this point I’m pretty confused about the difference between strong
> and safe unowned. I understand that strong retains its reference, but it
> seems to me that Dave Abrahams and Apple’s Swift book are saying or
> implying that (safe) unowned also retains its reference - so the
> consequence of using (safe) unowned incorrectly is that it will create a
> retain cycle, whereas using unowned(unsafe) incorrectly will crash. But if
> unowned(safe) retains its reference, how is it different from strong (apart
> from whether ARC is currently optimising for it)?
> >
> > 2. When to use weak or unowned in closure capture lists (rather than
> default to strong) is also pretty confusing! Presumably the default strong
> option is correct for some or most closures, but I don’t have a very clear
> idea of when it’s not correct.
> >
> > 3. Whether (and when) it’s necessary to avoid using functions or class
> variables whose name begins with new or copy. I don’t think this is
> discussed in Apple’s Swift book (or I haven’t found where it’s discussed),
> but I think it’s necessary for classes that interface with Objective C in
> some way (e.g. subclasses of Cocoa classes).
> >
> > My experience of memory management in Objective-C and Swift (after many
> years of experience with C and C++) is that it mostly “just works” (as
> Apple say in the Swift book) - but there are many cases where you need a
> deeper understanding and it’s hard to find clear explanations.
> >
> > Jeremy
> >
> >
> >
> >
> > _______________________________________________
> >
> > Cocoa-dev mailing list (email@hidden)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-Saagar Jha
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden