iOS 内存泄漏 iphone内存损坏

参考文章：http://www.cocoachina.com/ios/20160226/15324.html

                  http://www.cocoachina.com/ios/20160222/15333.html

有时候，你会遇到由EXC_BAD_ACCESS造成的崩溃。 这篇文章会告诉你什么是EXC_BAD_ACCESS，以及它产生的原因。我还会提供一些EXC_BAD_ACCESS错误的解决方案。另外，我还会对内存泄露的解决方法进行介绍，针对一些专业名词进行相应的解释。

一. EXC_BAD_ACCESS问题

1. 什么是 EXC_BAD_ACCESS?

一旦你理解EXC_BAD_ACCESS的本质，你就会更好地理解这个模糊的名词。这里有一个极为简单的解释，也有一个技术层面的解释。我们首先从简单的解释开始说起。

2. 简单的解释

不管什么时候当你遇到EXC_BAD_ACCESS这个错误，那就意味着你向一个已经释放的对象发送消息。这是最常见的情况，但也有例外，我们将在稍后讨论。

3. EXC_BAD_ACCESS的本质

技术层面的解释有些复杂。在C和Objective-C中，你一直在处理指针。指针无非是存储另一个变量的内存地址的变量。当您向一个对象发送消息时，指向该对象的指针将会被引用。这意味着，你获取了指针所指的内存地址，并访问该存储区域的值。

当该存储器区域不再映射到您的应用时，或者换句话说，该内存区域在你认为使用的时候却没有使用，该内存区域是无法访问的。 这时内核会抛出一个异常（ EXC ），表明你的应用程序不能访问该存储器区域（BAD ACCESS） 。

总之，当你碰到EXC_BAD_ACCESS ，这意味着你试图发送消息到的内存块，但内存块无法执行该消息。但是，在某些情况下， EXC_BAD_ACCESS是由被损坏的指针引起的。每当你的应用程序尝试引用损坏的指针，一个异常就会被内核抛出。

4.调试EXC_BAD_ACCESS

调试EXC_BAD_ACCESS可能会非常棘手和令人沮丧。然而，现在EXC_BAD_ACCESS不再是一个谜，它没有想象中的那么可怕。

你需要知道的第一件事是您的应用程序并不一定是在崩溃的那一刻，无法访问内存区域。这就是常使调试EXC_BAD_ACCESS变得困难的原因。

同样受损指针也是如此。当你的指针被损坏时，您的应用程序不会崩溃。同时，如果您在应用程序中来回传递一个受损的指针也不会崩溃。当应用程序试图引用受损指针的时候，就会发生奔溃。

5.僵尸调试模式

僵尸调试模式在过去几年中得到了普及，事实上它们已经出现在Xcode上超过十年。僵尸听起来有点戏剧性，但它实际上是为帮助我们调试EXC_BAD_ACCESS功能而取得一个伟大的名字。让我来解释它是如何工作的。

在Xcode中，您可以启用僵尸对象，这意味着被释放的对象将会以僵尸的形式被保留。换言之，保留释放的对象就是为了调试。这里没有涉及任何魔法。如果您向僵尸对象发送消息，你的应用程序将会由于EXC_BAD_ACCESS而崩溃。

这有什么好处吗？让EXC_BAD_ACCESS难以调试的原因是，你不知道你的应用程序试图访问哪个对象。僵尸对象在许多情况下解决这个问题。通过保留已释放的对象，Xcode可以告诉你你试图访问哪个对象，这使的查找问题原因容易得多。

在Xcode中启用僵尸对象是很容易的。注意，这可能会因的Xcode的版本而不同的。以下方法适用于Xcode的6和7，单击左上角的Edit Scheme，并选中Edit Scheme。

在左侧选中Run ，在上方打开 Diagnostics选项。要启用僵尸对象，勾选 Enable Zombie Objects选框。

如果你现在遇到EXC_BAD_ACCESS ，在Xcode的控制台输出，告诉你该从哪里查找问题。看看下面的例子输出。 

2015-08-12 06:31:55.501 Debug[2371:1379247] -[ChildViewController respondsToSelector:] message sent to deallocated instance 0x17579780

在上面的例子中， Xcode告诉我们， respondsToSelector的消息：被发送到一个僵尸对象。然而，僵尸对象不再是ChildViewController类的一个实例。以前分配给ChildViewController实例的内存区域不再映射到您的应用程序。这为你了解问题产生的根本原因提供一个不错的建议。

不幸的是，僵尸对象将无法保存您的一天每次崩溃的EXC_BAD_ACCESS的记录。既然僵尸对象没有这些方法，那么你可以采取其他的方法进行一些适当的分析。

6.分析

如果僵尸对象不能解决你的问题，那么问题的根源可能就不那么简单了。在这种情况下，您需要仔细看看在应用程序崩溃时执行的代码。这可能是繁琐和耗时的。

为了帮助你发现你的代码的问题，你可以使用Xcode来分析你的代码，帮助你找到出现问题的地方。注意，Xcode分析项目，它会指出每一个潜在的可能出现的问题的地方。

使用Xcode来分析你的项目，从Xcode的 Product菜单选择 Analyze或按 Shift-Command-B.Xcode的将需要片刻的时间，但是当它完成的时候你会在左边的 Issue Navigator看到问题列表。由Analyze发现的问题用蓝色高亮显示。

当你点击一个问题，Xcode的会指向问题代码块，这些正是你要的注意的地方。注意，Xcode仅仅是建议。在某些情况下，这是可能的，问题是不相关的，不固定。

如果你找不到造成EXC_BAD_ACCESS的错误，那就需要你仔细审视Xcode项目，分析其中发现的每一个问题。

7.结论

EXC_BAD_ACCESS是开发者面临的一个共同的问题，它是手动内存管理固有的问题。虽然推行ARC内存管理方式 （自动引用计数）使得EXC_BAD_ACCESS没那么频繁，但他们并没有真正的消失

二.内存泄露问题

1.静态分析

一般来说，在程序未运行之前我们可以先通过Clang Static Analyzer(静态分析)来检查代码是否存在bug。比如，内存泄露、文件资源泄露或访问空指针的数据等。下面有个静态分析的例子来讲述如何启用静态分析以及静态分析能够查找哪些bugs。

启动程序后，点击静态分析，马上就出现crash

此时，即使启用NSZombieEnabled，控制台也不能打印出更多有关bug的信息，具体原因是什么，等下会解释。

打开StaticAnalysisViewController，里面引用Facebook Infer工具的代码例子，包含个人日常开发中会出现的bugs：

@implementation StaticAnalysisViewController        


                  


         #pragma mark - Lifecycle        


         - (void)viewDidLoad        


         {        


                  [         super          viewDidLoad];        


                  


                  [self memoryLeakBug];        


                  [self resoureLeakBug];        


                  [self parameterNotNullCheckedBlockBug:nil];        


                  [self npeInArrayLiteralBug];        


                  [self prematureNilTerminationArgumentBug];        


         }        


                  


         #pragma mark - Test methods from facebook infer iOS Hello examples        


         - (void)memoryLeakBug        


         {        


                  CGPathRef shadowPath = CGPathCreateWithRect(self.inputView.bounds, NULL);        


         }        


                  


         - (void)resoureLeakBug        


         {        


                  FILE *fp;        


                  fp=fopen(         "info.plist"         ,          "r"         );        


         }        


                  


         -(void) parameterNotNullCheckedBlockBug:(void (^)())callback {        


                  callback();        


         }        


                  


         -(NSArray*) npeInArrayLiteralBug {        


                  NSString *str = nil;        


                  return          @[@         "horse"         , str, @         "dolphin"         ];        


         }        


                  


         -(NSArray*) prematureNilTerminationArgumentBug {        


                  NSString *str = nil;        


                  return          [NSArray arrayWithObjects: @         "horse"         , str, @         "dolphin"         , nil];        


         }        


                  


         @end

下面我们通过静态分析来检查代码是否存在bugs。有两个方式：

2.手动静态分析：每次都是通过点击菜单栏的Product -> Analyze或快捷键shift + command + b

3.自动静态分析：在Build Settings启用Analyze During 'Build'，每次编译时都会自动静态分析

静态分析结果如下：

通过静态分析结果，我们来分析一下为什么NSZombieEnabled不能定位EXC_BAD_ACCESS的错误代码位置。由于callback传入进来的是null指针，而NSZombieEnabled只能针对某个已经释放对象的地址，所以启动NSZombieEnabled是不能定位的，不过可以通过静态分析可得知。

4.启动Instruments

有时使用静态分析能够检查出一些内存泄露问题，但是有时只有运行时使用Instruments才能检查到，启动Instruments步骤如下：

1.点击Xcode的菜单栏的 Product -> Profile 启动Instruments

2.此时，出现Instruments的工具集，选中Leaks子工具点击

3.打开Leaks工具之后，点击红色圆点按钮启动Leaks工具，在Leaks工具启动同时，模拟器或真机也跟着启动

4.启动Leaks工具后，它会在程序运行时记录内存分配信息和检查是否发生内存泄露。当你点击引用循环进去那个页面后，再返回到主页，就会发生内存泄露

内存泄露.gif

如果发生内存泄露，我们怎么定位哪里发生和为什么会发生内存泄露？

5.定位内存泄露

借助Leaks能很快定位内存泄露问题，在这个例子中，步骤如下：

• 首先点击Leak Checks时间条那个红色叉

• 然后双击某行内存泄露调用栈，会直接跳到内存泄露代码位置

6.分析内存泄露原因

上面已经定位好内存泄露代码的位置，至于原因是什么？可以查看上一篇的iOS/OS X内存管理(一)：基本概念与原理的循环引用例子，那里已经有详细的解释。

难以检测Block引用循环

大多数的内存问题都可以通过静态分析和Instrument Leak工具检测出来，但是有种block引用循环是难以检测的，看我们这个Block内存泄露例子，跟上面的悬挂指针例子差不多，只是在configureCellBlock里面调用一个方法configureCell。

- (ArrayDataSource *)dataSource        


         {        


                  if          (!_dataSource) {        


                  _dataSource = [[ArrayDataSource alloc] initWithItems:self.nameList        


                  cellIdentifier:kNameCellIdentifier        


                  tableViewStyle:UITableViewCellStyleDefault        


                  configureCellBlock:^(UITableViewCell *cell, NSString *item, NSIndexPath *indexPath) {        


                  cell.textLabel.text = item;        


                  


                  [self configureCell];        


                  }];        


                  }        


                  return          _dataSource;        


         }        


                  


         - (void)configureCell        


         {        


                  NSLog(@         "Just for test"         );        


         }        


                  


         - (void)dealloc        


         {        


                  NSLog(@         "release BlockLeakViewController"         );        


         }

我们首先用静态分析来看看能不能检查出内存泄露：

结果是没有任何内存泄露的提示，我们再用Instrument Leak工具在运行时看看能不能检查出：

结果跟使用静态分析一样，还是没有任何内存泄露信息的提示。

那么我们怎么知道这个BlockLeakViewController发生了内存泄露呢？还是根据iOS/OS X内存管理机制的一个基本原理：当某个对象的引用计数为0时，它就会自动调用- (void)dealloc方法。

在这个例子中，如果BlockLeakViewController被navigationController pop出去后，没有调用dealloc方法，说明它的某个属性对象仍然被持有，未被释放。而我在dealloc方法打印release BlockLeakViewController信息：

- (void)dealloc        


         {        


                  NSLog(@         "release BlockLeakViewController"         );        


         }

在我点击返回按钮后，其并没有打印出来，因此这个BlockLeakViewController存在内存泄露问题的。至于如何解决block内存泄露这个问题，很多基本功扎实的同学都知道如何解决，不懂的话，自己查资料解决吧！