Http://www.cocoachina.com/ios/20170216/18689.html
IOS Memory mechanism features
The iphone device's RAM has been scarce, with the iphone generation only 128MB, up to 1GB at IPhone5, and 3GB in IPhone7 Plus. The StackOverflow provides the number of available memory on some IPhone models.
When there is less physical memory available, IOS sends a low-memory broadcast notification to each app and kills lower-priority processes if the available memory remains below a certain value thereafter.
The desktop operating system can replace temporarily unused physical memory on disk when physical memory is tight, and load it into memory again when needed. IOS does not have this mechanism because the flash memory of a mobile device is not as large as a PC, and frequent read and write Flash memory reduces its lifespan. The current scenario for IOS to be low-memory is to kill processes with lower priority.
Like most desktop operating systems, IOS also uses the virtual memory mechanism.
Virtual memory
The principles and pros and cons of virtual memory are no longer described here, which is where the IOS virtual memory mechanism is different.
Memory paging
IOS divides virtual memory into one page per 4KB, and not all of the page maps to physical memory. Each Page has three states:
Whether resident is a page state important identity, if the page is mapped into memory, the page is resident state, otherwise it is nonresident state;
Page that is loaded into memory based on the ReadOnly file is called clean memory, such as the system framework, executable files, files read through mmap, and so on. This Page is loaded from the immutable file, so it can be automatically unload by IOS when the physical memory is tight, and then re-loaded from the original file into memory when needed.
Any non-clean page is dirty, and their common feature is that the page does not have a corresponding file in the flash memory, such as through Alloc on the heap created on the storage space, has been decompressed images, database caches and so on. Dirty memory can not be swapped out by the operating system, only when the process is killed to be recycled, so when the system memory alarm, if the process creates a large number of dirty memory, then it will likely be killed.
Examples Show
As mentioned in the previous question, Malloc's memory is resident dirty, but in fact it is not, such as:
| 1 |
char *p = valloc(2 * 4096); |
In this case, two copies of 4096 bytes of memory are requested in the virtual memory, but because the application is not used, the operating system does not actually allocate the corresponding physical memory space for the memory space just requested, so the memory space is in the nonresident state at this time. If you assign a value to P[0]:
At this point p[0] will be loaded into physical memory, and thus become resident dirty state, similarly if the p[1] assignment is the same.
A file is loaded by means of the following mmap:
| 1 |
NSData *data = [NSData dataWithContentsOfMappedFile:file];char *p = (char *)[data bytes]; |
At this point the file is not being used, so it is only in virtual memory that the operating system does not map it to physics, so the state of the owning Page is nonresident. If you call the following code:
Because the p[0] portion of the file is used, the operating system loads the p[0] part into physical memory, and because p corresponds to a storage area that is a read-only file loaded mmap mode, p[0] corresponding Page is resident clean, and p[1] The state of the Page does not change because the part is still not being used.
What to do
For developers, to reduce the use of memory alarms by the system to kill, you should do the following:
It is possible to minimize the creation of dirty memory
Try to ensure that dirty memory is released immediately after it is exhausted.
Handle system memory alert notifications in a timely manner, freeing up memory-intensive and rebuilt objects
When memory alarms occur, the memory is no longer requested, and no larger block of memory can be requested
Reference documents
List of IOS devices
WWDC2010 Session 417:advanced Performance optimization on IPhone OS, part 2
WWDC2012 Session 242:ios App performance:memory
iOS Memory Quest