简介 平常我们都会用 Instrument 的 Leaks 或第三方库排查内存泄露，但是在Instrument 功能众多，布局更为复杂；第三方库无法准确识别多层对象循环引用，在 Xcode 8.0之后 ，自带一种简单有效的内存分析工具：Debug Memory Graph。 因为项目中复杂的控制器，之前采用的MVC架构，业务逻辑复杂，controller代码量大，对于处理这相关控制器的开发任务，采用MVVM架构模式，结合项目开发，把开发中使用debug memory graph分析内存循环引用的方法记录学习。
详情页面：
进入详情页，点击左下角的三个圆点组成的三角形-步骤1。如图
我们可以在左边栏目看到当前整个app中所有对象的内存引用计数。其中TLshipment有47个，因为是通过网络请求的一次性列表数据，所以数量相对较多。点开详情页的内存绘制图，我们可以观察到整个控制器的线性引用关系，亮色的线条，即为存在引用关系。
从xxxxcontroller 的引用关系可以看到，在TLDetailControllerDataSource实例，malloc 内存空间中，循环引用了 从xxxxcontroller。即： xxxxcontroller ->xxxxDetailControllerDataSource -> xxxxcontroller -> xxxxDetailControllerDataSource循环引用。
上图中我们可以看到tabbarController直接引用了detailcontroller 控制器，是因为detailController底部未隐藏tabbar，其他控制器不存在强引用当前detailController。
当我改变代码，操作5次进入退出detailcongroller，可以明确看出，detailcontroller 引用计数为5，说明创建了5次当前控制器，并且未释放内存。点开控制器的memory 内存图：如下图
congroller 与 dataSource 之间有明显的引用关系，并且为强引用、未释放状态，我们在代码中找到这段代码，被注释代码为已弱化的正确写法，未注释的vc 为未弱化的错误写法，导致项目存在循环引用关系：
使用memory graph 是非常轻量且快速分析内存的好助手，但是如果是需要更加细致到每一个对象或者类的消耗的时间或者是占用的具体内存空间，使用instrument内的工具分析更详尽。