BROADCASTS.com

Discussion - Allocations and Leaks instruments\n\n\nExtraordinarily hard to spot\nTough to find offending code without help from tools\nUnbounded Memory Growth (memory growth without a chance to collect (deallocate) memory\nTrue Leaks (retain cycles)\nAllocations\n\n\nGeneration Analysis\nTracks allocations still resident when the generation is marked\n\n - As you do multiple generations you will see only the new allocations since the last generations\n\nSimulate Memory Warning (did it help, do you have anything observing for this?)\nI have unbounded memory growth, now what?\n\n - Look for the biggest offenders (sorting)\n - Drill into the code and look for ways to release unnecessary allocations\n\nGood \u2018ol fashion memory management\nIf you\u2019re intentionally holding onto objects, consider implementing an observer for UIApplicationDidReceiveMemoryWarningNotification to release them\n\n\nLeaks / Retain Cycles aka. Strong Reference Cycles\n\n\n Persistent vs. Transient\n Static Code Analyis\n Narrow list to your code\n Use / Observe (detective work)\n \u201cYou\u2019re in the ballpark\u201d now what?\n\n\nReference counting\nWeak and Unowned\n\n\nClosure example with capture list; weak and unowned\n\n\nApple says, \u201cUse a weak reference whenever it is valid for that reference to become nil at some point during its lifetime. Use an unowned reference when you know that the reference will never be nil once it has been set during initialization.\u201d\n\n\n\n\n\n\n\nPicks\n\nDarryl\n\n\nVisual Debugging with Xcode WWDC 2016 Session 410 demonstrates the use of the new Memory Graph Debugger starting at about 24 minutes in\n\n\n\nJohn\n\n\n"Weak, Strong, Unowned, Oh My!" - a Guide to References in Swift by Hector Matos