经验之道：最有效的iOS内存泄漏检测

时间 2019-11-06

标签经验之道有效 ios 内存泄漏检测栏目 iOS 繁體版

原文原文链接

版权声明：本文由胡涛原创文章，转载请注明出处:
文章原文连接：https://www.qcloud.com/community/article/125模块化

来源：腾云阁 https://www.qcloud.com/community工具

使用instruments工具来更好的调试咱们的工程中新开发或者修改过的模块的内存情况。性能

iOS设备性能愈来愈好，iOS App 也相应的变得愈来愈庞大，App代码的量级也在快速的增加，开发一个小的模块在工程中调试变的愈来愈难，一般咱们是经过观察Allocation的内存变化高低，或者内存分配快照对比来寻找泄漏的状况，但这几乎是一个让人抓狂的调试方法，尤为在很是复杂的项目中，一个模块的推入与推出在Allocation上的变化微乎其微，并且受制于项目的复杂度，各类你所未知的对象的建立与销毁带来的Allocation图形高度的影响，对于观察Allocation的分配图像的高低变化来讲，可以参考的意义就变的很是有限。测试

经过过去参与过的复杂大型的iOS项目开发经验，开发新的模块的时候，总结出了一套完整的iOS内存自测的方法，经过Instruments来逐步跟踪检测咱们建立和主动销毁的对象是否真的销毁了。调试

在演示以前，须要强调一件事情就是，以文件夹目录做为你的空间命名很重要，请遵循开发新模块的时候使用你的模块的命名做为前缀。由于iOS没有命名空间这个东西，一般为了保证不冲突，咱们都是以项目前缀＋空间命名来保证文件的独立性，空间名就是目录和模块的名字了。这个在咱们使用instruments进行内存检测的时候是很是重要的，接下来的使用过程就能够证明这一良好的命名习惯所带来的巨大好处，不仅是优雅，更重要的是帮助。orm

除了命名，还有一件很重要的事情就是，你须要对你的模块在各类UI操做或者事件发生过程的状况下，对你的对象分配过程要很是很是清楚，由于这样，你才能看出相应的变化，哪些对象是应该存在的，哪些对象在某个动做结束后是一定会销毁的，这个应该很容易，你应该纯自然的就知道，由于你开发的整个逻辑。对象

最近在开发一个新的模块，正好须要在内存方面作一个完整的自测，既要确保效率，也要确保内存的正确分配与释放。教程

重要：（如下教程开始全部示例图片，请自行点击图片看大图，看的倍儿清楚！）事件

首先，我先上图，看一下个人命名组织结构，遵循的就是模块化的命名，由于手Q的跨部门合做，因此用部门标记做为前缀。代码首先是要让人来看的，是人在维护程序，因此可读性很是重要，在开发完这些功能后，我对于全部对象在运行过程当中的建立与销毁是很清楚的。
图片
接下来我要进入instruments来进行内存测试，profile运行Leaks就OK了，就会进入下面看到的界面，详细讲解一下都是什么吧，这些对对象怎么分配内存的很重要。
而后我就须要操做模拟器来进入我所开发的功能模块，会看到很是复杂的对象分配状况，因此这一步很是关键，我只须要在搜索框搜索模块的前缀就能够只显示当前模块所涉及的对象分配与销毁状况，以下图，进入了的模块视图：
接下来我执行一个环境查询的命令，再看一下执行以后的内存分配状况。
个人逻辑是这样的，点击一次建立一个命令(VASDebugPlatformServerCmd)，经过这个命令初始化并执行一个任务，任务结束后就销毁这个任务对象(VASDebugPlatformBaseOperation)，相应的命令也做为任务的成员一块儿被销毁。因此，在动做执行完后咱们应该能够在已销毁对象中找到这个实例，运行截图以下：
我看到任务是已经被销毁了的，但是用来初始化的命令对象为何没有被销毁，我须要深挖一下这个命令对象(VASDebugPlatformServerCmd)的引用计数到底怎么发生变化的，就须要用到下面的步骤了，按照图解去深挖它：
我挖到命令对象的内部，一路挖到底，我发现命令对象最终的引用计数是1，证实它还在内存中活着，截图是这样的：
因此，我就看看，任务对象销毁了，那任务对象到底发生了什么事截图是这样的：
我就是不死心，我就是要看到，究竟是不是真的呢，为了进一步佐证命令对象在内存中，我在对象内部观察了一个内存检测的通知，收到通知后弹一个alert出来，若是对象被销毁了，它确定收不到这个通知，以下面截图所示的工做：
由于这是我本身写的逻辑，我很清楚对象在哪里分配内存，而后我就去查代码，命令对象到底经历了什么，从开始到结束的执行过程是什么样的：
看完上面的截图，再去看命令对象的引用计数变化就知道为何了：
固然，我也看出了为何引用计数没有归零，因此，我在下面进行了修复：
再次profile->Leaks , 而后我再作一次查询任务，看看此次命令对象的引用计数变化，命令对象被释放了！：

总结：

保持你的模块拥有一个良好的命名空间
请深入而且清楚的知道，触发什么事件，执行UI动做以后，你的对象分配会是什么样的，谁此刻应该存在内存中，谁应该被销毁，而后利用上面的原理去查看，它是否是被销毁了，若是没有被销毁，那么你应该去查你的代码，到底在执行过程当中，哪里没有平衡引用计数。
此方法在ARC和MRC的状况都是适用的，目标是观察具体哪一个实例对象没有被销毁，而后根据引用计数变化跳转到代码中去确认哪里出现了内存问题。

文章来源于公众号：小时光茶社（Tech Teahouse）