This is the total count of persistent and transient objects added together. This is handy because it lets you know if an object is being cleaned up properly or if an object in no longer retained in a particular moment in time. This is the number of deallocated objects that used to be strongly retained but now no longer exist. This is the number of persistent objects that are being strongly referenced in your project at this moment in time. Also, notice the three boxes I have highlighted in red on the top of the Allocation Summary table. In the example above I am profiling a UISearchController object and you can see it it singled out because I have it checked as the only object I want to profile in the Recorded Types pane. I, personally, like to take a survey of my project at different points during the development process and see if all memory is going where I think it should be going based upon my design and then target specific objects using the Recorded Types pane if I see a problem. This is where you can choose to profile NS (Foundation), CF (Core Foundation), malloc (C's version of memory allocation), or lastly, your own custom objects. This is set by the default wildcard (*) option in the Recorded Types pane in the right side of the Instrument window. When your project starts it will start profiling all memory allocations used by all classes and libraries in use in your project by default. Also, at this point it is worth noting that I have always received the most accurate results when profiling my projects on an actual device and not a simulator. Once you select the Allocations template, click the button with a red circle to start recording your allocations.
Apple developer memory monitor instrument how to#
In the following posts I will give a brief overview on how to get started profiling memory allocations in your projects and also explain some of the different techniques I use when profiling memory.
Memory usage is like an art, you can spend your whole career perfecting it and still think you are not using it efficiently. I have always thought that the true elegance of an iOS program or any C program for that matter is in how effectively memory is being used. I personally like to profile memory so I can have an end to end perspective about where memory is going and how effectively it is being used at different points in the project. Profiling gives you a sense of validation about how you have technically designed certain aspects of a project and it also gives you a sense of where you may have gone wrong and inadvertently created retain cycles, memory leaks, or zombies. Profiling memory allocations in a iOS project is probably one of my favorite things to do when building a project besides coding.
0 kommentar(er)
