好记性不如烂笔头，所以决定写篇博客陆陆续续地记录一些使用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...]