IOS memory management and iOS Memory Management

IOS memory management and iOS Memory Management

Memory Management for iOS is a common issue. When we write about iOS, memory management is involved all the time. From the initial MRR (manual retain-release) to the later ARC (Automatic Reference Counting), including CoreFoundation's memory management, all follow the basic principles of Reference Counting.

We are certainly familiar with basic memory management. Here we will focus on a little bit, and I will not talk about the rest. The official document contains a paragraph like this.

-You own any object you create

You create an object using a method whose name begins with "alloc", "new", "copy", or "mutableCopy" (for example, alloc, newObject, or mutableCopy ).

That is to say, if you use the methods starting with alloc/new/copy/mutableCopy to create an object, you will have this object (retain ). When you don't need it, you need to manually release it once.

For example, assume there is a method,[STObject newObject]

We should use this method. If we do not release the Object, it will cause the Object to be leaked.

123	STObject *object = [STObject newObject];// do something[object release];

 

In this case, we can imagine that if we want to implement the method starting with new, we need the following code:

1234567

- (instancetype)newObject {    return [[[self class] alloc] init];} + (UIButton *)copyButton {    return [[UIButton buttonWithType:UIButtonTypeCustom] retain];}

The following issues occur:

We can write the above experiment code and test it.

The final test result is as follows:

• Scenario 1 and 3 run normally
• Scenario 2: crash
• Scenario 4: Memory leakage

Why is scenario 2 crash? This is because under ARC, if the compiler sees that you have created an object in the method starting with alloc/new/copy/mutableCopy, the release operation will be inserted at the last time in use, because the returned object is autorelease and is release once again, this leads to a wild pointer.

Scenario 4 also causes leakage. The Compiler under ARC finds that the method starts with "new" and does not insert the release statement at the end of the method. In scenario 4, newObject is not release, so leakage occurs.

This problem will not occur if we only use MRR or ARC. This problem occurs generally when the ARC/MRR is mixed, due to some writing irregularities, in the process of writing code,Compliance with regulations is necessary.

If we write Methods Starting with alloc/new/copy/mutableCopy, do not forget to return the retain object in MRR, similarly, when we use the alloc/new/copy/mutableCopy method to create an object, we cannot forget to release the object after use.

If we have a piece of MRR code that provides a method starting with "new" but does not comply with the specifications, what should we do under "ARC? According to the above conclusion, our normal use will certainly lead to a wild pointer

Here, if you can change the code, of course, it is best to change the code to comply with the specifications. If you cannot change the source code, we can only modify the users. Here we provide a method:

12	SEL selector = NSSelectorFromString(@"copyObject");STObject *object = (STObject *)[STObject performSelector:selector];

You can try and think about why.

Memory Management for iOS is far more than that. In this article, we mentioned that the actual coding process is rarely encountered. Just use it as a supplement to knowledge ~