How can I "steal" Android memory ?, 「 Steal 」 android

How can I "steal" Android memory ?, 「 Steal 」 android

Previously, MemoryFile was used for memory optimization, which found some features of MemoryFile and a very trickly usage method. Therefore, record it here.

What is it

MemoryFile is a framework introduced by android at the very beginning. It actually encapsulates the Memory Sharing Mechanism unique to android, ashmem is registered as a special character device in the Android kernel. The Ashmem driver initializes a memory area in a custom slab buffer in the kernel, then, map the applied memory to the user's process space (through tmpfs) through mmap, so that the applied memory can be used in the user process. In addition, one feature of Ashmem is to recycle the memory marked as "unpin" when the system memory is insufficient, memoryFile can also be called by Binder to allow two processes to share a memory area. Since the entire memory application process is no longer on the Java layer, it is obvious that the memory applied for using MemoryFile does not actually occupy the Java heap memory.

The User Interface exposed by MemoryFile can be said to be the same as its name. It is basically the same as the reading and writing of our files. You can also use InputStream and OutputStream to read and write the files:

1234	MemoryFile memoryFile = new MemoryFile (null, inputStream. available (); memoryFile. allowPurging (false); OutputStream outputStream = memoryFile. getOutputStream (); outputStream. write (1024 );

We can see the call of allowPurging. This is the "pin" and "unpin" mentioned earlier. After setting allowPurging to false, the Ashmem corresponding to this MemoryFile will be marked as "pin", so this memory will not be recycled even if the android system memory is insufficient. In addition, because the default values of Ashmem are "unpin", the application may be recycled at a certain time point, and cannot be read or written at this time.

Tricks

MemoryFile is a very trickly thing. Because it does not occupy the Java heap memory, we can save some objects with MemoryFile to avoid GC. In addition, there may be a BUG on android:

In systems above 4.4, if MemoryFile is used in the application, an additional Ashmem value is displayed during dumpsys meminfo:

It can be seen that although the memory applied for by the MemoryFile is neither included in the Java heap nor in the Native heap, it occupies the Ashmem memory, which is actually included in the memory occupied by the app.

However, the memory applied for using the MemoryFile is not included in the app's memory when the memory is less than 4.4:

In addition, I have calculated it here and it is not included in Native Heap. In addition, when I go to the system settings to check the memory usage of the process, it can also be seen that it is not actually included in the Ashmem memory.

This should be a BUG in android, but I found it and didn't find the corresponding issue. If it doesn't work, it may also be a feature.

In the well-known Fresco, they also used this bug to avoid reading the file byte into the Java heap during decode bitmap and using MemoryFile, this BUG is also used. However, this part of memory is not included in the app. Here, it corresponds to GingerbreadPurgeableDecoder and KitKatPurgeableDecoder in Fresco respectively, fresco uses the two different decoder in the decode Image System of 4.4 and below 4.4 respectively.

From this point, we can see that using MemoryFile can help our app "steal" some memory in systems lower than 4.4, and it can be excluded from the app memory.

Summary

This section briefly introduces the basic principles and usage of MemoryFile, and describes a place in MemoryFile that can help developers "steal" memory. This is a very trickly method, although less than 4.4 of the memory is not included in the process, it is not recommended to use it in large quantities, because when allowPurging is set to false, the corresponding Ashmem memory area is "pin", so when the android system memory is insufficient, this memory area cannot be recycled. If it is not released for a long time, this is equivalent to the absence of terminals occupying a large amount of mobile phone memory and cannot be recycled, it will certainly affect the system stability

 

Q: one-click call to programmer Q & A artifacts, one-to-one service, developer programming required official website: www.wenaaa.com

QQ Group 290551701 has gathered many Internet elites, Technical Directors, architects, and project managers! Open-source technology research, welcome to the industry, Daniel and beginners interested in IT industry personnel!