android Bitmap does not have recycle(), resulting in a surge in native memory
After android8.0, Bitmap is transferred from the Java layer to the native layer. Although this move relieves the memory pressure of the JVM and improves the loading speed of graphics, inappropriate Bitmap allocation/release logic will cause memory problems to be hidden deep in the native layer. layer, more concealed and difficult to locate.
After the Bitmap is loaded into "memory", it will be divided into two parts. The first part is the Bitmap description information, and the second part (the largest part) is the Bitmap pixel (byte array). The first part contains Java memory, and the second part contains native memory maintained by C/C++. The recycle() function of Bitmap releases the native memory of C/C++. If there is no recycle(), the GC may only recycle part of the java memory, and the native memory of C/C++ is still occupied. Solution: After the upper-level java code uses Bitmap, it needs to actively and manually recycle the Bitmap, and the recycling code:
if (mBitmap != null) {
mBitmap.recycle();
mBitmap = null;
}