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 <z...@mac.com> 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 <moon.rab...@virginmedia.com> > wrote: > > > >> On 13 Jul 2017, at 01:32, Jens Alfke <j...@mooseyard.com> wrote: > >> > >>> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes < > moon.rab...@virginmedia.com> 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 <j...@mooseyard.com> 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 < > quinceymor...@rivergatesoftware.com> 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 (Cocoa-dev@lists.apple.com) > > > > 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: > > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > > > This email sent to z...@mac.com > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com > -- -Saagar Jha _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
