ios delegatee 作为属性,为什么要用weak修饰

2914人阅读
copy: 创建一个引用计数为1的对象,然后释放旧的对象
retain:释放旧的对象,将旧对象的值赋予输入对象,再提高输入对象的引用计数为 1
Copy其实是建立了一个相同的对象,而retain不是:
比如一个NSString对象,地址为0×1111,内容为@”STR”
Copy到另外一个NSString之 后,地址为0×2222,内容相同,新的对象retain为1, 旧有对象没有变化
retain到另外一个NSString之 后,地址相同(建立一个指针,指针拷贝),内容当然相同,这个对象的retain值+1
也就是说,retain是指针拷贝,copy是内容拷贝。在拷贝之前,都会释放旧的对象。
1、使用copy: 对NSString
2、使用retain: 对其他NSObject和其子类
strong与weak是由ARC新引入的对象变量属性
ARC引入了新的对象的新生命周期限定,即零弱引用。如果零弱引用指向的对象被deallocated的话,零弱引用的对象会被自动设置为nil。
@property(strong) MyClass *myO
相当于@property(retain) MyClass *myO
@property(weak) MyOtherClass *
相当于@property(assign) MyOtherClass *
强引用与弱引用的广义区别:
强引用也就是我们通常所讲的引用,其存亡直接决定了所指对象的存亡。如果不存在指向一个对象的引用,并且此对象不再显示列表中,则此对象会被从内存中释放。
弱引用除了不决定对象的存亡外,其他与强引用相同。即使一个对象被持有无数个若引用,只要没有强引用指向他,那麽其还是会被清除。
简单讲strong等同retain
weak比assign多了一个功能,当对象消失后自动把指针变成nil,好处不言而喻。
__weak, __strong 用来修饰变量,此外还有 __unsafe_unretained, __autoreleasing 都是用来修饰变量的。
__strong 是缺省的关键词。
__weak 声明了一个可以自动 nil 化的弱引用。
__unsafe_unretained 声明一个弱应用,但是不会自动nil化,也就是说,如果所指向的内存区域被释放了,这个指针就是一个野指针了。
__autoreleasing 用来修饰一个函数的参数,这个参数会在函数返回的时候被自动释放。
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:136431次
积分:1744
积分:1744
排名:第8876名
原创:38篇
转载:17篇
评论:60条
(1)(1)(1)(1)(3)(3)(9)(3)(4)(4)(1)(1)(1)(5)(4)(3)(3)(1)(7)相关资源链接:1,
.h文件中:
1,@property (strong,nonatomic)中属性的定义主要是类对外的接口,将retain,copy等变为strong。
2,私有变量
.m文件中的类扩展定义的私有属性变量,即@interface class (){@property()nsarray * array;}
& & 现在直接在类实现中@implementation class{ nsarray * array;}即可----附:此处仍然可以self.array来访问。
除了files owner(链接nib顶层对象用strong)之外,均用weak。
优势:unload中,不需要self.outlet=了。
附:当接受到内存警告时,ViewCtl的mainView会unload,释放其所有subView。但是需要设置所有非outlet变量为nil。
4,strong=retain,weak(outlet多用),unsafe_unretained=assign(IOS4适用),copy=copy+strong,assign(原始类型BOOL,int,CGFloat等),readonly要+strong,id&protical&delegate用weak,nonatomic,block用copy。
5,在.m文件中,移除所有的autorelease,retain,release调用。
诸如:self.XX=[[[mainVC alloc]init]autorelease];现在改为:self.XX=[[mainVC alloc]init]即可。
6,dealloc{},移除所有release方法,【super dealoc】;其他资源如定时器,CF对象时才需要之。CFRealse等。作用:1,移除监听;2,取消注册通知;3,将non-weak delegate设置为nil;4,invalidate timers。
7,@autoreleasepool用法:
if someArray很大
for(id obj in someArray)
@autoreleasepool
//假如你创建了许多中间临时变量在此处
8,某个项目中若设置某个文件不使用arc,方法:在Build Phases -& Compile sources,选择需要的文件,在右边Compile Flags输入-fno-objc-arc
&启用arc:-fobjc-arc 。
9,Blocks:主要在于blocks中的循环参照问题。
a,block在属性定义的时候,使用copy。
调用端如下:
MyObject&*object&=&[[MyObject&alloc]&init];&object.str&=&@&hoge&;&object.block&=&^{NSLog(@&block: str=%@&,&object.str);&};&[object&performBlock];
由上可知:object和block构成了循环参照,如图:
解决办法:
1,使用__block修饰---
使用__block关键字,让对象有读写权限,如果Block内的处理完毕就释放object。
__block&MyObject&*object&=&[[MyObject&alloc]&init];&object.str&=&@&hoge&;&object.block=&^{&NSLog(@&block: str=%@&,&object.str);&object&=&nil;&};&[object&performBlock];
关键字的意思就是让block取消对object的强参照,以避免循环参照。但是,有一个问题就是,object的释放动作是在Block内部执 行,如果Block没有被执行的话,循环参照一直存在。比如上面的代码,如果第8行 [object performBlock]; 没有执行的话,那么一直还是循环参照状态。
使用__weak关键字修饰另一种方案就是让Block的参照变为弱参照。MyObject&*object&=&[[MyObject&alloc]&init];&object.str&=&@&hoge&;&__weak&MyObject*weakObject&=&object;&object.block&=&^{&NSLog(@&block: str=%@&,&weakObject.str);&};[object&performBlock];考虑到异步通信时Blocks的使用情况,weak变量weakObject有可能随时变为nil,所以类似于下面先变为strong变量,并检查是否为nil的处理方式应该更安全。MyObject&*object&=&[[MyObject&alloc]&init];&object.str&=&@&hoge&;&__weak&MyObject*weakObject&=&object;&object.block&=&^{&MyObject&strongObject&=&weakObject;&if(strongObject)&{&NSLog(@&block: str=%@&,&strongObject.str);&}&};&[objectperformBlock];总上,当我们使用Blocks时,也需要考虑Block中变量和实例的关系,不要引起不必要的循环参照问题。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
以下未细化:
手动下的情况:
1,凡用alloc/new/copy/mutableCopy,则生成对象并拥有其所有权;
2,retain-拥有对象所有权,release-释放对象所有权,dealloc-释放对象资源。
3,变成准则:
生成对象时,使用autorelease--&返回对象即return [[object retain] autorelease];
对象代入时,先autorelease再retain--&代入对象即
- (void)setMember:(TempValue *)value {
& [_member autorelease];
& _member = [value retain];
1,指针在,obj就在。
2,父Var--&子Var& :strong引用;子Var--&父Var& :Weak引用
3,在手动惯例内存时,一旦obj自array中remove后,obj便会销毁。但在ARC中,obj拥有该值的strong引用--
[array objectAtIndex:0];
[array removeObjectAtIndex:0];
NSLog(@&%@&, obj);
1,不能使用NSAutoReleasePool、而需要@autoreleasepool块
2,retain, release, autorelease, dealloc由编译器自动插入,不能在代码中调用, & dealloc虽然可以被重载,但是不能调用[super dealloc]。
引用关键字:
1,strong, weak, autoreleasing限定的变量会被隐式初始化为nil。
2,_strong:(缺省)
4,_unsafe_unretained:其修饰的,当无所有者时,其不自动指向nil。
5,_autoreleasing:该关键字使对像延迟释放。比如你想传一个未初始化的对像引用到一个方法当中,在此方法中实例化此对像,那么这种情况可以使用__autoreleasing。他被经常用于函数有值参数返回时的处理.
例:- (void) generateErrorInVariable:(__autoreleasing NSError **)paramError&
&& *paramError = [[NSError alloc] initWithDomain:@&MyApp& code:& & & & 1userInfo:errorDictionary];&
{ NSError *error =&
[selfgenerateErrorInVariable:&error];
&NSLog(@&Error = %@&, error); }
-----------------------------------------
函数的返回值是在函数中申请的,那么希望释放是在调用端时:
例:-(NSString *)stringTest&
{ NSString *retStr = [NSString stringWithString:@&test&];
& & return [[retStr retain] autorelease];&
// 使用ARC&
-(NSString *)stringTest&
& __autoreleasing NSString *retStr = [NSString alloc] & initWithString:@&test&];&
&& returnretS&
即当方法的参数是id*,且希望方法返回时对象被autoreleased,那么使用该关键字。
基本的ARC使用规则
代码中不能使用retain, release, retain, autorelease不重载dealloc(如果是释放对象内存以外的处理,是可以重载该函数的,但是不能调用[super dealloc])不能使用NSAllocateObject, NSDeallocateObject不能在C结构体中使用对象指针id与void *间的如果cast时需要用特定的方法(__bridge关键字)不能使用NSAutoReleasePool、而需要@autoreleasepool块不能使用“new”开始的属性名称 (如果使用会有下面的编译错误”Property’s synthesized getter follows Cocoa naming convention for returning ‘owned’ objects”)
ARC之@property
属性值
unsafe_unretained
__unsafe_unretained
__unsafe_unretained
1,weak:delegate和IBOutlet用该属性来声明
2,assign:一般数据变量,BOOL
3,unsafe_unretained等价weak。
4,readwrite和readonly-----需要类似@property (nonatomic, strong, readonly) NSString *
typedef void(^MyBlock)(void);
&@interface MyObject : NSObject&
@property (nonatomic,copy) MyB&
@property (nonatomic, strong) NSString *&
-(void)performB
@implementation MyObject&
@synthesize block,&
-(void)performBlock&
&& if (self.block)&
& & & { self.block(); }
-----------------------------------------------------------
1,基本var用assign:
@property (nonatomic, assign) int scalarI
2,对象var用strong,weak:
@property (nonatomic, strong) id childO
@property (nonatomic, weak) id parentO
@property (nonatomic, weak) NSObject &SomeDelegate& *
注意:IBOutlets均设定为weak,除了top-level IBOutlets用strong外。
3,blocks对象用copy:
@property (nonatomic, copy) SomeBlockType someB
4,在dealloc中主要任务:
&& 1,移除observers;
&& 2,unregister for notifications
&& 3,set any non-weak delegates to nil;
&& 4,invalidate any timers
5,Bridging:
CFStringRef my_
NSString & *a = (__bridge NSString*)my_ & & // Noop cast.
CFStringRef b = (__bridge CFStringRef)my_& & & // Noop cast.
NSString & *c = (__bridge_transfer NSString*)my_ // -1 on the CFRef
CFStringRef d = (__bridge_retained CFStringRef)my_& // returned CFRef +1
Core Foundation框架 (CoreFoundation.framework) 是一组C语言接口,它们为iOS应用程序提供基本数据管理和服务功能。Core
Foundation框架和Foundation框架紧密相关,它们为相同功能提供接口,但Foundation框架提供Objective-C接口。如果您将Foundation对象和Core Foundation类型掺杂使用,则可利用两个框架之间的 “toll-free bridging”。所谓的Toll-free bridging是说您可以在某个框架的方法或函数同时使用Core Foundatio和Foundation 框架中的某些类型。很多数据类型支持这一特性,其中包括群体和字符串数据类型。每个框架的类和类型描述都会对某个对象是否为
toll-free bridged,应和什么对象桥接进行说明。
自 Xcode4.2 开始导入ARC机制后,为了支持对象间的转型,Apple又增加了许多转型用的关键字。这一讲我们就来了解其用法,以及产生的理由。
我们先来看一下ARC无效的时候,我们写id类型转void*类型的写法:
id obj = [[NSObject alloc] init];
反过来,当把void*对象变回id类型时,只是简单地如下来写,
[obj release];
但是上面的代码在ARC有效时,就有了下面的错误:
&&&&error: implicit conversion of an Objective-C pointer
&&&&&&&&to ’void *’ is disallowed with ARC
&&&&&&&&void *p =
&&&&&&&&&&&&&&&&&&^
&&&&error: implicit conversion of a non-Objective-C pointer
&&&&&&&&type ’void *’ to ’id’ is disallowed with ARC
&&&&&&&&id o =
&&&&&&&&&&&&&&&&^
为了解决这一问题,我们使用 __bridge 关键字来实现id类型与void*类型的相互转换。看下面的例子。
id obj = [[NSObject alloc] init];
void *p = (__bridge void *)
id o = (__bridge id)p;
将Objective-C的对象类型用 __bridge 转换为 void* 类型和使用 __unsafe_unretained 关键字修饰的变量是一样的。被代入对象的所有者需要明确对象生命周期的管理,不要出现异常访问的问题。
除过 __bridge 以外,还有两个 __bridge 相关的类型转换关键字:
__bridge_transfer
__bridge_retained
接下来,我们将看看这两个关键字的区别。
__bridge_retained
先来看使用 __bridge_retained&关键字的例子程序:
id obj = [[NSObject alloc] init];
void *p = (__bridge_retained void *)
从名字上我们应该能理解其意义:类型被转换时,其对象的所有权也将被变换后变量所持有。如果不是ARC代码,类似下面的实现:
id obj = [[NSObject alloc] init];
[(id)p retain];
可以用一个实际的例子验证,对象所有权是否被持有。
void *p = 0;
&&&&id obj = [[NSObject alloc] init];
&&&&p = (__bridge_retained void *)
NSLog(@&class=%@&, [(__bridge id)p class]);
出了大括号的范围后,p 仍然指向一个有效的实体。说明他拥有该对象的所有权,该对象没有因为出其定义范围而被销毁。
__bridge_transfer
相反,当想把本来拥有对象所有权的变量,在类型转换后,让其释放原先所有权的时候,需要使用 __bridge_transfer 关键字。文字有点绕口,我们还是来看一段代码吧。
如果ARC无效的时候,我们可能需要写下面的代码。
// p 变量原先持有对象的所有权
id obj = (id)p;
[obj retain];
[(id)p release];
那么ARC有效后,我们可以用下面的代码来替换:
// p 变量原先持有对象的所有权
id obj = (__bridge_transfer id)p;
可以看出来,__bridge_retained 是编译器替我们做了 retain 操作,而 __bridge_transfer 是替我们做了 release1。
Toll-Free bridged
在iOS世界,主要有两种对象:Objective-C 对象和 Core Foundation 对象0。Core Foundation 对象主要是有C语言实现的 Core Foundation Framework 的对象,其中也有对象引用计数的概念,只是不是 Cocoa Framework::Foundation Framework 的 retain/release,而是自身的 CFRetain/CFRelease 接口。
这两种对象间可以互相转换和操作,不使用ARC的时候,单纯的用C原因的类型转换,不需要消耗CPU的资源,所以叫做 Toll-Free bridged。比如 NSArray和CFArrayRef, NSString和CFStringRef,他们虽然属于不同的 Framework,但是具有相同的对象结构,所以可以用标准C的类型转换。
比如不使用ARC时,我们用下面的代码:
NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = (CFStringRef)
同样,Core Foundation类型向Objective-C类型转换时,也是简单地用标准C的类型转换即可。
但是在ARC有效的情况下,将出现类似下面的编译错误:
&&&&Cast of Objective-C pointer type ‘NSString *’ to C pointer type ‘CFStringRef’ (aka ‘const struct __CFString *’) requires a bridged cast
&&&&Use __bridge to convert directly (no change in ownership)
&&&&Use __bridge_retained to make an ARC object available as a +1 ‘CFStringRef’ (aka ‘const struct __CFString *’)
错误中已经提示了我们需要怎样做:用 __bridge 或者 __bridge_retained&来转型,其差别就是变更对象的所有权。
正因为Objective-C是ARC管理的对象,而Core Foundation不是ARC管理的对象,所以才要特意这样转换,这与id类型向void*转换是一个概念。也就是说,当这两种类型(有ARC管理,没有ARC管理)在转换时,需要告诉编译器怎样处理对象的所有权。
上面的例子,使用 __bridge/__bridge_retained 后的代码如下:
NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = (__bridge CFStringRef)
只是单纯地执行了类型转换,没有进行所有权的转移,也就是说,当string对象被释放的时候,cfString也不能被使用了。
NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = (__bridge_retained CFStringRef)
CFRelease(cfString); // 由于Core Foundation的对象不属于ARC的管理范畴,所以需要自己release
使用 __bridge_retained 可以通过转换目标处(cfString)的 retain 处理,来使所有权转移。即使 string 变量被释放,cfString 还是可以使用具体的对象。只是有一点,由于Core Foundation的对象不属于ARC的管理范畴,所以需要自己release。
实际上,Core Foundation 内部,为了实现Core Foundation对象类型与Objective-C对象类型的相互转换,提供了下面的函数。
CFTypeRef&&CFBridgingRetain(id&&X)&&{
&&&&return&&(__bridge_retained&&CFTypeRef)X;
id&&CFBridgingRelease(CFTypeRef&&X)&&{
&&&&return&&(__bridge_transfer&&id)X;
所以,可以用 CFBridgingRetain 替代 __bridge_retained 关键字:
NSString *string = [NSString stringWithFormat:...];
CFStringRef cfString = CFBridgingRetain(string);
CFRelease(cfString); // 由于Core Foundation不在ARC管理范围内,所以需要主动release。
__bridge_transfer
所有权被转移的同时,被转换变量将失去对象的所有权。当Core Foundation对象类型向Objective-C对象类型转换的时候,会经常用到 __bridge_transfer 关键字。
CFStringRef cfString = CFStringCreate...();
NSString *string = (__bridge_transfer NSString *)cfS
// CFRelease(cfString); 因为已经用 __bridge_transfer 转移了对象的所有权,所以不需要调用 release
同样,我们可以使用 CFBridgingRelease() 来代替 __bridge_transfer 关键字。
CFStringRef cfString = CFStringCreate...();
NSString *string = CFBridgingRelease(cfString);
由上面的学习我们了解到 ARC 中类型转换的用法,那么我们实际使用中按照怎样的原则或者方法来区分使用呢,下面我总结了几点关键要素。
明确被转换类型是否是 ARC 管理的对象
Core Foundation 对象类型不在 ARC 管理范畴内
Cocoa Framework::Foundation 对象类型(即一般使用到的Objectie-C对象类型)在 ARC 的管理范畴内
如果不在 ARC 管理范畴内的对象,那么要清楚 release 的责任应该是谁
各种对象的生命周期是怎样的
1. 声明 id obj 的时候,其实是缺省的申明了一个 __strong 修饰的变量,所以编译器自动地加入了 retain 的处理,所以说 __bridge_transfer 关键字只为我们做了 release 处理。
根据苹果官方的文档(/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html):
__bridge只做类型转换,但是不修改对象(内存)管理权;
__bridge_retained(也可以使用CFBridgingRetain)将Objective-C的对象转换为Core Foundation的对象,同时将对象(内存)的管理权交给我们,后续需要使用CFRelease或者相关方法来释放对象;
__bridge_transfer(也可以使用CFBridgingRelease)将Core Foundation的对象转换为Objective-C的对象,同时将对象(内存)的管理权交给ARC。
旧工程配置arc方案:
1、直接在targets-&build phases中修改compiler Flags,是否支持arc。添加:-fobjc-arc,就可以让旧项目支持arc。如果想让原来支持arc的不使用arc则添加-fno-objc-arc
2、因为在build phases中可以改变是否支持arc,所以应该在代码中添加判断是否支持arc,这样不管以后.m的arc是否改变,都不用再次调整代码。
下面是一个.h文件(附件中也上传了.h),整合了arc的各种属性、release判断,直接#import在你想使用arc的类中即可。
#ifndef paixiu_PXISARC_h
#define paixiu_PXISARC_h
#ifndef PX_STRONG
#if __has_feature(objc_arc)
#define PX_STRONG strong
#define PX_STRONG retain
#ifndef PX_WEAK
#if __has_feature(objc_arc_weak)
#define PX_WEAK weak
#elif __has_feature(objc_arc)
#define PX_WEAK unsafe_unretained
#define PX_WEAK assign
#if __has_feature(objc_arc)
#define PX_AUTORELEASE(expression) expression
#define PX_RELEASE(expression) expression
#define PX_RETAIN(expression) expression
#define PX_AUTORELEASE(expression) [expression autorelease]
#define PX_RELEASE(expression) [expression release]
#define PX_RETAIN(expression) [expression retain]
说明:在arc中,strong对应原来的retain与copy,weak对应原来的assign。
EX:举例使用autorelease:
NSArray *testArray = PX_AUTORELEASE([[NSArray alloc] init]);
&//如果支持arc,testArray就只是alloc init,release的事情由系统来做。
//如果不支持arc,那这条语句相当于:
NSArray *testArray = [[[NSArray alloc] init] autorelease];
这样不管以后改不改arc,都不会内存泄漏了。
所以,arc的使用有两点:
A:在build phases中修改compiler Flags值。
B:在代码中判断是否支持arc,包括对属性(property)、释放(release)的判断。
3、在dealloc中需要这样做:
类如果注册了通知(观察者模式),需要remove掉。这个不管是否支持arc,都必须要做的。
- (void)dealloc {
[[NSNotificationCenterdefaultCenter] removeObserver:self];//如果注册了通知的话。
[self removeObserver:self forKeyPath:keyPath];//如果注册了kvo的话。
#if !__has_feature(objc_arc)& //在这里也需要判断是否支持arc,支持的话就执行旧工程中该release的语句.
&&& [array release]; //array代表alloc但没有autorelease的变量
&&& [super dealloc];
4、另外加点block的判断,这个是在4.0以后有的,当然也可以不进行判断,因为现在大多数都4.0以后了。
#if NS_BLOCKS_AVAILABLE
1、arc的设置是在build phases中修改compiler Flags的值。
2、如果使用了arc,在你的代码中不可以使用retain, release, autorelease,如果使用的话会报错。
3、如果使用了arc,在@property声明中,用strong代替retain。在支持__unsafe_unretained的情况下,__unsafe_unretained相当于assign。
4、如果使用了arc,NSAutoReleasePool也不能使用,测试发现,用@autoreleasepool 代替,不会编译报错。
总之,一切你之前“背过”的那几条内存管理规则,你都不用去管了。而且,个人感觉,用arc代码清晰很多,而且效率也提高了些。
——————————————————————————————————
对于arc属性可能写的不太清楚,这里附加点:
1、不管在不在arc下,object对象都有强引用、弱引用之分,当需要保持(拥有)其他对象的时候,需要retain。
2、在arc中,使用strong、weak修饰的变量,当对象不再存在的时候会被置为nil。而[align=-webkit-left]__unsafe_unretained不会被置为nil,会成为野指针,是不安全的,再次访问可能造成错误。
[align=-webkit-left]3,引用关键字:arc中,变量声明默认为_strong.
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:57045次
排名:千里之外
原创:17篇
转载:52篇
(2)(6)(2)(3)(4)(1)(1)(2)(7)(2)(4)(8)(11)(18)在前面分析了nomantic、copy、retain等属性之后,在教新的XCode版本中,我们又经常会看到__unsafe_unretain、__strong、__weak、__autoreleasing这四种属性,那么他们有什么用呢?
__unsafe_unretain、__strong、__weak、__autoreleasing是出现在 LLVM 编译器 3.0版本之后。而__unsafe_unretain、__strong、__autoreleasing可以在不使用ARC(自动参考计数)可用。在ARC下,默认的指针都是__strong属性。这意味着一个对象赋值给另外一个指针,那么只要指针参考了该对象,该对象就会一直保持。这对于大部分对象都实用,但是这可能会导致retain cycle。例如,你拥有一个对象包含了另外了一个实例变量对象,但是第二个对象又把前一个对象作为它的委托,那么这两个对象将不会被释放。
因为上面的原因,所以才有了__unsafe_unretain和__weak限定符存在。他们通常用来修饰delegate,即定义一个delegate的属性时,使用__unsafe_unretain和__weak来修饰,然后通过使用__unsafe_unretain和__weak来单独标记实例变量。这意味着delegate实例变量将仍然能够指向第一个对象,但是它不会导致保留第一个对象,因此打破了retain cycle,而能够释放两个对象
除了delegate,__unsafe_unretain和__weak修饰符也还能避免你的代码出现retain cycle。Leaks instrument现在包含了一个cycle视图,能够发现你的应用中的retain cycle,并图像显示出来。
__unsafe_unretain和__weak都能避免retain cycle,但是他们也有一些细微的不同。对于__weak,当释放指针指向的对象时,该对象的指针将转换为nil,这是比较安全的行为。而__unsafe_unretain,正如其名称隐藏的含义,尽管释放指针指向的对象时,该指针将继续指向原来的内存。这将会导致应用crash,所以是unsafe。
为什么我们仍要使用__unsafe_unretain呢?这是因为__weak直到iOS5.0以及lion之后才出现。
而__autoreleasing 的英文解释为:to denote arguments that are passed by reference (id *) and are autoreleased on return,即主要是在引用传参时使用。
最后需要注意的一点是:cocoa设定了一个规则,即父对象建立子对象的强引用,而子对象只对父对象建立弱引用。
而使用弱引用时需要注意,当你发消息给一个被dealloc的弱引用对象时,你的程序会崩毁。因此,必须细致地判断对象是否有效。多数情况下,被弱引用地对象是知道其他对象对它的弱引用的,所以当它自己dealloc时,需要通知对它弱引用的其他对象。
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:67378次
积分:1208
积分:1208
排名:第14235名
转载:230篇
评论:11条
(12)(23)(53)(22)(11)(15)(3)(22)(36)(2)(2)(22)(2)(1)(1)(7)(3)(6)(6)(3)(5)(18)(23)(4)(1)

我要回帖

更多关于 jquery delegate 的文章

 

随机推荐