Usually, we use Instrument Leaks or third-party libraries to check for memory Leaks. However, the layout of Instrument is more complex because it has many functions. Third party libraries can’t accurately identify multi-level object circular references, and after Xcode 8.0, a simple and effective Memory analysis tool came with the Debug Memory Graph. Because of the complex controller in the project, MVC architecture was previously adopted, with complex business logic and large amount of controller code, MVVM architecture mode was adopted to deal with the development tasks of related controllers. Combined with the project development, the method of analyzing memory cycle references by using debug Memory Graph in the development was recorded and learned.
Details Page:
To go to the details page, click the triangle of three dots in the lower left corner – Step 1. As shown in figure
We can see the memory reference count for all objects in the current app in the left column. Among them, 47 items of TLshipment are relatively large because they are one-time list data requested through the network. Click on the memory drawing of the detail page, we can observe the linear reference relationship of the whole controller, the bright line, that is, the existence of reference relationship.
From xxxxcontroller references as you can see, in TLDetailControllerDataSource instance, malloc memory space, the circular reference from xxxxcontroller. Namely: xxxxcontroller – > xxxxDetailControllerDataSource – > xxxxcontroller – > xxxxDetailControllerDataSource circular reference.
In the figure above, we can see that tabbarController directly references the DetailController controller, because the Tabbar is not hidden at the bottom of the DetailController, and other controllers do not strongly reference the current DetailController.
When I change the code and perform 5 operations to exit detailCongroller, it is clear that the DetailController reference count is 5, indicating that the current controller has been created for 5 times and memory has not been freed. Click on the controller’s memory map: as shown below
There is an obvious reference relationship between Congroller and dataSource, and it is in strong reference and unreleased state. We find this code in the code, and the annotated code is the correct way to write weakened, while the unannotated VC is the wrong way to write unweakened, leading to the circular reference relationship in the project:
The Memory Graph is a very lightweight and fast tool for analyzing memory, but if you need to be more detailed about the time consumed or the specific memory space occupied by each object or class, you can use the tools in the instrument for more detailed analysis.