相对电脑而言，移动设备具有内存少、CPU速度慢等特点，因此iOS开发人员需要尽可能优化应用的性能。性能优化需要考虑的问题很多，下面南昌网站制作公司小编和大家一起来学习几个重要的优化方法。今天我们来重点学习一下程序性能优化之内存优化。

在Swift语言中，内存管理采用ARC(Automatic Reference Counting，自动引用计数)。ARC是与MRC(ManualReference Counting，手动引用计数)相对而言的，这些概念来源自于Objective-C的内存管理方式。

1.内存管理

这里我们有必要先介绍一下Objective-C的内存管理方法，共有3种，分别介绍如下。

MRC。就是由程序员自己负责管理对象生命周期，负责对象的创建和销毁。

ARC。采用与MRC一样的内存引用计数管理方法，但不同的是，它在编译时会在合适的位置插入对象内存释放(如release、autorelease和retain等)，程序员 不用关心对象释放的问题。苹果推荐在新项目中使用ARC，但在iOS 5之前的系统中不能采用ARC。

GC。在Objective-C 2.0之后，内存管理出现了类似于Java和C#的内存垃圾收集技术，但是垃圾收集与ARC完全不同，垃圾收集是后台有一个线程负责检查已经不再使用的对象，然后释放之。由于后台有一个线程一直运行，因此会严重影响性能，这也是Java和C#程序的运行速度无法超越C++的主要原因。GC技术不能应用于iOS开发，只能应用于Mac OS X开发。

从上面的介绍可知，iOS采用MRC和ARC这两种方式，ARC是苹果推荐的方式，MRC方式相对比较原始，对于程序员的能力要求很高，但是它很灵活、方便，很不容易驾驭好。Swift采用ARC管理内存，因此使用起来比较简单。

2.使用 Analyze 和 Instruments 工具解决内存泄漏问题

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

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

下面我们看看本节配套的Objective-C工程中ViewController的代码片段：

- (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，这是没有问题的，但遗憾的这是基于MRC的，都存在内存泄漏的可能性。从理论上讲，内存泄漏是由对象或变量没有释放引起的，但实践证明并非所有的未释放对象或变量都会导致内存泄漏，这与硬件环境和操作系统环境有关，因此我们需要检测工具帮助我们找到这些“泄漏点”。

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

图1 使用Analyze进行静态分析之后的代码界面

图2 Instruments分析工具

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

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

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

图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:didSelectRowAtIndexPath:方法疑似泄漏点2的展开结果

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

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

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

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

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

南昌网站制作小编提示：采用alloc、new、copy和mutableCopy所创建的对象，所有权属于调用者，它的生命周期由调用者管理，调用者负责通过release或autorelease方法释放对象。

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

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

图7 Instruments的Leaks模板

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

图8 Instruments检测到的内存泄漏

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

图9 查看泄漏的详细信息

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

图10 查看堆栈信息

图11 查看泄漏点

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

3.查找和解决僵尸对象

内存泄漏指一个对象或变量在使用完成后没有释放掉。如果我们走了另外一个极端情况，会是什么样呢?这就导致过度释放问题，从而使对象“僵尸化”，该对象则被称为僵尸对象。如果一个对象已经被释放过了，或者调用者没有这个对象的所有权而释放它，都会造成过度释放，产生僵尸对象。

对于很多人来说，僵尸对象或许听起来很恐怖、也很陌生，但是如果说起EXEC_BAD_ACCESS异常，可能大家并不陌生。如果应用的某个方法试图调用僵尸对象，则会崩溃(应用直接跳出)，并抛出EXEC_BAD_ACCESS异常。

下面我们看看本节配套Objective-C工程中ViewController的代码片段：

注意看上述代码中的粗体部分，你会发现什么问题吗?程序运行时，抛出EXEC_BAD_ACCESS异常。假设我们现在无法找到问题，可以使用Instruments工具的Zombies跟踪模板。按照图12所示选择Zombies模板，接着点击Profile按钮就可以进入了。

图12 Instruments的Zombies模板

这样在程序运行时，如果发现僵尸对象，就会弹出一个对话框，如图13所示，点击其中的 按钮，便会在屏幕下方显示僵尸对象的详细信息(如图14所示)。

图13 僵尸对象信息

图14 僵尸对象的详细信息

从图14可见，僵尸对象为UIAlertView类型，从上到下僵尸对象的引用计数变化是：1(创建)→ 0(释放)→ ?1(僵尸化)。点击View中的 按钮，打开堆栈跟踪信息视图，然后在右边的跟踪堆栈信息中点击 条目进入我们的程序代码并定位到僵尸对象，如图15所示。

图15 定位僵尸对象

在图15中，3条高亮显示的代码会影响对象的引用计数，从中我们不难发现问题。就本例而言，我们需要将本节开头第②行代码[alert show]放在[alert release]语句之前调用就可以了。

4.autorelease 的使用问题

在MRC中，释放对象通过release或autorelease消息实现，其中release消息会立刻使引用计数减一，autorelease消息会使对象放入内存释放池中延迟释放，对象的引用计数并不变化，而是向内存释放池中添加一条记录，直到池被销毁前通知池中的所有对象全部发送release消息才真正将引用计数减少。

由于使用autorelease消息会使对象延迟释放，所以除非必须，否则不要使用它释放对象。在iOS程序中，内存释放池的释放默认在程序结束。应用程序入口main.m文件的代码如下：

int main(int argc, char *argv[])

{

@autoreleasepool {

return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));

}

}

代码被包裹在@autoreleasepool {…}之间，这是池的作用范围，默认是整个应用。如果产生大量对象，采用autorelease释放也会导致内存泄漏。那么什么时候才必须使autorelease呢?我们看看下面的代码：

- (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] autorelease];

}

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;

}

在上述代码中，cell对象不能马上释放，我们需要使用它设置表视图界面。autorelease一般用在为其他调用者提供对象的方法中，对象在该方法中不能马上释放，而需要延迟释放。

此外，还有一种情况需要使用autorelease，就是使用静态工厂方法获得对象时，因为静态工厂方法内部使用了autorelease。使用静态工厂方法的代码如下：

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

该对象的所有权虽然不是当前调用者，但它是由iOS系统通过发送autorelease消息放入到池中的。当然，这一切对于开发者都是不可见的，我们也要注意减少使用这样的语句。

5.响应内存警告

好的应用应该在系统内存警告的情况下释放一些可以重新创建的资源。在iOS中，我们可以在应用程序委托对象、视图控制器以及其他类中获得系统内存警告消息。

(1) 应用程序委托对象

在应用程序委托对象中接收内存警告消息，需要写applicationDidReceiveMemoryWarning:方法，具体可参考本节实例代码中AppDelegate的代码片段：

- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application

{

NSLog(@'AppDelegate中调用applicationDidReceiveMemoryWarning:');

}

(1) 视图控制器

在视图控制器中接收内存警告消息，需要重写didReceiveMemoryWarning方法，具体可参考本节实例代码中

ViewController的代码片段：

- (void)didReceiveMemoryWarning

{

NSLog(@'ViewController中didReceiveMemoryWarning调用');

[super didReceiveMemoryWarning];

//释放成员变量

[_listTeams release];

}

注意，释放资源代码应该放在[super didReceiveMemoryWarning]语句后面。

(1) 其他类

在其他类中可以使用通知。在发生内存警告时，iOS系统会发出UIApplicationDidReceiveMemoryWarningNotification通知，凡是在通知中心注册了该通知的类都会接收到内存警告通知，具体可参考本节实例代码中ViewController的代码片段：

- (void)viewDidLoad

{

[super viewDidLoad];

NSBundle *bundle = [NSBundle mainBundle];

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

ofType:@'plist'];

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

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

self.listTeams = array;

[array release];

//接收内存警告通知，调用handleMemoryWarning方法处理

NSNotificationCenter *center = [NSNotificationCenter defaultCenter];

[center addObserver:self

selector:@selector(handleMemoryWarning)

name:UIApplicationDidReceiveMemoryWarningNotification

object:nil];

}

//处理内存警告

-(void) handleMemoryWarning

{

NSLog(@'ViewController中handleMemoryWarning调用');

}

在上述代码中，我们在viewDidLoad方法中注册UIApplicationDidReceiveMemoryWarningNotification消息，接收到报警信息后调用handleMemoryWarning方法。这些代码完全可以写在其他类中，直接在ViewController中重写didReceiveMemoryWarning方法就可以了。本例只是示意性地介绍一下UIApplicationDidReceiveMemoryWarningNotification报警消息。

内存警告在设备上并不经常出现，一般我们没有办法模拟，但模拟器上有一个功能可以模拟内存警告。启动模拟器，选择“硬件”→“模拟内存警告”模拟器菜单，这时我们会在输出窗口中看到内存警告发生了，具体如下所示：

2014-11-19 15:58:51.032 MemoryLeakSample[1396:41574] Received memory warning.

2014-11-19 15:58:51.033 MemoryLeakSample[1396:41574] AppDelegate中调用applicationDidReceiveMemoryWarning:

2014-11-19 15:58:51.034 MemoryLeakSample[1396:41574] ViewController中handleMemoryWarning调用

2014-11-19 15:58:51.034 MemoryLeakSample[1396:41574] ViewController中didReceiveMemoryWarning调用