iOS开发基础性知识(二十)----内存分析工具的使用和作用

96
NBeanN
0.1 2017.05.24 10:59* 字数 2616

一、Analyze【静态分析】

XCode Product——>Analyze 或者 command+shift+B

Analyze的作用:

1、逻辑错误:访问空指针或未初始化的变量等;

2、内存管理错误:如内存泄漏等;

3、声明错误:从未使用过的变量;

4、Api调用错误:未包含使用的库和框架。


二、Instruments 【动态分析】

XCode的Product——>Profile——>Instruments——> Leaks 或者command+I

Leaks启动后会开始录制,随着对模拟器运行的App的操作,可以在Leaks中查看内存占用的情况。

注:如果你的项目使用了ARC,随着你的操作,不断开启或关闭视图,内存可能持续上升,但这不一定表示存在内存泄漏,ARC释放的时机是不固定的。

Leaks顶部分为两栏:Allocations和Leaks,右侧的曲线代表内存分配和内存泄漏曲线。

点击第二栏Leaks,进行内存泄漏分析,左下角会出现Leaks调试的选项:

建议把Snapshot Interval间隔时间设置为10秒,勾选Automatic Snapshotting,Leaks会自动进行内存捕捉分析。

在你怀疑有内存泄漏的操作前和操作后,可以点击Snapshot Now进行手动捕捉。

Leaked Object的表格中显示了内存泄漏的类型、数量及内存空间。

点击具体的某个内存泄漏对象,在右侧Detail窗口中会出现导致泄漏可能的位置,其中黑色头像代表了最可能的位置。

熟练使用Leaks后会对内存泄漏判断更准确,在可能导致泄漏的操作里,多使用Snapshot Now手动捕捉。

开始时如果设备性能较好,可以把自动捕捉间隔设置为5秒钟。

使用ARC的项目,一般内存泄漏都是malloc、自定义结构、资源引起的,多注意这些地方进行分析。

开启ARC后,内存泄漏的原因

开启了ARC并不是就不会存在内存问题,苹果有句名言:ARC is only for NSObject。

在IOS 中使用malloc分配的内存,ARC是不会处理的,需要自己进行处理。


三、Instruments Allocation 【内存分配分析】

XCode的Product——>Profile——>Instruments——>Allocations

内存泄漏:是指内存被分配了,但程序中已经没有指向该内存的指针,导致该内存无法被释放,产生内存泄漏。

内存不合理运用:苹果官方称这种情况为Abandoned Memory,也就是存在已分配内存的引用,但实际上程序中不会使用,比如图片等对象加入了缓存,但缓存中的对象一直没有被使用。

XCode提供的Instruments中的Allocation工具可以用来帮你了解内存的分配情况,当你的App收到内存警告时,首先应该用Allocation进行内存分析,了解哪些对象占用了太多内存。

启动后Allocation面板显示了内存中的对象占用曲线,可以显示目前中内存分配了哪些对象,对象的数量,以及由哪些函数进行的创建。

左侧有几个比较有用的选项:

All Objects Created

Created & Still Living

Created & Destroyed

通过以上方法可以对应用的整体内存使用情况有所了解,但内存不合理使用导致的内存警告往往是部分代码或视图导致的,我们往往要关注于某段时间或操作过程中内存的分配和使用情况,Allocation提供了这种功能。

比如在进入一个视图前或操作前,我们在Allocation面板左侧点击Mark Generation,这时候会产生Generation A节点,显示内存当前的情况:

我们可以在进入视图后再点一次Mark Generation,在视图退出后再点一次Mark,这样三次产生的 Generation分别记录了进入前、进入后、关闭后,再最后一个Generation应该内存被合理释放,否则就代表了在这个视图或操作中有泄漏或不合理的地方。

以上只是Allocation的基本运用,设计出一套使用Allocation来合理测试的方案是比较复杂的,后续慢慢介绍。


四、Zombies【僵尸对象分析】

XCode的Product——>Profile——>Instruments——>Zombies

被过度释放的对象(overreleased objects)

在使用ARC之前,很多人遇到过EXC_BAD_ACCESS错误,这个错误可以理解为访问了已被释放的对象,苹果称之为僵尸对象。

在开启ARC后,可以很大程度上避免产生EXC_BAD_ACCESS错误,但也是有出现可能的,比如IOS里使用了C++代码,C++部分的对象是不会有ARC来管理的。

EXC_BAD_ACCESS错误不像访问空指针一样容易定位,往往报错时很难查找到错误点,所以XCode在Instruments中提供了单独的Zombies工具来分析这类错误。

可以看到Zombies工具下边的介绍,用于查找那些被过度释放的僵尸对象。

Zombies工具的查找原理其实和设置NSZombieEnabled环境变量的调试方式是一样的,启动Zombies后在内部设置了NSZombieEnabled为True。

启用了NSZombieEnabled的话,它会用一个僵尸来替换默认的dealloc实现,也就是在引用计数降到0时,该僵尸实现会将该对象转换成僵尸对象。僵尸对象的作用是在你向它发送消息时,就不会向之前那样Crash或者产生 一个难以理解的行为,而是放出一个错误消息,它会显示一段日志并自动跳入调试器, 因此我们就可以找到具体或者大概是哪个对象被错误的释放了。

1、启动Instruments,选择Zombies;

2、对之前产生EXC_BAD_ACCESS的测试用例重新运行,直到程序崩溃,如果发生EXC_BAD_ACCESS错误,会出现以下界面:

3、通过滑动箭头来查看错误细节,例如可以看到该对象的内存操作过程,如malloc、autorelease、retain、release等操作;

4、查看底部的详细历史,选择相应的行可以定位到相应的代码,找出产生错误的代码:

基本上通过查看Zombies工具给出的信息找出错误代码行是比较简单的,Zombies也只有在产生EXC_BAD_ACCESS错误时才有用。


五、Time Profiler【查看时间占用】

XCode的Product——>Profile——>Instruments——>Time Profiler

Time Profiler还有之前介绍过的Leaks、Allocations工具,被戏称为Instruments的救命三招,是当应用遇到问题时首先应当使用的三个工具。

Time Profiler帮助我们分析代码的执行时间,找出导致程序变慢的原因,告诉我们“时间都去哪儿了?”。

Time Profiler分析原理:它按照固定的时间间隔来跟踪每一个线程的堆栈信息,通过统计比较时间间隔之间的堆栈状态,来推算某个方法执行了多久,并获得一个近似值。其实从根本上来说与我们的原始分析方法异曲同工,只不过其将各个方法消耗的时间统计起来。

选择Time Profiler工具开始测试,这时会自动启动模拟器和Time Profiler录制。

先进行一些App的操作,让Time Profiler收集足够的数据,尤其是你觉得那些有性能瓶颈的地方。


1
2
3

这里边几个选项的含义如下:

Separate by Thread: 每个线程应该分开考虑。只有这样你才能揪出那些大量占用CPU的"重"线程

Invert Call Tree: 从上倒下跟踪堆栈,这意味着你看到的表中的方法,将已从第0帧开始取样,这通常你是想要的,只有这样你才能看到CPU中话费时间最深的方法.也就是说FuncA{FunB{FunC}} 勾选此项后堆栈以C->B-A 把调用层级最深的C显示在最外面

Hide Missing Symbols: 如果dSYM无法找到你的app或者系统框架的话,那么表中看不到方法名只能看到十六进制的数值,如果勾线此项可以隐藏这些符号,便于简化数据

Hide System Libraries: 勾选此项你会显示你app的代码,这是非常有用的. 因为通常你只关心cpu花在自己代码上的时间不是系统上的

Show Obj-C Only: 只显示oc代码 ,如果你的程序是像OpenGl这样的程序,不要勾选侧向因为他有可能是C++的

Flatten Recursion: 递归函数, 每个堆栈跟踪一个条目

Top Functions: 一个函数花费的时间直接在该函数中的总和,以及在函数调用该函数所花费的时间的总时间。因此,如果函数A调用B,那么A的时间报告在A花费的时间加上B花费的时间,这非常真有用,因为它可以让你每次下到调用堆栈时挑最大的时间数字,归零在你最耗时的方法。

上面的参数在实践中合理设置,也没有什么太多技巧,就是通过数据的隐藏、显示让我们更关注于想找到的数据。


参考文章

菜鸟走向大牛,大家共同前进,如果觉得不错,请给个赞/关注。

一起交流学习,有问题随时欢迎联系,邮箱:383708669@qq.com

日记本
Web note ad 1