Android转换位图BUG，知其然不知其所以然

　　最近，在开发某App的时候，发现了一个很奇怪的bug，前面我也发了关于bitmap的总结，但是这个问题恰恰出在BitmapFactory.decodeFile(pathName)这个函数上，使用这个函数在我的应用中如果设置在activity的onCreate方法内部，会导致activity无法加载，返回上级activity。

　　网上描述的大多数原因是OutOfMemoryError，但我catch不到这个error，所以可以肯定不是内存溢出引起的错误。为什么解码图像会出现这样的问题呢？关于这个问题，我纠结了一段时间。

由于调用decodeFile与decodeStream基本相似，中间过程中会引用一个设置bitmap比例的函数外最终都会调用BitmapFactory.decodeStream(is, outPadding, opts)，先看一下他们的转码流程，下面这段解码分析参考的是别人一篇oom文章的：

 

　　上图是整个decodeStream实现bitmap转码的流程，最终的决定权其实是在Init.c中，因为Android在启动系统的时候会去优先执行这个里面的函数，通过调用dvmStartup()方法来初始化虚拟机，最终调用到会调用到HeapSource.c中的dvmHeapSourceStartup()方法，而在Init.c中有这么两句代码：

 

gDvm.heapSizeStart = 2 * 1024 * 1024;   // Spec says 16MB; too big for us.

gDvm.heapSizeMax = 16 * 1024 * 1024;    // Spec says 75% physical mem

 

 

在另外一个地方也有类似的代码，那就是AndroidRuntime.cpp中的startVM()方法中：

 

strcpy(heapsizeOptsBuf, "-Xmx");

property_get("dalvik.vm.heapsize", heapsizeOptsBuf+4, "16m");

//LOGI("Heap size: %s", heapsizeOptsBuf);

opt.optionString = heapsizeOptsBuf;

 

 

 

同样也是默认值为16M，虽然目前我看到了两个可以启动VM的方法，具体Android何时会调用这两个初始化VM的方法，还不是很清楚。不过可以肯定的一点就是，如果启动DVM时未指定参数，那么其初始化堆最大大小应该就是16M，那么我们在网上查到了诸多关于解码图像超过8M就会出错的论断是如何得出来的呢？

我们来看看HeapSource.c中的这个方法的注释：

 

/*

* External allocation tracking

*

* In some situations, memory outside of the heap is tied to the

* lifetime of objects in the heap.  Since that memory is kept alive

* by heap objects, it should provide memory pressure that can influence

* GCs.

*/

static bool

externalAllocPossible(const HeapSource *hs, size_t n)

{

    const Heap *heap;

    size_t currentHeapSize;

   /* Make sure that this allocation is even possible.

     * Don’t let the external size plus the actual heap size

     * go over the absolute max.  This essentially treats

     * external allocations as part of the active heap.

     *

     * Note that this will fail "mysteriously" if there’s

     * a small softLimit but a large heap footprint.

     */

    heap = hs2heap(hs);

    currentHeapSize = mspace_max_allowed_footprint(heap->msp);

    if (currentHeapSize + hs->externalBytesAllocated + n <=

            heap->absoluteMaxSize)

    {

        return true;

    }

    HSTRACE("externalAllocPossible(): "

            "footprint %zu + extAlloc %zu + n %zu >= max %zu (space for %zu)\n",

            currentHeapSize, hs->externalBytesAllocated, n,

            heap->absoluteMaxSize,

            heap->absoluteMaxSize -

                    (currentHeapSize + hs->externalBytesAllocated));

    return false;

}

 

 

 

标为红色的注释的意思应该是说，为了确保我们外部分配内存成功，我们应该保证当前已分配的内存加上当前需要分配的内存值，大小不能超过当前堆的最大内存值，而且内存管理上将外部内存完全当成了当前堆的一部分。也许我们可以这样理解，Bitmap对象通过栈上的引用来指向堆上的Bitmap对象，而Bitmap对象又对应了一个使用了外部存储的native图像，实际上使用的是byte[]来存储的内存空间，如下图：

 

 

当然我们承认不好的程序总是程序员自己错误的写法导致的 ，不过我们倒是非常想知道如何来规避这个问题，那么接下来就是解答这个问题的关键。

今天无意中看到stackoverflow上有人也曾经遇到过这个问题，而这个给了一个很好的解决方案，但他也不知道这个BUG该怎么解释：

I had this same issue and solved it by avoiding the BitmapFactory.decodeStream or decodeFile functions and instead used BitmapFactory.decodeFileDescriptor

decodeFileDescriptor looks like it calls different native methods than the decodeStream/decodeFile.

Anyway what worked was this (note that I added some options as some had above, but that's not what made the difference. What is critical is the call to Bitmap.decodeFileDescriptor instead of decodeStream or decodeFile):

 

private void showImage(String path)   {
    Log.i("showImage","loading:"+path);
    BitmapFactory.Options bfOptions=new BitmapFactory.Options();
    bfOptions.inDither=false;                     
    bfOptions.inPurgeable=true;                 
    bfOptions.inInputShareable=true;             
    bfOptions.inTempStorage=new byte[32 * 1024]; 


    File file=new File(path);
    FileInputStream fs=null;
    try {
        fs = new FileInputStream(file);
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    }

    try {
        if(fs!=null) bm=BitmapFactory.decodeFileDescriptor(fs.getFD(), null, bfOptions);
    } catch (IOException e) {
        e.printStackTrace();
    } finally{ 
        if(fs!=null) {
            try {
                fs.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    im.setImageBitmap(bm);
    bm=null;
}

 

 

 

I think there is a problem with the native function used in decodeStream/decodeFile. I have confirmed that a different native method is called when using decodeFileDescriptor. Also what I've read is "that Images (Bitmaps) are not allocated in a standard Java way but via native calls; the allocations are done outside of the virtual heap, but are counted against it!"

我拙劣的翻译了一下：

我遇到了同样的问题，通过规避BitmapFactory.decodeStream或者decodeFile函数，使用BitmapFactory.decodeFileDescriptor解决的，decodeFileDescriptor相比decodeStream/decodeFile来说，看起来它调用了不同的本地方法。无论如何，它是这样工作的（注意，像上边的一样，我增加了一些设置，但那不是使这个不同的地方。）关键的就是它调用Bitmap.decodeFileDescriptor而不是decodeStream or decodeFile)。

我想这可能是decodeStream/decodeFile中本地函数的问题。我很确定当使用decodeFileDescriptor时一个不同的本地方法被调用。我读到的也是“图片（Bitmaps）并不是指派给一个标准的java路径，但是是通过本地调用的；这个分配是在虚拟的堆外完成的，但是是被认为针对它的！”。

 

还是点到为止吧，大家都应该明白我的题目的意思了，最主要的是这个错误没办法去验证究竟什么地方发生了错误，但是可以规避这种错误，希望大家都自己去测试一下，验证一下，毕竟自己做过验证的才能算是放心的。

 

参考资料：http://www.cnblogs.com/-OYK/archive/2012/12/03/2798903.html