十年专注于品牌网站建设 十余年专注于网站建设_小程序开发_APP开发,低调、敢创新、有情怀!
南昌百恒网络微信公众号 扫一扫关注
小程序
tel-icon全国服务热线:400-680-9298,0791-88117053
扫一扫关注百恒网络微信公众号
扫一扫打开百恒网络微信小程序

百恒网络

南昌百恒网络

APP开发之使用Analyze和Instruments工具解决内存泄漏问题

百恒网络 2017-05-26 4203

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

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

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

Objective-C工程中ViewController的代码片段一

Objective-C工程中ViewController的代码片段二

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

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

使用Analyze进行静态分析的代码界面

Instruments分析工具

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

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

viewDidLoad方法的疑似泄漏点展开结果

图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所示。

tableView:cellForRowAtIndexPath:方法的疑似泄漏点展开结果

这主要说明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 tableView:didSelectRowAtIndexPath:方法疑似泄漏点1的展现结果 图6 tableView:didSelectRowAIndexPath:方法疑似泄漏点2的展开结果

图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]语句就可以了。修改之后的代码如下:

UIAlertView *类型的alert对象创建后没有释放

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

Instruments的Leaks模板

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

Instruments检测到的内存泄漏

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

查看泄露的详细信息

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

图10 查看堆栈信息 图11 查看泄漏点

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

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

400-680-9298,0791-88117053
扫一扫关注百恒网络微信公众号
扫一扫打开百恒网络小程序

欢迎您的光顾,我们将竭诚为您服务×

售前咨询 售前咨询
 
售前咨询 售前咨询
 
售前咨询 售前咨询
 
售前咨询 售前咨询
 
售前咨询 售前咨询
 
售后服务 售后服务
 
售后服务 售后服务
 
备案专线 备案专线
 
×