Memory Graph Debugger - Debugging in iOS - Xcode, Swift, iOS - raywenderlich.com скачать в хорошем качестве

Memory Graph Debugger - Debugging in iOS - Xcode, Swift, iOS - raywenderlich.com

Discover how to find retain cycles and memory leaks using Xcode 8's new memory graph debugger. View other screencasts over here: https://videos.raywenderlich.com/scre... ---- About www.raywenderlich.com: raywenderlich.com is a website focused on developing high quality programming tutorials. Our goal is to take the coolest and most challenging topics and make them easy for everyone to learn – so we can all make amazing apps. We are also focused on developing a strong community. Our goal is to help each other reach our dreams through friendship and cooperation. As you can see below, a bunch of us have joined forces to make this happen: authors, editors, subject matter experts, app reviewers, and most importantly our amazing readers! ---- You use memory graph debugging to help find and fix leaked and abandoned memory. It is a special mode of debugger operation, similar to view debugging, that pauses app execution when invoked. Memory graph debugging displays objects present on the heap and their connection to/relationship with references that are keeping them alive in memory. There are several command-line tools already available for memory analysis on macOS (leaks, heap, vmmap, and so forth). They tend to be underutilized because they are 'outside' the standard Xcode development and debugging workflow, it takes more of an effort to put them to use. Such tools are also not available to the iOS, tvOS, and watchOS device developers. Memory graph debugging brings data from such analytic tools directly into the Xcode debugging workflow, making it more accessible and easier to take advantage of. Background and scope of capabilities Identifying abandoned memory is often difficult; solving its causes can be challenging. Current tools like Allocations can help to identify undesirable memory growth over time, but in an ARC world solving memory growth has become a graph problem. Memory graph debugging brings the equivalent of leaks --trace pointer to Xcode debugging with a progressive disclosure UI. When debugging apps with large object graphs, this helps you answer the question “what’s holding on to my view controller that’s still allocated?” You can quickly pause, find how many of your classes are allocated, and then summon a Quick Look or po an object in the console enabling you to obtain its statistics in a quick, convenient way. Memory graph debugging isn't trying to answer the questions of “How is my process using its memory overall?” or “What memory is counting towards my jetsam limits?” While these are important and difficult questions, the current scope of memory graph debugging focuses on leaks and abandoned memory. Leaked objects Strong reference cycles are the cause for most leaks in code compiled with Automatic Reference Counting (ARC), as is true for many non-ARC leaks as well. Selecting a leaked instance will show its relationships to other leaked memory to aid you in finding the cause of the cycle. Usually the fix will be to break a reference along the chain, for example capturing 'self' weakly in a ^block rather than strongly. When there are multiple references between nodes, the reference will show a count bubble that when clicked will display a popover listing the individual references. The inspector content or contextual menu options (Print Description, Quick Look) may also help in determining which objects are being leaked from which code-paths. If no cycle is immediately visible when selecting a leak but other objects are shown to the left, it's likely that the other cycles or leaks to the left are strongly referencing the selected object and that these should be investigated first. If no other objects show up when a leak is selected, then using Instruments' Leaks template may be helpful for diagnosing non-ARC or __bridging retain/release issues. Referenced objects Most memory referenced by other objects, with paths that eventually lead all the way to 'roots' of your process — Stack memory for an active thread, or global variables in writable __DATA sections of framework/App binaries. Identifying Abandoned Memory isn't easy, but a good starting point is to take a look at the instance counts of types you define and investigate cases where there are more instances present than you'd expect — e.g. "should there really be 15 instances of MyViewController in memory at once?" When you select an object, it will initially appear at the right side of the graph and show incoming references from objects on the left. All incoming references are along the shortest path to some root node in the application. Darker references are known to be "strong" and more certain, while the lighter references are more "conservative" and may simply appear to be references. References are also selectable and will provide some additional information like instance variable names and offsets where available.