Re: Understanding ARC
Re: Understanding ARC
- Subject: Re: Understanding ARC
- From: Dave <email@hidden>
- Date: Tue, 03 Jun 2014 18:08:32 +0100
Hi,
The only time you need to worry about autoreleased objects (if your App is 100% ARC), is when you call third party (including Apple) APIs. Even then it shouldn’t really cause a problem unless you are running in a loop which doesn’t call the run loop. In this case, depending on the APIs you may have Autoreleased objects building up to such an extent that you get terminated because your App is using too much memory.
The best way to find out what is happening is to run your app under Instruments allocation/leaks. If you memory going up with a horizontal line and not going down until the operations finish then Autorelease is a good candidate to the cause.
I tend to Bracket OS/Cocoa API that shift a significant amount of data with @auotreleasepool {} perhaps with something like this within the body:
myReturnObject = [objectReturnedByAPI copy];
This may actually copy data but usually it doesn’t due to optimisations in the OS. This creates a New Version of the Object that has a retain count of 1 (you don’t really need to care about this if using ARC), which basically means that as soon it it goes out of scope it will usually be released then and there.
Something like this:
-(SomeClass*) newObjectFromOS
{
SomeClass* myObject;
SomeClass* myReturnObject;
@autoreleasepool
{
myObject = [someOSClass getObject];
myReturnObject = [myObject copy];
}
return myReturnObject;
}
If you start the method name with “new” ARC knows not to autorelease the object and also, if you ever use the code in a Non-Arc project, it following the memory management rules.
Hope this helps
Dave
On 27 May 2014, at 09:27, Jamie Ojomoh <email@hidden> wrote:
>> YOU ARE OVERTHINKING THIS. Stop trying to figure out when things are
> getting released — that’s ARC’s job. Just write your code.
>
> That's what my dad said, but I though he just didn't know what the real
> answer was.
>
> Thank you for your helps.
>
>
> On Sun, May 25, 2014 at 5:46 PM, Jens Alfke <email@hidden> wrote:
>
>>
>> On May 25, 2014, at 2:07 AM, Jamie Ojomoh <email@hidden> wrote:
>>
>>> So if I use alloc/init then autoreleasepool doesn't work?
>>
>> No, I meant that the string hasn’t been autoreleased at all yet, so the
>> pool isn’t going to release it when it exits. The pool “works”, it’s just
>> not necessary.
>>
>>> Or don't I need autoreleasepool at all?
>>
>> You don’t need it. You only need an autorelease pool if
>> (a) You’re running a lengthy loop that allocates/autoreleases objects on
>> every iteration; wrapping the body in a pool, keeps those objects from
>> building up
>> (b) You’re implementing a C callback, i.e. from something like a CF or
>> Unix API.
>>
>>> Is there any difference in memory releasing / ARC between a class and a
>>> instance method?
>>
>> No. Those are totally unrelated concepts.
>>
>>> And why is it that memory automatically gets released properly when an
>>> application quits,
>>
>> It’s part of the job of an operating system to clean up resources left
>> behind by processes.
>>
>>> but when a class is released any memory that hasn't been
>>> freed or released properly hangs around forever? Is this not something
>>> that can be asked here?
>>
>> Classes don’t get released, objects do. I’m not quite sure what you’re
>> asking. Within a process, individual memory blocks have to be explicitly
>> freed. NSObject does this by keeping track of reference counts and freeing
>> the memory when the ref-count drops to zero. If an object isn’t released
>> enough times, it’ll stay around until the process quits.
>>
>> Releasing/freeing objects is kind of like cleaning up your room after
>> you’re done using things; you have to remember to put each thing away.
>> The process quitting is like your house getting bulldozed. Everything that
>> was in it is gone, there’s nothing left until a new house gets built.
>>
>> Anyway, YOU ARE OVERTHINKING THIS. Stop trying to figure out when things
>> are getting released — that’s ARC’s job. Just write your code.
>>
>> —Jens
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden