Bitmap的生成流程之BitmapFactory.decodeResource VS BitmapFactory.decodeStream

最新推荐文章于 2025-09-12 08:00:00 发布

原创最新推荐文章于 2025-09-12 08:00:00 发布 · 2.8w 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#android #resources #null #优化 #测试

Android 专栏收录该内容

60 篇文章

订阅专栏

本文通过一张时序图直观展示了Bitmap的内存管理过程，并详细解释了使用BitmapFactory.decodeResource与decodeStream的不同之处，旨在帮助开发者避免内存溢出（OOM）问题，通过对比分析与实践案例，提供有效内存优化策略。

BitmapFactory.decodeResource和BitmapFactory.decodeStream，相信对于有过android app开发经验的人来说都是很熟悉了。关于Bitmap的OOM问题，网上也有很多文章进行了分析，不少文章都说为避免OOM，最好使用BitmapFactory.decodeStream，但是具体说明原因的我至今没有找到，所以趁着10.1期间有空，就调查了一番，希望结果对大家能有帮助。

先来张时序图，看了这张图，估计很多问题都不用说明了：

下面做些说明：

1，函数externalBytesAvailable(...)的内存计算方法详细请参见文章《Android Bitmap内存限制》；

2，Bitmap.createScaledBitmap时可能会对Bitmap进行缩放，缩放所使用的Options请参见下面这段代码：

    public static Bitmap decodeResourceStream(Resources res, TypedValue value,
            InputStream is, Rect pad, Options opts) {

        if (opts == null) {
            opts = new Options();
        }

        if (opts.inDensity == 0 && value != null) {
            final int density = value.density;
            if (density == TypedValue.DENSITY_DEFAULT) {
                opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
            } else if (density != TypedValue.DENSITY_NONE) {
                opts.inDensity = density;
            }
        }
        
        if (opts.inTargetDensity == 0 && res != null) {
            opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
        }
        
        return decodeStream(is, pad, opts);
    }

当放大时，会加大造成OOM的可能性；
3，BitmapFactory.decodeResource比起BitmapFactory.decodeStream来说，在没有参数Options opts的情况下，确实是多占用了内存，因为多了BitmapFactory.finishDecode这一步，这里多了一个Bitmap.createScaledBitmap操作；

4，关于使用BitmapFactory.decodeResource和BitmapFactory.decodeStream的效率对比，大家可以参见文章《Android 内存优化测试》

5，关于文章《Android 内存优化测试》提到的使用BitmapDrawable是最节省内存的方法，原因是frameworks\base\core\java\android\content\res\Resources.java对Bitmap做了缓存处理，文中所有的array其实都是指向同一个Bitmap，这一点也可以通过Bitmap.toString的输出信息来证明。