好记性不如烂笔头,所以决定写篇博客陆陆续续地记录一些使用Instruments的技巧。
1. 内存泄露的检测。
Memory Leak是编码过程中最基本的一类问题,即请求了内存分配,却没有归还给操作系统。
使用Instrument可以帮助我们进行内存泄露的检测,不过先想想,如果要我们来检测内存泄露,会怎么做呢?一种最直接的方法就是通过遍历构造一张堆上的内存分配、引用图,检测每一块内存是否有引用存在。如果没有,则表示存在内存泄露;如果有,却并不代表不是内存泄露。所以,Instruments并不能检测出所有的内存泄露。
我们可以简单地分配一块内存,不释放,来检测内存泄露:
NSArray *array = [[NSArray alloc] initWithObjects:@"1", @"2", nil];然后使用Instruments的Leak检测功能,可以得到下图:
橙色区域表示存在内存泄露,很显眼。并且在下方会显示出具体的代码位置:
此时,我们可以打开Extended Detail视图观察具体的函数调用,确定分别在哪里发生了泄露:
双击可以打开源文件(右上Xcode图标可以通过Xcode打开源文件进行定位):
但是,并非所有类型的对象都可以被检测出来,比如UI对象以及NSString,猜测是由于存在对这些资源的内部管理机制。
下面的代码,Instrument并不能检测出内存泄露:
NSString *string = [[NSString alloc] initWithString:@"LeakString"]; UILabel *label = [[UILabel alloc] init]; label = nil; UIButton *btn = [[UIButton alloc] init];
2. 使用Heapshot进一步观察内存泄露。
如果有指针指向一片内存区域,但代码无法再访问到该指针;或者存在循环引用。这些情况下,Instrument都无法检测出内存泄露。
不过Instruments提供了堆快照来进一步观察:
理想情况下,我们进入一个ViewController,然后再退回来,如果得到合理分配和释放的话,堆的增长应该是零(或者趋向零,因为有些资源可能iOS自己管理住了):
如果内配和释放不合理的话,通常每次堆快照都会有所增长,并且在多次重复操作后,依然增长:
如果存在这种情况,就需要特别关注下。
同样地,我们也可以通过Extended Detail视图来查看此时的函数调用信息,确定这些增长发生在哪里。
3. Zombie Messaged
访问野指针。直接原因是通过指针释放对象后,指针没有置空;间接原因可能是过于随意地使用autorelease的对象,系统释放后,我们还访问。关于什么时候系统会释放auto-released对象,可以参照我写的这篇文章。
- (void)zombieTest:(id)sender { UILabel *label = [[UILabel alloc] init]; [label release]; [sender addSubview:label]; }
如上代码,就会让程序挂掉,而且有时候很难排查。这种情况可以通过Instruments的Zombie选项来跟踪:
开启最下面的选项“Enable NSZombie detection”,然后跑一下程序:
同样可以定位到相应的代码:
4. Time Profiler
当我们发现App有点卡的时候,可以通过Time Profiler来看耗时在哪里。
通过运行时间可以找出卡在哪里,从而进行优化。
但耗时最多的并不一定就是App流畅性的瓶颈。举个例子,我之前写了一个瀑布流控件(相关博文),在实现cell重用机制的基础上,仍然发现滚动时候有点卡。于是我通过Time Profiler观察,发现scrollViewDidScroll的耗时占比有点高,以为在滚动回调函数做的事情太多,我陷进了在相关代码上死命寻找可优化的坑上,走上了过度优化的岔路。后来发现,是由于当时团队成员修改了图片异步加载相关代码导致的。
5. 真机观察Core Animation性能
通过联调真机,可以观察到运行时每秒绘制了多少帧(60帧封顶):
当帧率偏低时,就得注意优化了。
调试过程中,可以通过设置左侧面板的调试选项来获得更多信息:
比如上图中,我们勾选了“Color Blended Layers”选项,可以得到如下红绿分布图:
其中绿色代表不透明部分,红色代表透明部分。红色部分越多,对性能影响也越大,因为GPU需要对这些透明部分进行特殊处理(重复绘制)。
从上面的帧率以及红绿分布来看,湖畔这款App的性能还是不错的。
[To be continued...]