只malloc，不free，这种情况下Android6.0的内存增长如下：

Total内存750m，已经超过Nexus5 Android6.0 Dalvik虚拟机内存上限，但APP没有崩溃，可见native内存的增长并不会导致java虚拟机的OOM，在native层，oom的时机是到系统内存用尽的时候：

可见对于6.0的系统，一个APP也是能够耗尽系统所有内存的，下面来看下Bitmap内存分配原理，为什么8.0前后差别这么大。

Bitmap内存分配原理

8.0之前Bitmap内存分配原理

其实，通过Bitmap的成员列表，就能看出一点眉目，Bitmap中有个byte[] mBuffer，其实就是用来存储像素数据的，很明显它位于java heap中

public final class Bitmap implements Parcelable {    private static final String TAG = "Bitmap";     ...    private byte[] mBuffer;     ...    }

接下来，通过手动创建Bitmap，进行分析：Bitmap.java

public static Bitmap createBitmap(int width, int height, Config config) {    return createBitmap(width, height, config, true);}

Java层Bitmap的创建最终还是会走向native层：Bitmap.cpp

 static jobject Bitmap_creator(JNIEnv* env, jobject, jintArray jColors,                               jint offset, jint stride, jint width, jint height,                               jint configHandle, jboolean isMutable) {     SkColorType colorType = GraphicsJNI::legacyBitmapConfigToColorType(configHandle);      ...      SkBitmap Bitmap;     Bitmap.setInfo(SkImageInfo::Make(width, height, colorType, kPremul_SkAlphaType));             Bitmap* nativeBitmap = GraphicsJNI::allocateJavaPixelRef(env, &Bitmap, NULL);     if (!nativeBitmap) {         return NULL;     }      ...           jbyte* addr = (jbyte*) env->CallLongMethod(gVMRuntime, gVMRuntime_addressOf, arrayObj);     ...          android::Bitmap* wrapper = new android::Bitmap(env, arrayObj, (void*) addr,             info, rowBytes, ctable);     wrapper->getSkBitmap(Bitmap);     Bitmap->lockPixels();     return wrapper; }

这里只看关键点1，像素内存的分配：GraphicsJNI::allocateJavaPixelRef从这个函数名可以就可以看出，是在Java层分配，跟进去，也确实如此：

android::Bitmap* GraphicsJNI::allocateJavaPixelRef(JNIEnv* env, SkBitmap* bitmap,                                             SkColorTable* ctable) {    const SkImageInfo& info = bitmap->info();    if (info.fColorType == kUnknown_SkColorType) {        doThrowIAE(env, "unknown bitmap configuration");        return NULL;    }    size_t size;    if (!computeAllocationSize(*bitmap, &size)) {        return NULL;    }    // we must respect the rowBytes value already set on the bitmap instead of    // attempting to compute our own.    const size_t rowBytes = bitmap->rowBytes();       jbyteArray arrayObj = (jbyteArray) env->CallObjectMethod(gVMRuntime,                                                             gVMRuntime_newNonMovableArray,                                                             gByte_class, size);    if (env->ExceptionCheck() != 0) {        return NULL;    }    SkASSERT(arrayObj);    jbyte* addr = (jbyte*) env->CallLongMethod(gVMRuntime, gVMRuntime_addressOf, arrayObj);    if (env->ExceptionCheck() != 0) {        return NULL;    }    SkASSERT(addr);    android::Bitmap* wrapper = new android::Bitmap(env, arrayObj, (void*) addr,            info, rowBytes, ctable);    wrapper->getSkBitmap(bitmap);    // since we're already allocated, we lockPixels right away    // HeapAllocator behaves this way too    bitmap->lockPixels();    return wrapper;}

由于只关心内存分配，同样只看关键点1，这里其实就是在native层创建Java层byte[]，并将这个byte[]作为像素存储结构，之后再通过在native层构建Java Bitmap对象的方式，将生成的byte[]传递给Bitmap.java对象：

jobject GraphicsJNI::createBitmap(JNIEnv* env, android::Bitmap* bitmap,        int bitmapCreateFlags, jbyteArray ninePatchChunk, jobject ninePatchInsets,        int density) {    ...    jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID,            reinterpret_cast(bitmap), bitmap->javaByteArray(),            bitmap->width(), bitmap->height(), density, isMutable, isPremultiplied,            ninePatchChunk, ninePatchInsets);    hasException(env); // For the side effect of logging.    return obj;}

以上就是8.0之前的内存分配，其实4.4以及之前的更乱，下面再看下8.0之后的Bitmap是什么原理。

8.0之后Bitmap内存分配有什么新特点

其实从8.0的Bitmap.java类也能看出区别，之前的 private byte[] mBuffer成员不见了，取而代之的是private final long mNativePtr，也就说，Bitmap.java只剩下一个壳了，具体如下：

public final class Bitmap implements Parcelable {    ...    // Convenience for JNI access    private final long mNativePtr;    ... }

之前说过8.0之后的内存分配是在native，具体到代码是怎么样的表现呢？流程与8.0之前基本类似，区别在native分配时：

static jobject Bitmap_creator(JNIEnv* env, jobject, jintArray jColors,                              jint offset, jint stride, jint width, jint height,                              jint configHandle, jboolean isMutable,                              jfloatArray xyzD50, jobject transferParameters) {    SkColorType colorType = GraphicsJNI::legacyBitmapConfigToColorType(configHandle);     ...         sk_sp nativeBitmap = Bitmap::allocateHeapBitmap(&Bitmap);    if (!nativeBitmap) {        return NULL;    }    ...    return createBitmap(env, nativeBitmap.release(), getPremulBitmapCreateFlags(isMutable));}

看一下allocateHeapBitmap如何分配内存

static sk_sp allocateHeapBitmap(size_t size, const SkImageInfo& info, size_t rowBytes) {        void* addr = calloc(size, 1);    if (!addr) {        return nullptr;    }        return sk_sp(new Bitmap(addr, size, info, rowBytes));}

可以看出，8.0之后，Bitmap像素内存的分配是在native层直接调用calloc，所以其像素分配的是在native heap上， 这也是为什么8.0之后的Bitmap消耗内存可以无限增长，直到耗尽系统内存，也不会提示Java OOM的原因。

8.0之后的Bitmap内存回收机制

NativeAllocationRegistry是Android 8.0引入的一种辅助自动回收native内存的一种机制，当Java对象因为GC被回收后，NativeAllocationRegistry可以辅助回收Java对象所申请的native内存，拿Bitmap为例，入下：

Bitmap(long nativeBitmap, int width, int height, int density,        boolean isMutable, boolean requestPremultiplied,        byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {    ...    mNativePtr = nativeBitmap;    long nativeSize = NATIVE_ALLOCATION_SIZE + getAllocationByteCount();        NativeAllocationRegistry registry = new NativeAllocationRegistry(        Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);    registry.registerNativeAllocation(this, nativeBitmap);   if (ResourcesImpl.TRACE_FOR_DETAILED_PRELOAD) {        sPreloadTracingNumInstantiatedBitmaps++;        sPreloadTracingTotalBitmapsSize += nativeSize;    }}

当然这个功能也要Java虚拟机的支持，有机会再分析。

Android 4.4之前其实Bitmap也可在native（伪）分配内存

其实在Android5.0之前，Bitmap也是可以在native分配内存的，一个典型的例子就是Fresco，Fresco为了提高5.0之前图片处理的性能，就很有效的利用了这个特性，不过由于不太成熟，在5.0之后废弃，直到8.0重新拾起来（新方案），与这个特性有关的两个属性是BitmapFactory.Options中的inPurgeable与inInputShareable，具体的不在分析。过期技术，等于垃圾，有兴趣，可以自行分析。

         /**         * @deprecated As of {@link android.os.Build.VERSION_CODES#LOLLIPOP}, this is         * ignored.         *         * In {@link android.os.Build.VERSION_CODES#KITKAT} and below, if this         * is set to true, then the resulting bitmap will allocate its         * pixels such that they can be purged if the system needs to reclaim         * memory. In that instance, when the pixels need to be accessed again         * (e.g. the bitmap is drawn, getPixels() is called), they will be         * automatically re-decoded.         *         * 
For the re-decode to happen, the bitmap must have access to the         * encoded data, either by sharing a reference to the input         * or by making a copy of it. This distinction is controlled by         * inInputShareable. If this is true, then the bitmap may keep a shallow         * reference to the input. If this is false, then the bitmap will         * explicitly make a copy of the input data, and keep that. Even if         * sharing is allowed, the implementation may still decide to make a         * deep copy of the input data.
         *         * 
While inPurgeable can help avoid big Dalvik heap allocations (from         * API level 11 onward), it sacrifices performance predictability since any         * image that the view system tries to draw may incur a decode delay which         * can lead to dropped frames. Therefore, most apps should avoid using         * inPurgeable to allow for a fast and fluid UI. To minimize Dalvik heap         * allocations use the {@link #inBitmap} flag instead.
         *         * 
Note: This flag is ignored when used         * with {@link #decodeResource(Resources, int,         * android.graphics.BitmapFactory.Options)} or {@link #decodeFile(String,         * android.graphics.BitmapFactory.Options)}.
         */        @Deprecated        public boolean inPurgeable;        /**         * @deprecated As of {@link android.os.Build.VERSION_CODES#LOLLIPOP}, this is         * ignored.         *         * In {@link android.os.Build.VERSION_CODES#KITKAT} and below, this         * field works in conjuction with inPurgeable. If inPurgeable is false,         * then this field is ignored. If inPurgeable is true, then this field         * determines whether the bitmap can share a reference to the input         * data (inputstream, array, etc.) or if it must make a deep copy.         */        @Deprecated        public boolean inInputShareable;

总结

• 8.0之前的Bitmap像素数据基本存储在Java heap
• 8.0之后的 Bitmap像素数据基本存储在native heap
• 4.4可以通过inInputShareable、inPurgeable让Bitmap的内存在native层分配（已废弃）

作者：看书的小蜗牛
Android Bitmap变迁与原理解析（4.x-8.x）

仅供参考，欢迎指正

更多相关文章

1. 【我的Android进阶之旅】使用Android(安卓)Studio 3.6 的 Androi
2. 你不得不了解的JVM（一）
3. android 内存使用详情查询的几种方法
4. Android提高十六篇之使用NDK把彩图转换灰度图
5. Android(安卓)Binder 分析——匿名共享内存（Ashmem）
6. Android的几种分辨率
7. Android(安卓)使用View Gone 与 ViewStub的区别
8. Android进程内存查看
9. Android中px、dp和sp区别

随机推荐

1. mysql优化之like和=性能详析
2. 详解MySQL 重做日志（redo log）与回滚日志（un
3. MySQL 常用的拼接语句汇总
4. MySQL Truncate用法详解
5. MySQL20个高性能架构设计原则（值得收藏）
6. 全面解读MySQL主从复制，从原理到安装配置
7. mysql中关于覆盖索引的知识点总结
8. mysql实现不用密码登录的实例方法
9. 聊聊MySQL中的存储引擎
10. 教你如何6秒钟往MySQL插入100万条数据的