Questions tagged «automatic-ref-counting»

自动引用计数（ARC）是一种编译器功能，可提供对Objective-C和Swift对象的自动内存管理。

7
在这个区块中强烈地捕捉自我很可能会导致保留周期
如何避免在xcode中出现此警告。这是代码片段： [player(AVPlayer object) addPeriodicTimeObserverForInterval:CMTimeMakeWithSeconds(0.1, 100) queue:nil usingBlock:^(CMTime time) { current+=1; if(current==60) { min+=(current/60); current = 0; } [timerDisp(UILabel) setText:[NSString stringWithFormat:@"%02d:%02d",min,current]];///warning occurs in this line }];
7
为什么ARC仍需要@autoreleasepool？
在大多数情况下，对于ARC（自动引用计数），我们根本不需要考虑使用Objective-C对象进行内存管理。不再允许创建NSAutoreleasePool，但是有一个新语法： @autoreleasepool { … } 我的问题是，当我不应该手动释放/自动释放时，为什么会需要这个？ 编辑：总结一下我从所有答案和评论中得出的结论： 新语法： @autoreleasepool { … } 是的新语法 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; … [pool drain]; 更重要的是： ARC使用autorelease和release。 为此需要一个自动释放池。 ARC不会为您创建自动发布池。然而： 每个Cocoa应用程序的主线程中已经有一个自动释放池。 在两种情况下，您可能想使用@autoreleasepool： 当您处于辅助线程中并且没有自动释放池时，必须进行自己的设置以防止泄漏，例如myRunLoop(…) { @autoreleasepool { … } return success; }。 当您希望创建更多本地池时，如@mattjgalloway在其答案中所示。
4
禁用某些文件的自动引用计数
我已经下载了iOS 5 SDK，并发现ARC是新Apple编译器的一项强大功能。目前，许多第三方框架不支持ARC。我可以使用ARC作为新代码并保持当前的保留/发布代码不变吗？ARC转换器在这里不起作用，因为某些框架（例如JSONKit）无法使用该转换器转换为ARC。 编辑： 答案是为-fno-objc-arc不需要ARC的文件添加到编译器标志。在Xcode 4中，您可以在目标->构建阶段->编译源代码下执行此操作。
3
ARC和桥接铸造
使用ARC，我无法再转换CGColorRef为id。我了解到我需要进行桥接。根据c文件： 一桥连投是C样式转换标注有三个关键字之一： (__bridge T) op将操作数强制转换为目标类型T。如果T 是可保留对象指针类型，则op必须具有不可保留指针类型。如果T是不可保留的指针类型，则op必须具有可保留的对象指针类型。否则，演员表的格式不正确。没有所有权转移，并且ARC不插入保留操作。 (__bridge_retained T) op将必须具有可保留对象指针类型的操作数强制转换为必须是不可保留指针类型的目标类型。ARC保留该值，但要对本地值进行通常的优化，并且接收方负责平衡+1。 (__bridge_transfer T) op将必须具有不可保留的指针类型的操作数强制转换为必须是可保留的对象指针类型的目标类型。ARC将在封闭的全表达式结束时释放该值，但要对本地值进行通常的优化。 这些转换是必需的，以便在ARC控制中进出对象。请参阅有关可保留对象指针的转换部分的基本原理。 仅使用a __bridge_retained或__bridge_transfercast来说服ARC分别发出不平衡的保留或释放是不好的形式。 我会在哪种情况下使用它们？ 例如，CAGradientLayer具有一个colors接受CGColorRefs 数组的属性。我的猜测是我应该__brige在这里使用，但是不清楚为什么应该（或者不应该）。
7
在启用ARC的代码中修复警告“在此块中强烈捕获[对象]可能会导致保留周期”
在启用ARC的代码中，当使用基于块的API时，如何解决有关潜在保留周期的警告？ 警告： Capturing 'request' strongly in this block is likely to lead to a retain cycle 由以下代码片段生成： ASIHTTPRequest *request = [[ASIHTTPRequest alloc] initWithURL:... [request setCompletionBlock:^{ NSDictionary *jsonDictionary = [[CJSONDeserializer deserializer] deserialize:request.rawResponseData error:nil]; // ... }]; 警告与request块内对象的使用有关。
5
有关iOS5 SDK中自动引用计数的一些问题
我目前正在开发iPad版应用程序。该开发工作始于iOS 4.2，现在正在继续（并且我认为将完成）针对iOS 4.3。我刚刚阅读了iOS 5中的ARC，并且基本上我了解到我们将不再需要释放和保留对象。我的问题是： 如果我决定升级到iOS 5，是否需要删除所有 [myObject retain][myObject release]从代码中和语句？ 如果我使用ARC开发了适用于iOS 5的新应用，是否需要实施某种“复古兼容性”检查？即：我需要检查iOS版本并相应地调用“保留并释放”吗？因此，基本上，ARC是否适用于所有iOS版本或仅适用于iOS 5？
2
使用ARC时，是否在dealloc中将属性设置为nil？
我正在尝试学习iOS 5中的自动引用计数。现在，此问题的第一部分应该很简单： 它是正确的，我根本不使用ARC时需要写在我的dealloc明确释放属性声明？换句话说，这是真的，以下就不是需要一个明确的dealloc的？ @interface MyClass : NSObject @property (strong, nonatomic) NSObject* myProperty; @end @implementation MyClass @synthesize myProperty; @end 我的下一个更重要的问题来自“ 过渡到ARC发行说明”文档中的一行： 您不必（实际上不能）释放实例变量，但是您可能需要在系统类和未使用ARC编译的其他代码上调用[self setDelegate：nil]。 这就引出了一个问题：我怎么知道哪些系统类没有用ARC编译？什么时候应该创建自己的dealloc并将显着保留的属性显式设置为nil？我是否应该假设属性中使用的所有NS和UI框架类都需要显式的dealloc？ 关于SO和其他方面的大量信息，涉及使用手动引用跟踪时释放属性支持ivar的做法，但是使用ARC时，有关此信息的信息很少。
1
这里的“实例消息的接收者类型'CALayer'是转发声明”是什么意思？
我正在将代码块从iOS4项目移植到iOS5，但是ARC遇到了一些麻烦。该代码从屏幕截图生成PDF。 PDF生成代码 UIView *captureView; ... NSMutableData *pdfData = [NSMutableData data]; UIGraphicsBeginPDFContextToData(pdfData, captureView.bounds, nil); UIGraphicsBeginPDFPage(); CGContextRef pdfContext = UIGraphicsGetCurrentContext(); [captureView.layer renderInContext:pdfContext]; UIGraphicsEndPDFContext(); renderInContext行 [captureView.layer renderInContext:pdfContext]; 产生以下错误。 Automatic Reference Counting issue Receiver type 'CALayer' for instance message is a forward declaration 有什么想法吗？
3
在哪种情况下，我们需要在ARC下编写__autoreleasing所有权限定符？
我正在努力完成难题。 __strong是所有Objective-C可保留对象指针（如NSObject，NSString等）的默认值。这是一个强大的参考。ARC -release在范围的末尾与a 保持平衡。 __unsafe_unretained等于旧方法。它用于弱指针而不保留可保留对象。 __weak__unsafe_unretained与之类似，只是它是一个自动归零的弱引用，这意味着一旦释放引用的对象，指针将设置为nil。这消除了悬挂指针和EXC_BAD_ACCESS错误的危险。 但是究竟有什么__autoreleasing好处呢？我很难找到有关何时需要使用此限定符的实际示例。我相信这仅适用于期望指针指向的函数和方法，例如： - (BOOL)save:(NSError**); 要么 NSError *error = nil; [database save:&error]; 在ARC下必须这样声明： - (BOOL)save:(NSError* __autoreleasing *); 但这太模糊了，我想完全理解为什么。我发现的代码片段将__autoreleasing放在两颗星之间，这对我来说很奇怪。类型是NSError**（指向NSError的指针），那么为什么要放置__autoreleasing在星星之间而不是简单地放置在它们之间NSError**？ 另外，可能还有其他情况我必须依靠__autoreleasing。
6
iOS5中强弱存储的说明
我是iOS5开发的新手，正在使用Objective-C。我很难理解强存储和弱存储之间的区别。我已经阅读了文档和其他SO问题，但是它们听起来与我完全相同，没有进一步的了解。 我阅读了以下文档：过渡到ARC-引用了iOS4的保留，分配和发布条款；这让我感到困惑。然后，我看一下Open U CS193p，它区分强项和弱项： 强：“将其保留在堆中，直到我不再指向它为止” 弱：“只要其他人强烈将其保留，则保留此” 这两个定义是否相同=如果指针不再指向对象，则释放保存该对象的内存？我了解指针，内存堆，分配或释放的概念-但是强和弱之间有什么区别？
6
去ARC还是不去ARC？优缺点都有什么？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 改善这个问题 由于我目前正在处理的项目中的大多数代码都是在iOS 5.0之前编写的，因此我尚未使用ARC。 我只是在想，不手动保留/释放（由此带来的结果可能是更可靠的代码）的便利是否超过了使用ARC的任何“成本”？您对ARC有什么经验，您会推荐吗？ 所以： ARC可为项目带来多少收益？ ARC是否具有Java垃圾回收这样的成本？ 您是否一直在使用ARC？如果是，到目前为止，您是如何找到它的？
3
在弹出窗口仍然可见的情况下达到了UIPopovercontroller的dealloc
我向你保证，我确实在为我的问题寻找答案，但是没有一个是有帮助的。在这里，我得到了一个简单的代码，应UIImagePickerController在内显示UIPopoverController： -(void)takePicture:(id)sender{ UIImagePickerController *picker=[[UIImagePickerController alloc] init]; picker.delegate=self; picker.sourceType=UIImagePickerControllerSourceTypeCamera; picker.allowsEditing=YES; UIPopoverController *poc=[[UIPopoverController alloc] initWithContentViewController:picker]; [poc presentPopoverFromBarButtonItem:bbItem permittedArrowDirections:UIPopoverArrowDirectionAny animated:NO]; } 现在，即使是第一次[UIPopoveController dealloc]接触……错误，程序也会崩溃。根据ARC，我没有进行任何保留，释放或自动释放。UIPopoverControllers受益于ARC时是否需要特别考虑？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.