作为Android开发，这个知识点一定要知道，官方也改了 2 次~

Posted 2022-01-12 River_ly

今天面试遇到同学说做过内存优化，于是我一般都会问那 Bitmap 的像素内存存在哪？大多数同学都回答在 java heap 里面，就比较尴尬，理论上你做内存优化，如果连图片这个内存大户内存存在哪都不清楚，实在不太能说得过去。

Bitmap可以说是安卓里面最常见的内存消耗大户了，我们开发过程中遇到的oom问题很多都是由它引发的。谷歌官方也一直在迭代它的像素内存管理策略。从 android 2.3.3以前的分配在native上，到2.3-7.1之间的分配在java堆上，又到8.0之后的回到native上。几度变迁，它的回收方法也在跟着变化。

一、Android 2.3.3以前

2.3.3以前Bitmap的像素内存是分配在natvie上，而且不确定什么时候会被回收。根据官方文档的说法我们需要手动调用Bitmap.recycle()去回收:

https://developer.android.com/topic/performance/graphics/manage-memory

在 Android 2.3.3（API 级别 10）及更低版本上，位图的后备像素数据存储在本地内存中。它与存储在 Dalvik 堆中的位图本身是分开的。本地内存中的像素数据并不以可预测的方式释放，可能会导致应用短暂超出其内存限制并崩溃。

在 Android 2.3.3（API 级别 10）及更低版本上，建议使用 recycle()。如果您在应用中显示大量位图数据，则可能会遇到 OutOfMemoryError 错误。利用recycle() 方法，应用可以尽快回收内存。

注意：只有当您确定位图已不再使用时才应该使用 recycle()。如果您调用recycle() 并在稍后尝试绘制位图，则会收到错误：“Canvas: trying to use a recycled bitmap”。

二、Android 3.0~Android 7.1

虽然3.0~7.1的版本Bitmp的像素内存是分配在java堆上的，但是实际是在natvie层进行decode的，而且会在native层创建一个c++的对象和java层的Bitmap对象进行关联。

从BitmapFactory的源码我们可以看到它一路调用到nativeDecodeStream这个native方法:

// BitmapFactory.java
public static Bitmap decodeFile(String pathName, Options opts) 
    ...
    stream = new FileInputStream(pathName);
    bm = decodeStream(stream, null, opts);
    ...
    return bm;


public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) 
    ...
    bm = decodeStreamInternal(is, outPadding, opts);
    ...
    return bm;


private static Bitmap decodeStreamInternal(InputStream is, Rect outPadding, Options opts) 
    ...
    return nativeDecodeStream(is, tempStorage, outPadding, opts);

nativeDecodeStream实际上会通过jni创建java堆的内存,然后读取io流解码图片将像素数据存到这个java堆内存里面:

// BitmapFactory.cpp
static jobject nativeDecodeStream(JNIEnv* env, jobject clazz, jobject is, jbyteArray storage,
        jobject padding, jobject options) 
    ...
    bitmap = doDecode(env, bufferedStream, padding, options);
    ...
    return bitmap;


static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding, jobject options) 
    ...
    // outputAllocator是像素内存的分配器,会在java堆上创建内存给像素数据,可以通过BitmapFactory.Options.inBitmap复用前一个bitmap像素内存
    SkBitmap::Allocator* outputAllocator = (javaBitmap != NULL) ?
            (SkBitmap::Allocator*)&recyclingAllocator : (SkBitmap::Allocator*)&javaAllocator;
    ...
    // 将内存分配器设置给解码器
    decoder->setAllocator(outputAllocator);
    ...
    //解码
    if (decoder->decode(stream, &decodingBitmap, prefColorType, decodeMode)
                != SkImageDecoder::kSuccess) 
        return nullObjectReturn("decoder->decode returned false");
    
    ...
    return GraphicsJNI::createBitmap(env, javaAllocator.getStorageObjAndReset(),
            bitmapCreateFlags, ninePatchChunk, ninePatchInsets, -1);


// Graphics.cpp
jobject GraphicsJNI::createBitmap(JNIEnv* env, android::Bitmap* bitmap,
        int bitmapCreateFlags, jbyteArray ninePatchChunk, jobject ninePatchInsets,
        int density) 

    // java层的Bitmap对象实际上是natvie层new出来的
    // native层也会创建一个android::Bitmap对象与java层的Bitmap对象绑定
    // bitmap->javaByteArray()代码bitmap的像素数据其实是存在java层的byte数组中
    jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID,
            reinterpret_cast<jlong>(bitmap), bitmap->javaByteArray(),
            bitmap->width(), bitmap->height(), density, isMutable, isPremultiplied,
            ninePatchChunk, ninePatchInsets);
    ...
    return obj;

我们可以看最后会调用javaAllocator.getStorageObjAndReset()创建一个android::Bitmap类型的native层Bitmap对象，然后通过jni调用java层的Bitmap构造函数去创建java层的Bitmap对象，同时将native层的Bitmap对象保存到mNativePtr:

// Bitmap.java
// Convenience for JNI access
private final long mNativePtr;

/**
 * Private constructor that must received an already allocated native bitmap
 * int (pointer).
 */
// called from JNI
Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density,
        boolean isMutable, boolean requestPremultiplied,
        byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) 
    ...
    mNativePtr = nativeBitmap;
    ...

从上面的源码我们也能看出来，Bitmap的像素是存在java堆的，所以如果bitmap没有人使用了，垃圾回收器就能自动回收这块的内存，但是在native创建出来的nativeBitmap要怎么回收呢？从Bitmap的源码我们可以看到在Bitmap构造函数里面还会创建一个BitmapFinalizer去管理nativeBitmap:

/**
 * Private constructor that must received an already allocated native bitmap
 * int (pointer).
 */
// called from JNI
Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density,
        boolean isMutable, boolean requestPremultiplied,
        byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) 
    ...
    mNativePtr = nativeBitmap;
    mFinalizer = new BitmapFinalizer(nativeBitmap);
    ...

BitmapFinalizer的原理十分简单。Bitmap对象被销毁的时候BitmapFinalizer也会同步被销毁，然后就可以在BitmapFinalizer.finalize()里面销毁native层的nativeBitmap:

private static class BitmapFinalizer 
    private long mNativeBitmap;
    ...
    BitmapFinalizer(long nativeBitmap) 
        mNativeBitmap = nativeBitmap;
    
    ...
    @Override
    public void finalize() 
        try 
            super.finalize();
         catch (Throwable t) 
            // Ignore
         finally 
            setNativeAllocationByteCount(0);
            nativeDestructor(mNativeBitmap);
            mNativeBitmap = 0;
        
    

三、Android 8.0之后

8.0以后像素内存又被放回了native上，所以依然需要在java层的Bitmap对象回收之后同步回收native的内存。

虽然BitmapFinalizer同样可以实现，但是Java的finalize方法实际上是不推荐使用的，所以谷歌也换了NativeAllocationRegistry去实现:

/**
 * Private constructor that must received an already allocated native bitmap
 * int (pointer).
 */
// called from JNI
Bitmap(long nativeBitmap, int width, int height, int density,
        boolean isMutable, boolean requestPremultiplied,
    ...
    mNativePtr = nativeBitmap;
    long nativeSize = NATIVE_ALLOCATION_SIZE + getAllocationByteCount();
    NativeAllocationRegistry registry = new NativeAllocationRegistry(
        Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);
    registry.registerNativeAllocation(this, nativeBitmap);

NativeAllocationRegistry底层实际上使用了sun.misc.Cleaner,可以为对象注册一个清理的Runnable。当对象内存被回收的时候jvm就会调用它。

import sun.misc.Cleaner;

public Runnable registerNativeAllocation(Object referent, Allocator allocator) 
    ...
    CleanerThunk thunk = new CleanerThunk();
    Cleaner cleaner = Cleaner.create(referent, thunk);
    ..


private class CleanerThunk implements Runnable 
    ...
    public void run() 
        if (nativePtr != 0) 
            applyFreeFunction(freeFunction, nativePtr);
        
        registerNativeFree(size);
    
    ...

这个Cleaner的原理也很暴力,首先它是一个虚引用,registerNativeAllocation实际上创建了一个Bitmap的虚引用:

// Cleaner.java
public class Cleaner extends PhantomReference 
    ...
    public static Cleaner create(Object ob, Runnable thunk) 
        ...
        return add(new Cleaner(ob, thunk));
    
    ...
    private Cleaner(Object referent, Runnable thunk) 
        super(referent, dummyQueue);
        this.thunk = thunk;
    
    ...
    public void clean() 
        ...
        thunk.run();
        ...
    
    ...

虚引用的话我们都知道需要配合一个ReferenceQueue使用，当对象的引用被回收的时候，jvm就会将这个虚引用丢到ReferenceQueue里面。而ReferenceQueue在插入的时候居然通过instanceof判断了下是不是Cleaner:

// ReferenceQueue.java
private boolean enqueueLocked(Reference<? extends T> r) 
    ...
    if (r instanceof Cleaner) 
        Cleaner cl = (sun.misc.Cleaner) r;
        cl.clean();
        ...
    
    ...

也就是说Bitmap对象被回收,就会触发Cleaner这个虚引用被丢入ReferenceQueue，而ReferenceQueue里面会判断丢进来的虚引用是不是Cleaner，如果是就调用Cleaner.clean()方法。而clean方法内部就会再去执行我们注册的清理的Runnable。

最后

前段时间收集整理了Android高工必备技能知识脑图和核心知识点笔记文档！既能够夯实底层原理核心技术点，又能够掌握普通开发者，难以触及的架构设计方法论。那你在工作中、团队里、面试时，也就拥有了同行难以复制的核心竞争力。

相关的一些知识点解析都已经做了收录整理上传至公号中：Android开发之家，大家可以自行访问查阅。