一、內(nèi)存管理的基本規(guī)則

在Objective-C的內(nèi)存管理中，其實就是引用計數(shù)(reference count)的管理。內(nèi)存管理就是在程序需要時程序員分配一段內(nèi)存空間，而當(dāng)使用完之后將它釋放。如果程序員對內(nèi)存資源使用不當(dāng)，有時不僅會造成內(nèi)存資源浪費，甚至?xí)?dǎo)致程序crach。

image

二、 引用計數(shù)(Reference Count)

為了解釋引用計數(shù)，我們做一個類比：員工在辦公室使用燈的情景。

image

• 當(dāng)第一個人進入辦公室時，他需要使用燈，于是開燈，引用計數(shù)為1
• 當(dāng)另一個人進入辦公室時，他也需要燈，引用計數(shù)為2；每當(dāng)多一個人進入辦公室時，引用計數(shù)加1
• 當(dāng)有一個人離開辦公室時，引用計數(shù)減1，當(dāng)引用計數(shù)為0時，也就是最后一個人離開辦公室時，他不再需要使用燈，關(guān)燈離開辦公室。

從底層的實現(xiàn)來講就是一個class結(jié)構(gòu)體，結(jié)構(gòu)體內(nèi)部有個值(retain count)記錄了對象擁有者(ownship)的個數(shù)，當(dāng)計數(shù)值為0時，系統(tǒng)將自動釋放這個對象占用的內(nèi)存空間。

image

三、內(nèi)存管理基本規(guī)則

從上面燈的例子，我們對比一下燈的動作與Objective-C對象的動作有什么相似之處：

image

• 而Objective-C對象的動作對應(yīng)有哪些方法以及這些方法對引用計數(shù)有什么影響？

當(dāng)你alloc一個對象objc，此時RC=1；在某個地方你又retain這個對象objc，此時RC加1，也就是RC=2；由于調(diào)用alloc/retain一次，對應(yīng)需要調(diào)用release一次來釋放對象objc，所以你需要release對象objc兩次，此時RC=0；而當(dāng)RC=0時，系統(tǒng)會自動調(diào)用dealloc方法釋放對象。

除了alloc/new/copy/mutableCopy/retain這幾種方法可以獲取對象的所有權(quán)(ownship)外，當(dāng)對象被添加到集合對象(array, dictionary, set)中時，集合對象會獲取集合中所有對象的所有權(quán)(RC+1),當(dāng)集合對象釋放時，也會默認向集合中所有對象發(fā)送release消息(RC -1)，符合誰創(chuàng)建誰釋放的原則。

image

• 注意下以下情況是不會獲取對象的所有權(quán)：
  (1)不使用alloc/new/copy/mutableCopy方法引用的對象將不會獲取對象的擁有權(quán)

- (NSString *)fullName {
    NSString *string = [NSString stringWithFormat:@"%@ %@",
                                 self.firstName, self.lastName];
    return string;
}

這個函數(shù)調(diào)用的是NSString的 stringWithFormat并不不滿足內(nèi)存管理基本原則，不會擁有對象的所有權(quán)，所以可以放心的返回。而不用調(diào)用release方法或者autorelease方法。
(2)引用對象指針地址的方式(指針(*)、取地址(&))，不會獲取對象的擁有權(quán)。
這個比較好理解，比如我們常見的error。

    NSString *fileName = <#Get a file name#>;
    NSError *error;
    NSString *string = [[NSString alloc] initWithContentsOfFile:fileName
                                                       encoding:NSUTF8StringEncoding error:&error];
    if (string == nil) {
        // Deal with error...
    }
    // ...
    [string release];

四、 Autorelease Pool

在開發(fā)中，我們常常都會使用到局部變量，局部變量一個特點就是當(dāng)它超過作用域時，就會自動釋放。而autorelease pool跟局部變量類似，當(dāng)執(zhí)行代碼超過autorelease pool塊時，所有放在autorelease pool的對象都會自動調(diào)用release。它的工作原理如下：

• 創(chuàng)建一個NSAutoreleasePool對象
• 在autorelease pool塊的對象調(diào)用autorelease方法
• 釋放NSAutoreleasePool對象

image

iOS 5/OS X Lion前的(等下會介紹引入ARC的寫法)實例代碼如下：

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// put object into pool
id obj = [[NSObject alloc] init];
[obj autorelease];
[pool drain];
/* 超過autorelease pool作用域范圍時，obj會自動調(diào)用release方法 */

由于放在autorelease pool的對象并不會馬上釋放，如果有大量圖片數(shù)據(jù)放在這里的話，將會導(dǎo)致內(nèi)存不足。

for (int i = 0; i < numberOfImages; i++)
{
      /*   處理圖片，例如加載
       *   太多autoreleased objects存在
       *   由于NSAutoreleasePool對象沒有被釋放
       *   在某個時刻，會導(dǎo)致內(nèi)存不足 
       */
}

image

像上面這種情況你就可以這么寫：

for (int i = 0; i < numberOfImages; i++)
{
       @autoreleasepool {
      /*   
       *這樣臨時的autoreleased objects就會在autoreleasepool 結(jié)束時釋放達到最少的內(nèi)存占用。
       */
       }
}

五、ARC管理方法

iOS/OS X內(nèi)存管理方法有兩種：手動引用計數(shù)(Manual Reference Counting)和自動引用計數(shù)(Automatic Reference Counting)。從OS X Lion和iOS 5開始，不再需要程序員手動調(diào)用retain和release方法來管理Objective-C對象的內(nèi)存，而是引入一種新的內(nèi)存管理機制Automatic Reference Counting(ARC)，簡單來說，它讓編譯器來代替程序員來自動加入retain和release方法來持有和放棄對象的所有權(quán)。

image

在ARC內(nèi)存管理機制中，id和其他對象類型變量必須是以下四個ownership qualifiers其中一個來修飾：

• __strong(默認，如果不指定其他，編譯器就默認加入)
• __weak
• __unsafe_unretained
• __autoreleasing

image

比方說下面這段程序

NSError *error;
BOOL OK = [myObject performOperationWithError:&error];
if (!OK) {
    // Report the error.
    // ...

開啟ARC經(jīng)過編譯器處理后將會變成下面這樣：

NSError * __strong error;
NSError * __autoreleasing tmp = error;
BOOL OK = [myObject performOperationWithError:&tmp];
error = tmp;
if (!OK) {
    // Report the error.
    // ...

接下來看幾個例子：

• 5.1、__strong ownership qualifier
  如果變量var被__strong修飾，當(dāng)變量var指向某個對象objc，那么變量var持有某個對象objc的所有權(quán)

如果我想創(chuàng)建一個字符串，使用完之后將它釋放調(diào)用，使用MRC管理內(nèi)存的寫法應(yīng)該是這樣：

{
    NSString *text = [[NSString alloc] initWithFormat:@"Hello, world"];   //@"Hello, world"對象的RC=1
    NSLog(@"%@", text);
    [text release];                      //@"Hello, world"對象的RC=0
}

而如果是使用ARC方式的話，text對象無需調(diào)用release方法，而是當(dāng)text變量超過作用域時，編譯器來自動加入[text release]方法來釋放內(nèi)存

{
    NSString *text = [[NSString alloc] initWithFormat:@"Hello, world"];    //@"Hello, world"對象的RC=1
    NSLog(@"%@", text);
}
/*
 *  當(dāng)text超過作用域時，@"Hello, world"對象會自動釋放，RC=0
 */

而當(dāng)你將text賦值給其他變量anotherText時，MRC需要retain一下來持有所有權(quán)，當(dāng)text和anotherText使用完之后，各個調(diào)用release方法來釋放。

{
    NSString *text = [[NSString alloc] initWithFormat:@"Hello, world"];    //@"Hello, world"對象的RC=1
    NSLog(@"%@", text);

    NSString *anotherText = text;        //@"Hello, world"對象的RC=1
    [anotherText retain];                //@"Hello, world"對象的RC=2
    NSLog(@"%@", anotherText);

    [text release];                      //@"Hello, world"對象的RC=1
    [anotherText release];               //@"Hello, world"對象的RC=0
}

而使用ARC的話，則不需要調(diào)用retain和release方法來持有跟釋放對象。

{
    NSString *text = [[NSString alloc] initWithFormat:@"Hello, world"];   //@"Hello, world"對象的RC=1
    NSLog(@"%@", text);

    NSString *anotherText = text;        //@"Hello, world"對象的RC=2
    NSLog(@"%@", anotherText);
}
/*
 *  當(dāng)text和anotherText超過作用域時，會自動調(diào)用[text release]和[anotherText release]方法， @"Hello, world"對象的RC=0
 */

除了當(dāng)__strong變量超過作用域時，編譯器會自動加入release語句來釋放內(nèi)存，如果你將__strong變量重新賦給它其他值，那么編譯器也會自動加入release語句來釋放變量指向之前的對象。例如：

{
    NSString *text = [[NSString alloc] initWithFormat:@"Hello, world"];    //@"Hello, world"對象的RC=1
    NSString *anotherText = text;        //@"Hello, world"對象的RC=2
    NSString *anotherText = [[NSString alloc] initWithFormat:@"Sam Lau"];  // 由于anotherText對象引用另一個對象@"Sam Lau"，那么就會自動調(diào)用[anotherText release]方法，使得@"Hello, world"對象的RC=1, @"Sam Lau"對象的RC=1
}
/*
 *  當(dāng)text和anotherText超過作用域時，會自動調(diào)用[text release]和[anotherText release]方法，
 *  @"Hello, world"對象的RC=0和@"Sam Lau"對象的RC=0
 */

前面已經(jīng)提過內(nèi)存管理的四條規(guī)則：

我們總結(jié)一下編譯器是按以下方法來實現(xiàn)的：

• 對于規(guī)則1和規(guī)則2，是通過__strong變量來實現(xiàn)，
• 對于規(guī)則3來說，當(dāng)變量超過它的作用域或被賦值或成員變量被丟棄時就能實現(xiàn)
• 對于規(guī)則4，當(dāng)RC=0時，系統(tǒng)就會自動調(diào)用

• 5.2、__weak ownership qualifier

__strong不能解決引用循環(huán)(Reference Cycle)問題：對象A持有對象B，反過來，對象B持有對象A；這樣會導(dǎo)致不能釋放內(nèi)存造成內(nèi)存泄露問題。

image

舉一個簡單的例子，有一個類Test有個屬性objc，有兩個對象test1和test2的屬性objc互相引用test1和test2：

@interface Test : NSObject
@property (strong, nonatomic) id objc;
@end

{
    Test *test1 = [Test new];        /* 對象a */
    /* test1有一個強引用到對象a */

    Test *test2 = [Test new];        /* 對象b */
    /* test2有一個強引用到對象b */

    test1.objc = test2;              /* 對象a的成員變量objc有一個強引用到對象b */
    test2.objc = test1;              /* 對象b的成員變量objc有一個強引用到對象a */
}
/*   當(dāng)變量test1超過它作用域時，它指向a對象會自動release
 *   當(dāng)變量test2超過它作用域時，它指向b對象會自動release
 *   
 *   此時，b對象的objc成員變量仍持有一個強引用到對象a
 *   此時，a對象的objc成員變量仍持有一個強引用到對象b
 *   于是發(fā)生內(nèi)存泄露
 */

如何解決？于是我們引用一個__weak ownership qualifier，被它修飾的變量都不持有對象的所有權(quán)，而且當(dāng)變量指向的對象的RC為0時，變量設(shè)置為nil。例如：

__weak NSString *text = [[NSString alloc] initWithFormat:@"Sam Lau"];
NSLog(@"%@", text);

由于text變量被__weak修飾，text并不持有@"Sam Lau"對象的所有權(quán)，@"Sam Lau"對象一創(chuàng)建就馬上被釋放，并且編譯器給出警告??，所以打印結(jié)果為(null)。
所以，針對剛才的引用循環(huán)問題，只需要將Test類的屬性objc設(shè)置weak修飾符，那么就能解決。

@interface Test : NSObject
@property (weak, nonatomic) id objc;//修改成weak修飾符
@end

以及我們常用的block防止內(nèi)存泄漏也可以使用__weak 修飾符，引用官方給的例子如下：

MyViewController *myController = [[MyViewController alloc] init…];
// ...
MyViewController * __weak weakMyController = myController;
myController.completionHandler =  ^(NSInteger result) {
    MyViewController *strongMyController = weakMyController;
    if (strongMyController) {
        // ...
        [strongMyController dismissViewControllerAnimated:YES completion:nil];
        // ...
    }
    else {
        // Probably nothing...
    }
};

• 5.3、__unsafe_unretained ownership qualifier
  __unsafe_unretained ownership qualifier，正如名字所示，它是不安全的。它跟__weak相似，被它修飾的變量都不持有對象的所有權(quán)，但當(dāng)變量指向的對象的RC為0時，變量并不設(shè)置為nil，而是繼續(xù)保存對象的地址；這樣的話，對象有可能已經(jīng)釋放，但繼續(xù)訪問，就會造成非法訪問(Invalid Access)。例子如下：

__unsafe_unretained id obj0 = nil;
{
    id obj1 = [[NSObject alloc] init];     // 對象A
    /* 由于obj1是強引用，所以obj1持有對象A的所有權(quán)，對象A的RC=1 */

    obj0 = obj1;
    /* 由于obj0是__unsafe_unretained，它不持有對象A的所有權(quán)，但能夠引用它，對象A的RC=1 */
    NSLog(@"A: %@", obj0);
}
/* 當(dāng)obj1超過它的作用域時，它指向的對象A將會自動釋放 */

NSLog(@"B: %@", obj0);
/* 由于obj0是__unsafe_unretained，當(dāng)它指向的對象RC=0時，它會繼續(xù)保存對象的地址，所以兩個地址相同 */

打印結(jié)果是內(nèi)存地址相同：

image

如果將__unsafe_unretained改為weak的話，兩個打印結(jié)果將不同

__weak id obj0 = nil;
{
    id obj1 = [[NSObject alloc] init];     // 對象A
    /* 由于obj1是強引用，所以obj1持有對象A的所有權(quán)，對象A的RC=1 */

    obj0 = obj1;
    /* 由于obj0是__unsafe_unretained，它不持有對象A的所有權(quán)，但能夠引用它，對象A的RC=1 */

    NSLog(@"A: %@", obj0);
}
/* 當(dāng)obj1超過它的作用域時，它指向的對象A將會自動釋放 */

NSLog(@"B: %@", obj0);
/* 由于obj0是__weak， 當(dāng)它指向的對象RC=0時，它會自動設(shè)置為nil，所以兩個打印結(jié)果將不同*/

image

• 5.4、 __autoreleasing ownership qualifier

MRC下autorelease pool寫法如下：

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// put object into pool
id obj = [[NSObject alloc] init];
[obj autorelease];

[pool drain];
/* 超過autorelease pool作用域范圍時，obj會自動調(diào)用release方法 */

引入ARC之后，寫法更加簡潔：

@autoreleasepool {
    id __autoreleasing obj = [[NSObject alloc] init];
}

相比之前的創(chuàng)建、使用和釋放NSAutoreleasePool對象，現(xiàn)在你只需要將代碼放在@autoreleasepool塊即可。你也不需要調(diào)用autorelease方法了，只需要用__autoreleasing修飾變量即可。

image

但是我們很少或基本上不使用autorelease pool。當(dāng)我們使用XCode創(chuàng)建工程后，有一個app的入口文件main.m使用了它：

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

六、 Property(屬性)與ownership qualifier

有了ARC之后，新的property modifier也被引入到Objective-C類的property，例如：

@property (strong, nonatomic) NSString *text;

下面有張表來展示property modifier與ownership qualifier的對應(yīng)關(guān)系

• 先看下命名一個屬性為retain時,然后調(diào)用@synthesize時編譯器將會做什么
  setter方法：

 - (void)setCount:(NSNumber *)newCount {
        [newCount retain];
        [_count release];
        // Make the new assignment.
        _count = newCount;
    }

也就是這里會首先retain新值，然后釋放舊值(舊值RC -1)，然后再賦值新值。

• 相同的當(dāng)命名一個屬性為copy類型時
  setter方法：

 - (void)setCount:(NSNumber *)newCount {
        [_count release];
        // Make the new assignment.
        _count = [newCount copy];
    }

retain與copy的區(qū)別在于，一個不產(chǎn)生新的對象只是對對象的RC + 1,另一個產(chǎn)生新的對象。

• 除了上面屬性修飾符外還有atomic (default)、nonatomic、readonly、readwrite。

image

只能一個線程訪問，線程安全的(相當(dāng)于線程鎖的概念，一個時間段只有一個線程訪問不容易出錯，所以線程安全),低性能

image

七、內(nèi)存管理問題解決辦法

image

在往下看之前請下載實例MemoryProblems，我們將以這個工程展開如何檢查和解決內(nèi)存問題。

• 懸掛指針問題

懸掛指針(Dangling Pointer)就是當(dāng)指針指向的對象已經(jīng)釋放或回收后，但沒有對指針做任何修改(一般來說，將它指向空指針)，而是仍然指向原來已經(jīng)回收的地址。如果指針指向的對象已經(jīng)釋放，但仍然使用，那么就會導(dǎo)致程序crash。

當(dāng)你運行MemoryProblems后，點擊懸掛指針那個選項，就會出現(xiàn)EXC_BAD_ACCESS崩潰信息

image

我們看看這個NameListViewController是做什么的？它繼承UITableViewController，主要顯示多個名字的信息。它的實現(xiàn)文件如下：

static NSString *const kNameCellIdentifier = @"NameCell";
@interface NameListViewController ()
#pragma mark - Model
@property (strong, nonatomic) NSArray *nameList;
#pragma mark - Data source
@property (assign, nonatomic) ArrayDataSource *dataSource;
@end

@implementation NameListViewController

- (void)viewDidLoad {
    [super viewDidLoad];

    self.tableView.dataSource = self.dataSource;
}

#pragma mark - Lazy initialization
- (NSArray *)nameList
{
    if (!_nameList) {
        _nameList = @[@"Sam", @"Mike", @"John", @"Paul", @"Jason"];
    }
    return _nameList;
}

- (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;
        }];
    }
    return _dataSource;
}
@end

要想通過tableView顯示數(shù)據(jù)，首先要實現(xiàn)UITableViewDataSource這個協(xié)議，為了瘦身controller和復(fù)用data source，我將它分離到一個類ArrayDataSource來實現(xiàn)UITableViewDataSource這個協(xié)議。然后在viewDidLoad方法里面將dataSource賦值給tableView.dataSource。

解釋完NameListViewController的職責(zé)后，接下來我們需要思考出現(xiàn)EXC_BAD_ACCESS錯誤的原因和位置信息。

一般來說，出現(xiàn)EXC_BAD_ACCESS錯誤的原因都是懸掛指針導(dǎo)致的，但具體是哪個指針是懸掛指針還不確定，因為控制臺并沒有給出具體crash信息。

• 啟用NSZombieEnabled

要想得到更多的crash信息，你需要啟動NSZombieEnabled。具體步驟如下：
1、選中Edit Scheme，并點擊

image

2、Run -> Diagnostics -> Enable Zombie Objects

image

設(shè)置完之后，再次運行和點擊懸掛指針，雖然會再次crash，但這次控制臺打印了以下有用信息：

image

信息message sent to deallocated instance 0x7fe19b081760大意是向一個已釋放對象發(fā)送信息，也就是已釋放對象還調(diào)用某個方法。現(xiàn)在我們大概知道什么原因?qū)е鲁绦驎?code>crash，但是具體哪個對象被釋放還仍然使用呢？

點擊上面紅色框的Continue program execution按鈕繼續(xù)運行，截圖如下：

image

留意上面的兩個紅色框，它們兩個地址是一樣，而且ArrayDataSource前面有個_NSZombie_修飾符，說明dataSource對象被釋放還仍然使用。

再進一步看dataSource聲明屬性的修飾符是assign

#pragma mark - Data source
@property (assign, nonatomic) ArrayDataSource *dataSource;

而assign對應(yīng)就是__unsafe_unretained，它跟__weak相似，被它修飾的變量都不持有對象的所有權(quán)，但當(dāng)變量指向的對象的RC為0時，變量并不設(shè)置為nil，而是繼續(xù)保存對象的地址。

因此，在viewDidLoad方法中

- (void)viewDidLoad {
    [super viewDidLoad];

    self.tableView.dataSource = self.dataSource;    
    /*  由于dataSource是被assign修飾，self.dataSource賦值后，它對象的對象就馬上釋放，
     *  而self.tableView.dataSource也不是strong，而是weak，此時仍然使用，所有會導(dǎo)致程序crash
     */
}

解決：

@property (strong, nonatomic) ArrayDataSource *dataSource;  //strong代替assign

八、內(nèi)存泄露問題
使用Instruments里面的子工具Leaks來檢查內(nèi)存泄露。

• 靜態(tài)分析

一般來說，在程序未運行之前我們可以先通過Clang Static Analyzer(靜態(tài)分析)來檢查代碼是否存在bug。比如，內(nèi)存泄露、文件資源泄露或訪問空指針的數(shù)據(jù)等。下面有個靜態(tài)分析的例子來講述如何啟用靜態(tài)分析以及靜態(tài)分析能夠查找哪些bugs。

啟動程序后，點擊靜態(tài)分析，馬上就出現(xiàn)crash

image

此時，即使啟用NSZombieEnabled，控制臺也不能打印出更多有關(guān)bug的信息，具體原因是什么，等下會解釋。

打開StaticAnalysisViewController，里面引用Facebook Infer工具的代碼例子，包含個人日常開發(fā)中會出現(xiàn)的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

下面我們通過靜態(tài)分析來檢查代碼是否存在bugs。有兩個方式：

• 手動靜態(tài)分析：每次都是通過點擊菜單欄的Product -> Analyze或快捷鍵shift + command + b

• image

• 自動靜態(tài)分析：在Build Settings啟用Analyze During 'Build'，每次編譯時都會自動靜態(tài)分析

image

靜態(tài)分析結(jié)果如下：

image

通過靜態(tài)分析結(jié)果，我們來分析一下為什么NSZombieEnabled不能定位EXC_BAD_ACCESS的錯誤代碼位置。由于callback傳入進來的是null指針，而NSZombieEnabled只能針對某個已經(jīng)釋放對象的地址，所以啟動NSZombieEnabled是不能定位的，不過可以通過靜態(tài)分析可得知。

• 啟動Instruments

有時使用靜態(tài)分析能夠檢查出一些內(nèi)存泄露問題，但是有時只有運行時使用Instruments才能檢查到，啟動Instruments步驟如下：

1. 點擊Xcode的菜單欄的 Product -> Profile 啟動Instruments

   image

2. 此時，出現(xiàn)Instruments的工具集，選中Leaks子工具點擊

   image

3. 打開Leaks工具之后，點擊紅色圓點按鈕啟動Leaks工具，在Leaks工具啟動同時，模擬器或真機也跟著啟動

image

4. 啟動Leaks工具后，它會在程序運行時記錄內(nèi)存分配信息和檢查是否發(fā)生內(nèi)存泄露。當(dāng)你點擊引用循環(huán)進去那個頁面后，再返回到主頁，就會發(fā)生內(nèi)存泄露

   image
   image

如果發(fā)生內(nèi)存泄露，我們怎么定位哪里發(fā)生和為什么會發(fā)生內(nèi)存泄露？

九、定位內(nèi)存泄露
借助Leaks能很快定位內(nèi)存泄露問題，在這個例子中，步驟如下：

• 首先點擊Leak Checks時間條那個紅色叉

  image

• 然后雙擊某行內(nèi)存泄露調(diào)用棧，會直接跳到內(nèi)存泄露代碼位置

  image

十、難以檢測Block引用循環(huán)
大多數(shù)的內(nèi)存問題都可以通過靜態(tài)分析和Instrument Leak工具檢測出來，但是有種block引用循環(huán)是難以檢測的，看我們這個Block內(nèi)存泄露例子，跟上面的懸掛指針例子差不多，只是在configureCellBlock里面調(diào)用一個方法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");
}

• 我們首先用靜態(tài)分析來看看能不能檢查出內(nèi)存泄露：

image

• 結(jié)果是沒有任何內(nèi)存泄露的提示，我們再用Instrument Leak工具在運行時看看能不能檢查出：

image

結(jié)果跟使用靜態(tài)分析一樣，還是沒有任何內(nèi)存泄露信息的提示。

那么我們怎么知道這個 BlockLeakViewController發(fā)生了內(nèi)存泄露呢？還是根據(jù)iOS/OS X內(nèi)存管理機制的一個基本原理：當(dāng)某個對象的引用計數(shù)為0時，它就會自動調(diào)用- (void)dealloc方法。

在這個例子中，如果BlockLeakViewController被navigationController pop出去后，沒有調(diào)用dealloc方法，因為BlockLeakViewController 強引用了dataSource，而dataSource的configureCellBlock屬性又強引用了BlockLeakViewController的實例方法，導(dǎo)致循環(huán)引用，BlockLeakViewController不能被釋放。
我們在dealloc方法打印release BlockLeakViewController信息：

- (void)dealloc
{
    NSLog(@"release BlockLeakViewController");
}

在點擊返回按鈕后，其并沒有打印出來，因此這個BlockLeakViewController存在內(nèi)存泄露問題的。解決：

BlockLeakViewController *__weak controller = self;
[controller configureCell];   //代替[self configureCell];

總結(jié)

在創(chuàng)建工程的時候，在Build Settings啟用Analyze During Build，每次編譯時都會自動靜態(tài)分析。編碼時及時知道是否存在內(nèi)存泄露或其他bug問題，并且進行修改。而在運行過程中，如果出現(xiàn)EXC_BAD_ACCESS，則啟用NSZombieEnabled，看出現(xiàn)異常后，在控制臺是否能打印出更多的提示信息。如果想在運行時查看是否存在內(nèi)存泄露，使用Instrument Leak工具。但是有些內(nèi)存泄露是很難檢查出來，只有通過手動覆蓋dealloc方法，看它最終有沒有調(diào)用來判斷是否存在內(nèi)存泄漏。

參考借鑒文獻：
IOS內(nèi)存管理(一)基本概念與原理
IOS內(nèi)存管理(二)借助工具解決內(nèi)存問題