iOS alternative memory management

[[129290]]

OS memory management is a commonplace issue. When we write iOS, we are always involved in memory management. From the beginning of MRR (manual retain-release) to the later ARC (Automatic Reference Counting), including CoreFoundation's memory management, all follow the basic principle of reference counting.

Everyone must be familiar with basic memory management. I will mainly talk about it here and not say much about the rest. The official document has this paragraph

- 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).

The general idea is that if you create an object using methods starting with alloc/new/copy/mutableCopy, then you will own the object (retain). When you don't need it, you need to release it manually.

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

We should use it like this. If we don't release it, the Object will be leaked.

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

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

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

Then the following questions arise:

A newObject method is implemented under MRR. This method follows the agreed principle and the return value will retain+1. Then, this method is called under ARC to create an object.

A newObject method is implemented under MRR. This method does not follow the convention principle and returns an autorelease object. Then, this method is called under ARC to create an object.

A newObject method is implemented under ARC, and then the newObject method is called under MRR to create an object and release it after use.

A newObject method is implemented under ARC, and then the newObject method is called under MRR to create an object, but there is no release after use.

We can write the above experimental code ourselves and then test it.

The final test results are as follows:

Scenarios 1 and 3 run normally

In scenario 2, the system will crash.

Memory leak occurs in scenario 4

Why does scenario 2 crash? This is because under ARC, if our compiler sees that you created an object with a method starting with alloc/new/copy/mutableCopy, it will insert a release operation at the beginning of the use. Since the object returned is an autorelease object, it is released again, resulting in a wild pointer.

The reason for the leak in scenario 4 is the same. When the compiler under ARC finds that the method starts with new, it will not insert a release statement at the end of the method. During the use of scenario 4, newObject is not released, so a leak will occur.

If we only use MRR or ARC, this problem will not occur. This problem usually occurs when ARC/MRR is mixed, due to some non-standard writing, so it is necessary to comply with the standards in the process of writing code.

If we write our own methods starting with alloc/new/copy/mutableCopy, we must not forget to return the retained object under MRR. Similarly, when we use alloc/new/copy/mutableCopy methods to create objects, we must not forget to release them after use.

If we have a piece of MRR code that provides a method starting with new but does not follow the specification, what should we do under ARC? According to the above conclusion, our normal use will definitely lead to wild pointers.

Here, if we can change the code, we will change it to comply with the standard. If we cannot change the source code, we can only modify the user. Here is a method:

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

You can try it and then think about why.

There is much more to iOS memory management than this. What is mentioned in this article is rarely encountered in the actual coding process. It is just a supplement to knowledge.