内存泄漏指一个对象或变量在使用完成后没有释放掉，这个对象一直占用这部分内存，直到应用停止。如果这种对象过多，内存就会耗尽，其他应用就无法运行。这个在问题C++、C和Objective-C的MRC中是比较普遍的问题。

在Objective-C中，释放对象的内存时，可以发送release和autorelease消息，它们都可以将引用计数减1。当引用计数为0时，release消息会使对象立刻释放，autorelease消息会将对象放入内存释放池中延迟释放。

下面南昌APP制作开发公司-百恒网络为您介绍一下Objective-C工程中ViewController的代码片段：

大家看看，上面的这3个方法会有什么问题呢?如果代码基于ARC，这是没有问题的，但遗憾的这是基于MRC的，都存在内存泄漏的可能性。从理论上讲，内存泄漏是由对象或变量没有释放引起的，但实践证明并非所有的未释放对象或变量都会导致内存泄漏，这与硬件环境和操作系统环境有关，因此我们需要检测工具帮助我们找到这些“泄漏点”。

在Xcode中，共提供了两种工具帮助查找泄漏点：Analyze和Instruments。Analyze是静态分析工具。可以通过Product→Analyze菜单项启动。图1所示为使用Analyze工具进行静态分析之后的代码界面。Instruments是动态分析工具，它与Xcode集成在一起，可以在Xcode中通过Product→Profile菜单项启动。如图2所示，Instruments有很多跟踪模板可以动态分析和跟踪内存、CPU和文件系统。

我们可以结合使用这两个工具查找泄漏点。先使用Analyze静态分析查找可疑泄漏点，再用Instruments动态分析中的Leaks和Allocations跟踪模板进行动态跟踪分析，确认这些点是否泄漏，或者是否有新的泄漏出现等。

在图1所示的Analyze静态分析结果中，凡是有图标的行都是工具发现的疑似泄漏点。点击viewDidLoad方法中疑似泄漏点行末尾的图标，会展开分析结果，具体如图3所示。

图3中的线表明了程序执行的路径。在这个路径中，第1处说明在第25行中，Objective-C对象的引用计数是1，说明在这里创建了一个Objective-C对象。第2处说明在第27行中引用计数为1，该对象没有释放，怀疑有泄漏。这样的说明已经很明显地告诉我们问题所在了，[[NSArray alloc] initWithContentsOfFile:plistPath]创建了一个对象，并赋值给listTeams属性所代表的成员变量，然而完成了赋值工作之后，创建的对象并没有显式地发送release和autorelease消息。这里可以将代码修改如下：

NSArray *array = [[NSArray alloc] initWithContentsOfFile:plistPath];

self.listTeams = array;

[array release];

点击tableView:cellForRowAtIndexPath:方法中疑似泄漏点行末尾的图标，展开分析结果，如图4所示。

这主要说明UITableViewCell *类型的cell对象在第64行有可能存在泄漏。在表视图中，tableView:cellForRowAtIndexPath:方法用于实例化表视图单元格并设置数据，因此cell对象实例化后不能马上释放，而应该使用autorelease延迟释放。可以在创建cell对象时发送autorelease消息，将代码修改如下：

if (cell == nil) {

cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault

reuseIdentifier:CellIdentifier] autorelease];

}

我们再看一下tableView:didSelectRowAtIndexPath:方法中的疑似泄漏点，共有两个。点击行末尾的图标，展开分析结果，具体如图5和图6所示。

图5所示的是message对象创建之后没有释放，我们只需要在[alert show]之后添加[message release]语句代码就可以了。

在Objective-C中，实例化对象有如下两种方式：

NSString *message = [[NSString alloc] initWithFormat:@"您选择了%@队。", rowValue]; ①

NSString *message = [NSString stringWithFormat:@"您选择了%@队。", rowValue]; ②

第①行所示的以init开头的构造方法在alloc之后调用，我们将其称为“实例构造方法”。对于使用该方法创建的对象，其所有权是调用者，调用者需要对它的生命周期负责，具体说就是负责创建和释放。第②行所示的以string开头的方法，它通过类直接调用，我们将其称为“类级构造方法”。对于使用该方法创建的对象，其所有权非调用者所有，调用者无权释放它，否则就会因过度释放而“僵尸化”。

图6所示的是UIAlertView *类型的alert对象创建后没有释放，我们只需要在[alert show]之后添加[alertrelease]语句就可以了。修改之后的代码如下：

上面介绍的是使用Analyze静态分析查找可疑泄漏点。之所以称为“可疑泄漏点”，是因为这些点未必一定泄漏。确认这些点是否泄漏，还要通过Instruments动态分析工具中的Leaks和Allocations跟踪模板。Analyze静态分析只是一个理论上的预测过程。在Xcode中通过Product→Profile菜单项启动Instruments动态分析工具，接着选择Leaks模板，打开的界面如图7所示。

在Instruments中，虽然选择了Leaks模板，但默认情况下也会添加Allocations模板。基本上凡是分析内存都会使用Allocations模板，它可以监控内存分布情况。选中Allocations模板(图中①区域)，右边的③区域会显示随着时间的变化内存使用的折线图，同时在④区域会显示内存使用的详细信息以及对象分配情况。点击Leaks模板(图中②区域)，可以查看内存泄漏情况。如图8所示，如果在③区域有红线出现，则有内存泄漏，④区域则会显示泄漏的对象。

图8中出现的泄漏是在点击表视图中单元格测试tableView:didSelectRowAtIndexPath:方法时发生的，点击泄漏对象Address列后面的按钮，会进入如图9所示的详细界面。可以发现，里面有两个对象，可以看到它们的内存地址、占用字节、所属框架和响应方法等信息。

在图9中，点击右边的跟踪堆栈信息按钮，如图10所示，其中图标所示的条目是我们自己应用的代码，点击它即可进入程序代码，如图11所示。

图11所示的第84行代码是可能的泄漏点。事实上，内存泄漏是极其复杂的问题，工具使用是一方面，经验是另一方面。提高经验，然后借助于工具才是解决内存泄漏的根本。

以上就是南昌APP制作开发公司纪念堂所要讲的内容，可能有点长，但是非常实用，希望对大家有所帮助，了解更多关于APP开发技术，欢迎来电咨询百恒网络，欢迎访问百恒网络官网查看相关文章，网址：http://www.jxbh.cn/