iOS开发那些事--性能优化–内存泄露问题的解决

简介: <p><strong>内存泄漏问题的解决</strong></p> <p>内存泄漏(Memory Leaks)是当一个对象或变量在使用完成后没有释放掉,这个对象一直占有着这块内存,直到应用停止。如果这种对象过多内存就会耗尽,其它的应用就无法运行。这个问题在C++、C和Objective-C的MRR中是比较普遍的问题。</p> <p>在Objective-C中释放对象的内存是发送rele

内存泄漏问题的解决

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

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

上代码:

- (void)viewDidLoad

{

[super viewDidLoad];

NSBundle *bundle = [NSBundle mainBundle];

NSString *plistPath = [bundle pathForResource:@"team"

ofType:@"plist"];

//获取属性列表文件中的全部数据

self.listTeams = [[NSArray alloc] initWithContentsOfFile:plistPath];

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

{

static NSString *CellIdentifier = @”CellIdentifier”;

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];

}

NSUInteger row = [indexPath row];

NSDictionary *rowDict = [self.listTeams objectAtIndex:row];

cell.textLabel.text =  [rowDict objectForKey:@"name"];

NSString *imagePath = [rowDict objectForKey:@"image"];

imagePath = [imagePath stringByAppendingString:@".png"];

cell.imageView.image = [UIImage imageNamed:imagePath];

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

return cell;

}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{

NSUInteger row = [indexPath row];

NSDictionary *rowDict = [self.listTeams objectAtIndex:row];

NSString *rowValue  =  [rowDict objectForKey:@"name"];

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

UIAlertView *alert = [[UIAlertView alloc]initWithTitle:@”请选择球队”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];

[alert show];

[tableView deselectRowAtIndexPath:indexPath animated:YES];

}


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

在Xcode中提供了两种工具帮助查找泄漏点:Analyze和Profile,Analyze是静态分析工具可以通过菜单 Product→Analyze启动,为静态分析之后的代码画面;Profile是动态分析工具,这个工具叫“Instruments”,它是Xcode 集成在一起,可以在Xcode中通过菜单Product→Profile启动,Instruments有很多Trace Template(跟踪模板)可以动态分析和跟踪内存、CPU和文件系统。

12

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

其中的线段表明了程序执行的路径,在这个路径中,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:方法中的疑似泄漏点行末尾的蓝色图标展开分析结果

3

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

if (cell == nil) {

cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];

}


我们看一下tableView:didSelectRowAtIndexPath:方法中的疑似泄漏点有两个,行末尾的图标展开分析结果。

 4

 message对象创建之后没有释放,我们只需要在[alert show]之后添加[message release]语句代码就可以了。在Objective-C中实例化对象有两种方式:

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

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


①行所示以init-开头构造方法,它的是在alloc之后调用该方法我们称为“实例构造方法”,该方法创建对象所有权是调用者,调用者需要对它的 生命周期负责,具体说负责创建和释放。而另一种是②行所示string-(去掉NS后类名)开头方法,它是通过类直接调用我们称为“类级构造方法”,该方 法是创建的对象所有权非调用者所有,调用者不无权释放它,否则就会因过渡释放而“僵尸化”。

UIAlertView*类型alert对象创建之后没有释放,我们只需要在[alert show]之后添加[alert release]语句代码就可以了,修改之后的代码

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{

NSUInteger row = [indexPath row];

NSDictionary *rowDict = [self.listTeams objectAtIndex:row];

NSString *rowValue  =  [rowDict objectForKey:@"name"];

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

UIAlertView *alert = [[UIAlertView alloc]initWithTitle:@”请选择球队”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];

[alert show];

[alert release];

[message release];

[tableView deselectRowAtIndexPath:indexPath animated:YES];

}


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

5

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

6

出现的泄漏是在点击表视图中单元格测试tableView:didSelectRowAtIndexPath:方法方法时候发生的,其中 NSCFString类型的对象发生了泄漏,NSCFString类型在NSFoundation中是NSString*类型。点击泄漏对象前面的三角形 展开对象,可以看到它们的内存地址、占用字节、所属框架和响应方法信息。

7 打开扩展详细视图,可以看到右边的跟踪堆栈信息,其中我们自己应用代码,可以点击进入我们程序代码,会打开对应代码。 8

代码77并不是泄漏点,而是其中的NSString*类型对象在之后发生了泄漏,因此可以断定是message对象之后没有释放导致泄漏。我们修改代码如下:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{

NSUInteger row = [indexPath row];

NSDictionary *rowDict = [self.listTeams objectAtIndex:row];

NSString *rowValue  =  [rowDict objectForKey:@"name"];

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

UIAlertView *alert = [[UIAlertView alloc]initWithTitle:@”请选择球队”

message:message

delegate:self

cancelButtonTitle:@”Ok”

otherButtonTitles:nil];

[alert show];

    [message release];

[tableView deselectRowAtIndexPath:indexPath animated:YES];

}


添加[message release]语句。很多人还会猜测alert对象(UIAlertView*)会有泄漏,因此重新运行Instruments工具,反复点击单元格测 试,并未发现表示内存泄漏的红线! Instruments工具认为alert对象不释放不会引起内存泄漏,如果我们想进一步评估它对于内存的应用,这个时候我们可以看看 Allocations模板的折线图表,每次点击总占用内存数都有所增加,这说明alert对象没有释放虽然不是很严重,但是也会增加占用内存,因此 alert对象释放也是必须的。

9

这就是我们介绍的内存泄漏问题解决方法,事实上内存泄漏是极其复杂问题,工具使用是一方面,经验是另一方面。提高经验,然后借助于工具才是解决内存泄漏的根本。


目录
相关文章
|
2天前
|
Swift iOS开发 开发者
探索iOS开发中的SwiftUI框架
【7月更文挑战第19天】在移动应用开发的浪潮中,苹果公司的SwiftUI框架如同一股清新的海风,为iOS开发者带来了前所未有的编程体验。本文将深入探讨SwiftUI的核心特性,揭示其如何简化界面设计流程,提升开发效率,并展望SwiftUI在未来iOS开发领域的发展潜力。通过实例分析,我们将一同见证SwiftUI如何塑造更加直观、高效的编程模式。
|
3天前
|
Java Android开发 Swift
探索iOS与安卓开发的差异与挑战
本文深入探讨了iOS和安卓两大移动操作系统在应用开发领域的不同点及其所面临的挑战。通过对开发环境、编程语言、用户界面设计、性能优化及市场策略的比较分析,揭示了各自平台的独特性以及开发者需要克服的技术与市场障碍。 【7月更文挑战第19天】
|
4天前
|
iOS开发 开发者 MacOS
探索iOS开发中的SwiftUI框架
【7月更文挑战第18天】 在苹果的生态系统内,SwiftUI代表着界面构建的未来方向。作为一项现代化的UI框架,SwiftUI不仅简化了代码编写过程,还通过声明式语法提高了开发效率。本文将深入探讨SwiftUI的核心概念、优势以及如何在实际项目中应用它来构建响应式且美观的iOS应用。
17 4
|
3天前
|
Java Android开发 iOS开发
探索安卓与iOS开发的差异:平台特性与用户体验的对比分析
【7月更文挑战第19天】在移动开发的广阔天地中,安卓与iOS两大阵营各据一方,它们在开发环境、用户界面设计、性能优化等方面展现出独特的魅力与挑战。本文旨在深入探讨这两个平台在技术开发和用户体验上的根本差异,并分析这些差异如何影响开发者的策略和最终用户的选择。通过比较两者的编程语言、工具、框架以及设计理念,我们将揭示各自平台的优势与局限,为开发者提供实用的参考,并为消费者呈现一个更加清晰的平台选择视角。
|
22小时前
|
存储 缓存 Java
Android性能优化:内存管理与LeakCanary技术详解
【7月更文挑战第21天】内存管理是Android性能优化的关键部分,而LeakCanary则是进行内存泄漏检测和修复的强大工具。
|
2天前
|
开发工具 Android开发 Swift
探索Android与iOS开发的差异与挑战
【7月更文挑战第20天】在移动应用开发的广阔天地中,Android和iOS两大平台如同双子星座,各自闪耀着独特的光芒。本文将深入探讨这两个平台在开发过程中的主要差异,以及开发者面临的技术挑战。我们将从开发环境、编程语言、用户界面设计、性能优化、安全性考量等多个维度展开讨论,旨在为那些即将踏入或已在这片星空下航行的开发者提供一盏明灯。
|
3天前
|
Java Android开发 iOS开发
探索安卓与iOS开发的差异:平台特性与用户体验的对比分析
在移动应用开发的广阔天地中,安卓与iOS两大阵营各自占据着半壁江山。本文将深入探讨这两个平台在开发环境、编程语言、用户界面设计以及性能优化方面的差异,并分析这些差异如何影响最终的用户体验。通过数据支持的案例分析和最新的市场研究,我们将揭示开发者如何在这两个不同的生态系统中做出战略决策,以及这些决策对应用成功的潜在影响。
|
11天前
|
开发工具 Android开发 iOS开发
探索Android与iOS开发的差异与挑战
【7月更文挑战第11天】在移动应用开发的广阔天地中,Android和iOS两大平台如同双子星座般耀眼,各自拥有独特的开发生态和用户群体。本文将深入分析这两个平台的显著差异,从技术架构到开发工具,再到市场定位,揭示它们之间的异同。通过比较,我们不仅能够更好地理解各自的优势和局限,还能洞察未来移动应用开发的趋势。
|
5天前
|
Java Android开发 iOS开发
探索安卓与iOS开发的差异性与互操作性
【7月更文挑战第17天】在移动应用开发的广阔天地中,安卓和iOS这两大操作系统如同双子星座般璀璨夺目。它们各自拥有独特的开发环境、编程语言和用户群体,为开发者提供了不同的挑战和机遇。本文将从多个维度深入剖析安卓与iOS开发的差异性,并探讨它们之间的互操作性如何实现,以期为开发者们提供一份实用的指南。
16 7
|
4天前
|
安全 Java Android开发
探索安卓与iOS开发的差异:构建未来应用的关键考量
【7月更文挑战第18天】在移动应用开发的广阔天地中,安卓和iOS两大平台各领风骚。本文将深入探讨这两个平台在开发过程中的主要差异,包括编程语言、用户界面设计、性能优化、安全性以及市场策略等方面。通过比较分析,旨在为开发者提供决策支持,帮助他们选择最适合自己项目需求的平台,同时考虑到用户体验和市场需求的变化,为未来的应用开发指明方向。