Objective-C指针/内存管理问题 [英] Objective-C pointers/memory management question

查看:78
本文介绍了Objective-C指针/内存管理问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在测试以下代码. ffv在接口文件中声明.

ffv = [[FullFunctionView alloc] initWithFrame:self.view.bounds];
NSLog(@"%i", [ffv retainCount]);  // prints 1
[self.view insertSubview:ffv belowSubview:switchViewsBtn];
NSLog(@"%i", [ffv retainCount]);  // prints 2
[ffv release]; // you can release it now since the view has ownership of ffv
NSLog(@"%i", [ffv retainCount]);  // prints 1

if (ffv == nil)
    NSLog(@"ffv is nil");

// "ffv is nil" is not printed

[ffv testMethod]; // "test method called" is printed

这是我的[ffv testMethod]实现

- (void)testMethod
{
    NSLog(@"test method called");
}

在这种情况下,我得出的结论是,即使释放具有保留计数2的对象,您也会失去对该对象的所有权,但是引用仍然保留.

现在,我的问题是:

  1. 我的推论正确吗?
  2. 从中可以推断出其他重要的东西吗?
  3. 仍然保留(使用)ffv并从ffv调用方法会导致哪些并发症? (我认为这是可以的,因为视图将始终拥有ffv,并且只有在有人调用viewDidUnload之前,它才会释放它.只要我不将ffv的引用传递给其他对象即可.)

解决方案

1)我的推论正确吗?

您的推论是正确的.

this is my [ffv testMethod] implementation

- (void)testMethod
{
    NSLog(@"test method called");
}

What I deduce in this case is that even if you release an object with retain count 2, you lose ownership of that object however, the reference is still kept.

Now, my question are:

  1. Is my deduction correct?
  2. Is there anything else important that can be deduced from this?
  3. What are the complications caused by still keeping (using) ffv and calling methods from ffv? (My opinion is that this is ok since the view will always own ffv and won't release it until someone calls viewDidUnload. And as long as I don't pass ffv's reference to other objects.)

解决方案

1) Is my deduction correct?

Your deduction is correct. The Memory Management Programming Guide explains that each object has one or many owners. You own any object you create using any method starting with alloc, new, copy, or mutableCopy. You can also take ownership of an object using retain. When you're done with an object, you must relinquish ownership using release or autorelease.

Releasing the object doesn't change the value of any variables that reference that object. Your variable contains the object's memory address until you reassign it, no matter what retain count the object has. Even if the object's retain count goes to zero, causing the object to get deallocated, your variable will still point at that same address. If you try to access the object after it's been deallocated, your app will normally crash with EXC_BAD_ACCESS. This is a common memory management bug.

2) Is there anything else important that can be deduced from this?

Nothing comes to mind.

3) What are the complications caused by still keeping (using) ffv and calling methods from ffv? (My opinion is that this is ok since the view will always own ffv and won't release it until someone calls viewDidUnload. And as long as I don't pass ffv's reference to other objects.)

When you call release, you are telling the Objective C runtime that you no longer require access to the object. While there may be many cases like this one in which you know the object will still exist, in practice you really shouldn't access an object after calling release. You'd just be tempting fate and setting yourself up for future bugs.

I personally don't like peppering my code with release statements, because I don't trust myself to remember them 100% of the time. Instead, I prefer to autorelease my variables as soon as I allocate them like this:

ffv = [[[FullFunctionView alloc] initWithFrame:self.view.bounds] autorelease];

This guarantees that ffv will exist at least until the end of the method. It will get released shortly thereafter, typically before the next iteration of the run loop. (In theory this could consume excessive memory if you're allocating a large number of temporary objects in a tight loop, but in practice I've never encountered this case. If I ever do, it will be easy to optimize.)

这篇关于Objective-C指针/内存管理问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆