This article is transferred from the network, the original address
Memory usage is critical during iPhone development. Not only should we allocate and use the memory reasonably, but we should also pay attention to the memory leakage problem, because the memory leakage will cause the program to crash due to insufficient memory. According to my personal development experience, when developing the iPhone program, pay attention to the following aspects about memory:
- Memory Allocation and release appear in pairs
The memory objects allocated with alloc need to be called to release the release after use.
- Note the differences between the copy, retain, and assign operators.
The objects assigned by the copy and retain operators are the same as those assigned by alloc and must be release. Otherwise, memory leakage may occur.
The assign operator points an object to another object. The two point to the same memory object and do not need to call release for release.
- Nsarray, nsdictionary, nsmutablearray, nsmutabledictionary, and other container classes. When using these container classes, note that when adding objects to these class objects, the container class automatically calls a retain. For example
Nsstring * string = [[nsstring alloc] initwithstring: @ "test string"]; // refcount = 1
Nsarray * array = [nsarray array];
[Array addobject: String]; // refcount = 2
[String release]; // refcount = 1
In this case, even if the string has called release, but the retain has been called once when the array is added, pay attention to the changes in refcount to briefly introduce the Object Management Mechanism of iPhone or Objective C. OC uses a reference counting refcount method to manage memory objects. When refcount is equal to 0, the memory occupied by objects will be released, operators alloc, copy, retain adds refcount to 1 to indicate that the reference count is increased, and call release to reduce refcount to 1 automatically. When refcount = 0, it indicates that the object has not been referenced and can be released, then the object is unavailable.
- It is best to create your own automatic release pool (NSAID utoreleasepool) in the process of continuous and repetitive memory allocation, usually in loop operations such as for and while, for example
For (INT I = 0; I <100; I ++)
{
Nsstring * STR = [[nsstring alloc] initwithstring: @ "some string"];
// STR operations
[STR release];
}
In this case, there are two points to note: first, if possible, place the allocation and release of STR outside the for loop to reduce the memory allocation and release, leading to low program efficiency, it is also conducive to memory recovery. The above example should be
Nsstring * STR = [[nsstring alloc] initwithstring: @ "some string"];
For (INT I = 0; I <100; I ++)
{
// STR operations
}
[STR release];
If the actual situation is complex and you cannot exit the loop as in the example, you need to create your own memory management pool. This is also suitable for the process that requires a large number of autorelease objects.
NSAID utoreleasepool * Pool = [[NSAID utoreleasepool alloc] init];
For (INT I = 0; I <100; I ++)
{
// Actions
}
[Pool release];
This is because Apple handles the memory management mechanism of the iPhone. Generally, the system releases all the autorelease objects as needed, this is why sometimes the autorelease object may be valid out of scope.
- To avoid memory resident of infrequently used objects, many TX desktop developers like to load some resources such as small images into the memory during program initialization, thus improving program running efficiency. However, this method needs to be avoided when developing iPhone and other mobile devices, because the memory is always insufficient for these devices (of course, the larger the normal PC memory, the better :)). According to Apple's official statement, load resources lazily. is to read data from the hard disk as needed, instead of resident memory.
