MRC转ARC

阅读《iOS 5 By Tutorials》的笔记。

ARC-Automatic Reference Counting(自动引用计数) 是iOS5开始增加的。

ARC是编译器特性，而不是iOS运行时特性。

项目中MRC转到ARC 是非常简单的，所有的编程和以前一样，除了不再调用 retain, release, autorelease。 由编译器自动插入适当的地方。

ARC的规则:

只要还有一个变量指向对象，对象就会保持在内存中。当指针指向新值，或者指针不再存在时，相关联的对象就会 自动释放。
这条规则对于实例变量、synthesize 属性、本地变量都是适用的。

我们默认所有实例变量和本地变量都是 strong 类型的指针。

我们可以按“所有权”(ownership)来考虑 ARC 对象:
NSString *firstName = self.textField.text;
firstName 变量成为 NSString 对象的指针，也就是拥有者，该对象保存了文本输入框的内容。 用户改变了输入框的文本，此时 text 属性就指向了新的 String 对象。但原来的 String 对象仍然还有一个所有者(firstName 变量)， 因此会继续保留在内存中。 只有当 firstName 获得新值，或者超出作用域(本地变量方法返回 时、实例变量对象释放时)，String 对象不再拥有任何所有者，retain 计数降为 0，这时对象会被释放。

__weak NSString *weakName = self.textField.text;

weakName 变量和 textField.text 属性都指向一个 String 对象，但 weakName 不是拥有者。如果文本框的内容发生变化，则原先的 String 对象就没有拥有者，会被释放，此时 weakName 会自动变成 nil，称为 “zeroing” weak pointer: weak 变量自动变为 nil 是非常方便的，这样阻止了 weak 指针继续 指向已释放对象。“摇摆指针”和“zombies”会导致非常难于寻找的 Bug。 zeroing weak pointer 消除了类似的问题。

典型例子是 delegate 模式，View Controller 通过 strong 指针拥有一个 UITableView，Table view 的 data source 和 delegate 都是 weak 指针，指向View Controller。

在手动内存管理中，从 Array 中 移除一个对象会使对象不可用，对象不属于 Array 时会立即被释放。随后 NSLog()打印该对象就会导致应用崩溃。
在 ARC 中这段代码是完全合法的，因为 obj 变量是一个 strong 指针， 它成为了对象的拥有者，从 Array 中移除该对象也不会导致对象被释放。

ARC 的限制：

首先 ARC 只能工作于 Objective-C 对象，如果 应用使用了 Core Foundation 或 malloc()/free()，此时需要你来管理内存。此外 ARC 还有其它一些更为严格的语言规则，以确保 ARC 能够正常地工作。

虽然 ARC 管理了 retain 和 release，但并不表示你完全不需要处理 内存管理的问题。因为 strong 指针会保持对象的生命，某些情况下你仍然需要手动设置这些指针为 nil，否则可能导致应用内存不足。

属性 property
@property (retain, nonatomic)
变为
@property (strong, nonatomic)

在 ARC 之前，开发者经常会在.m 实现文件中使用 class extension 来定义 private property，如下:

@interface MainViewController () 
@property (nonatomic, retain) NSMutableArray *searchResults; 
@property (nonatomic, retain) SoundEffect *soundEffect; 
@end

这样做主要是简化实例对象的手动内存管理，让 property 的 setter 方法自 动管理原来对象的释放，以及新对象的 retain。但是有了 ARC，这样的代码就不再需要了。一般来说，仅仅为了简化内存管理，是不再需要使用 property 的， 虽然你仍然可以这样做，但直接使用实例变量是更好的选择。只有那些属于 public 接口的实例变量，才应该定义为 property。
我们可以直接在.m 类实现中定义 private 实例变量:

@implementation MainViewController 
{ 
    NSOperationQueue *queue; 
    NSMutableString *currentStringValue; 
    NSMutableArray *searchResults; 
    SoundEffect *soundEffect; 
}

我们在使用时，虽然没有定义 property，也可以直接
[self.soundEffect play];
如果你觉得这很别扭，也可以使用
[[self soundEffect] play];
如果你还是觉得应该定义 property，那就定义一个吧，反正也没什么害处。

很多时候我们会这样写 synthesize 语句:

@synthesize propertyName = _propertyName;

实际上propertyName 实例变量甚至可以不定义，编译器会自动为 property 定义 "*" 的实例变量

IBOutlet

在 ARC 中，所有outlet属性都推荐使用 weak，这些 view 对象已经属于 View Controller 的 view hierarchy，不需要再次定义为 strong(ARC 中效果等同于 retain)。唯一应该使用 strong 的 outlet 是 File's Owner，连接到 nib 的顶 层对象。
将 outlet 定义为 weak 的优点是简化了 viewDidUnload 方法的实现:

- (void)viewDidUnload 
{ 
    [super viewDidUnload]; 
    self.tableView = nil; 
    self.searchBar = nil; 
    soundEffect = nil; 
}

现在可以简化为:

- (void)viewDidUnload 
{
    [super viewDIdUnload];
    soundEffect = nil; 
}

因为 tableView 和 searchBar 这两个 property 定义为 weak，当它们指向的 对象被释放时，这两个变量会自动设置为 nil。
当 iOS App 接收到低内存警告时，View Controller 的 main view 会被 unload， 同时会释放所有 subview。这时 UITableView 和 UISearchBar 对象会自动释放， zeroing weak pointer system 就会自动设置 self.tableView 和 self.searchBar 为 nil。因此不需要在 viewDidUnload 中再次设置为 nil，实 际上当 viewDidUnload 被调用时，这两个属性已经是 nil 了。
这并不意味着你可以不需要 viewDidUnload，只要你保持一个对象的指针， 对象就会存活。当你不需要某个对象时，可以手动设置指针为 nil。如上面示例 代码中的 soundEffect = nil; viewDidUnload()方法里面需要设置所有非 outlet 变量为 nil，同样还有 didReceiveMemoryWarning()方法。

property

修饰符总结如下:

• strong:等同于"retain"，属性成为对象的拥有者

• weak:属性是 weak pointer，当对象释放时会自动设置为 nil，记住 Outlet 应该使用 Weak

• unsafe_unretained:等同于之前的"assign"，只有 iOS 4 才应该使用

• copy:和之前的 copy 一样，复制一个对象并创建 strong 关联

• assign:对象不能使用 assign，但原始类型(BOOL、int、float)仍然可以使用

readonly property

在 ARC 之前，我们可以如下定义一个 readonly property:

@property (nonatomic, readonly) NSString *result;

这会隐式地创建一个 assign property，这种用法对于 readonly 值来说是适当的。毕竟你何必对只读数据进行 retain 呢?但上面在 ARC 中会报错:
你必须显式地使用 strong, weak 或 unsafe_unretained，多数情况下使用 strong 是正确的选择:

@property (nonatomic, strong, readonly) NSString *result;

对于 readonly property，我们应该总是使用 self.propertyName 来访问实 例变量(除了 init 和自定义的 getter 和 setter 方法)。否则直接修改实例变 量会混淆 ARC 并导致奇怪的 Bug。正确的方法是使用 class extension 重新定义 property 为 readwrite:

.h 文件:

@property (nonatomic, strong, readonly) NSNumber *temperature;

.m 文件:

@property (nonatomic, strong, readwrite) NSNumber *temperature;

dealloc 方法

启用 ARC 之后，dealloc 方法在大部分时候都不再需要了，因为你不能 调用实例对象的 release 方法，也不能调用[super dealloc]。假如原先的 dealloc 方法只是释放这些对象，Xcode 就会把 dealloc 方法完全移除。你不再 需要手动释放任何实例变量。
如果你的 dealloc 方法处理了其它资源(非内存)的释放，如定时器、Core Foundation 对象，则你仍然需要在 dealloc 方法中进行手动释放，如 CFRelease(), free()等。这时 Xcode 会保留 dealloc 方法，但是移除所有的 release 和[super dealloc]调用。如下:

- (void)dealloc 
{ 
AudioServicesDisposeSystemSoundID(soundID); 
}

Autoreleasepool

NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; 
int retVal = UIApplicationMain(argc, argv, nil, 
NSStringFromClass([AppDelegate class])); 
[pool release];

修改成:

@autoreleasepool {
    int retVal = UIApplicationMain(argc, argv, nil, 
    NSStringFromClass([AppDelegate class])); 
    return retVal;
}

• 使用 CFBridgingRelease()，从 Core Foundation 传递所有权给 Objective-C;

• 使用 CFBridgingRetain()，从 Objective-C 传递所有权给 Core Foundation;

• 使用__brideg，表示临时使用某种类型，不改变对象的所有权。

Blocks 与 ARC:

block里面访问全局变量，使用以下写法，防止self.的调用引起页面先释放而使变量

Block = ^() 
{
    id strongSelf = weakSelf; 
    if (strongSelf != nil) 
    { 
        // do stuff with strongSelf 
    } 
};

__weak __typeof(self)wself = self;
Block = ^()
{
    if (!wself) return;
    dispatch_main_sync_safe(^{
    });
}

ARC中的block里的autorelease, [operation autorelease];改为 operation = nil；

由于CGColorRef不是Objective-C对象，cgColor1、cgColor2 、cgColor3 变量都不是 strong 指针 。

单例：

+ (id)sharedInstance
{ 
    static GradientFactory *sharedInstance; 
    static dispatch_once_t done; 
    dispatch_once(&done, ^{ 
        sharedInstance = [[GradientFactory alloc] init]; 
    }); 

    return sharedInstance; 
}

即使多个线程同时执行这个 block，Grand Central Dispatch 库的
dispatch_once()函数也能确保 alloc 和 init 只会被执行一次。

Toll-Free Bridging

是指，在一部分 Core Foundation 框架 和 Foundation 框架相配对的数据类型间，可自动转换使用的机制。语法则是在变量前的括号中写入配对的数据类型。
相关宏定义：

#if __has_feature(objc_arc)
#define BRIDGE_CAST __bridge
#else
#define BRIDGE_CAST
#endif
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,937评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,503评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,712评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,668评论 1赞 276
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,677评论 5赞 366
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,601评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,975评论 3赞 396
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,637评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,881评论 1赞 298
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,387评论 4赞 319
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,971评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2赞 342