一、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收集足够的数据,尤其是你觉得那些有性能瓶颈的地方。
这里边几个选项的含义如下:
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