Android 3.0以后，Bitmap的内存默认在Java堆上申请，而优于虚拟机的限制，Java堆大小是受限的。
申请超过堆最大内存，会引发OOM；重复在堆上申请内存，会引发频繁的GC，GC会带来额外的系统开销，一些情况下的GC会锁定非GC线程从而引发UI卡顿。
关于Bitmap的内存位置，逻辑在BitmapFactory的jni实现中，具体代码在frameworks/base/core/jni/graphics/BitmapFactory.cpp，doDecode()函数。
下面以4.4源码分析：
这里的逻辑由于可以直接传入kDecodeBounds_Mode类型的mode，以及isPurgeable，变得相对复杂：
- isPurgeable == true：这种情况就是在Ashmem上申请Bitmap内存的模式了
- 传入mode == kDecodeBounds_Mode：这种情况实际上并不会真正解码出Bitmap，而只是给出Bitmap的信息
对应的Java参数是BitmapFactory.Options的
根据是否decodeMode是否为kDecodeBounds_Mode，给SkImageDecoder设置不同的Allocator。
-
true，不设置Allocator，此时SkImageDecoder的Allocator为NULL
这里可以分为两方面解释：
a、对于传入mode是kDecodeBounds_Mode的情况，本身并不会解码出Bitmap，所以不需要Allocator；
b、对于isPurgeable == true，内存将在AshMemory上申请
对于内存的分析，仅针对isPurgeable==true的情况：- 由于decodeMode==kDecodeBounds_Mode的情况，decoder的decode并没有真正alloc，而是提前返回了true
-
在获取最终输出的outputBitmap的SkPixelRef时，purgeable的解码操作才被处理
Paste_Image.png
SkPixelRef的类型是SkImageRef_ashmem
Paste_Image.png在SkImageRef的prepareBitmap函数中，真正处理的解码
Paste_Image.png传入的Allocator是AshmemAllocator
Paste_Image.png由此产生的Bitmap内存分布在Ashmem上面
-
false，此处分为几种情况
-
需要对Bitmap进行scale，并且javaBitmap != NULL，使用了ScaleCheckingAllocator
Paste_Image.png
当需要解码的Bitmap，经过scale后，尺寸大于了inBitmap，在解码时会返回false。否则，将申请一块nativeHeap用于存放临时的bitmap。
而后，将解码出来的decodingBitmap，通过canvas画在输出的outputBitmap上面去。
Paste_Image.png-
不需要scale，javaBitmap != NULL
javaBitmap就是复用的inBitmap，不为NULL时，这里使用了RecyclingPixelAllocator
Paste_Image.png
对应的allocPixelRef其实并没有真正的alloc内存，而是将javaBitmap的SkPixelRef取出交给新的Bitmap使用
-
不需要scale，javaBitmap == NULL
此时Allocator是JavaPixelAllocator，其allocPixelRef就是从Java虚拟机中申请内存。
Paste_Image.png
Paste_Image.png
-
总结一下：BitmapFactory根据isPurgeable、inBitmap、scale的属性，使用了以下类型的Allocator：
- JavaPixelAllocator，在Java堆分配Pixels内存，默认情况都使用这个
- RecyclingPixerAllocator，对于有inBitmap复用的情况，使用这个Allocator，本质是将inBitmap的PixelRef赋值给解码的Bitmap
- AshmemAllocator，对于设置了isPurgeable的情况，使用这个Allocator，本质是在Ashmem上分配Pixels内存。
- ScaleCheckingAllocator，这是针对设置了scale，并且设置了inBitmap的情况，目的是先做校验，校验通过则申请临时的native堆内存存放临时Bitmap，再将临时Bitmap绘制在最后的outBitmap上面去。
