概念回顾

• px, dp, dpi
  px-像素；dp-密度无关像素(Density Independent Pixels)；dpi-像素密度(dots per inch)
  dpi=px/尺寸；160dpi为基准, 1dp=1px
• mdpi, hdpi, xdpi, xxdpi

密度	像素密度范围	缩放比例
ldpi	0dpi~120dpi	0.75
mdpi(基准)	120dpi~160dpi	1.0
hdpi	160dpi~240dpi	1.5
xhdpi	240dpi~320dpi	2.0
xxhdpi	320dpi~480dpi	3.0
xxxhdpi	480dpi~640dpi	4.0

• Bitmap格式

格式	占用位数/像素2	特点
ALPHA_8	1byte	只有alpha通道
RGB_565	2byte	红绿蓝分别占5,6,5bit
ARGB_4444	2byte	质量较低API 13后不建议使用
ARGB_8888	4byte	四个通道每个占8bit

---

切入正题

？如何计算资源图片占用的内存

什么？还要计算？难道不是图片本身的大小么？！
当然不是～
jpg格式也好，png格式也好，都是用 压缩算法 对图片进行压缩后的 存储格式 ，而在代码中将图片加载进内存，则相当于一个 解压 的过程，需要将图片还原为位图，所以需要根据bitmap图片格式和宽高(单位 px)进行计算：
bitmap图片占用内存大小=图片高度 * 图片宽度 * 每像素占用位数
以下图为例，套用上边的公式，占用内存=358*240*4=343680，离开压缩包撒了欢的 膨胀 膨胀 peng！

到底是不是这样呢？我们把图片放到hdpi目录下，调用API里的方法，验证一下

Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.mipmap.png1, options);
imageView.setImageBitmap(bitmap);
Log.i(TAG, "图片宽度：" + bitmap.getWidth() );
Log.i(TAG, "图片高度：" + bitmap.getHeight() );
Log.i(TAG, "图片占用内存：" + bitmap.getByteCount() );
Log.i(TAG, "bitmap使用的密度即存放路径对应密度：" + options.inDensity);
Log.i(TAG, "设备密度：" + options.inTargetDensity);

赶紧查看日志

怎么不一致 ？！

果然，图片占用内存的计算另有玄机！

别急，先从日志里边找线索。前边说到图片在hdpi目录下，对应像素密度240dpi，而设备对应的像素密度为480dpi，翻了一番，图片的宽高也扩大了一倍，像是进行了等比缩放

？难道图片占用内存的大小跟存放路径有关

追随源码，顺藤摸瓜。
这一把验证宽高缩放与像素密度的关系，别的部分暂且按下不表

public static Bitmap decodeResource(Resources res, int id, Options opts) {
        ... ...
        try {
            final TypedValue value = new TypedValue();
            is = res.openRawResource(id, value);
            // 解析图片流
            bm = decodeResourceStream(res, value, is, null, opts);
        } catch (Exception e) {
            ... ...
        } finally {
           ... ...
        }
          ... ...
        return bm;
    }

进入decodeResourceStream

public static Bitmap decodeResourceStream(@Nullable Resources res, @Nullable TypedValue value,
            @Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts) {
        validate(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);
    }

此处对option的使用密度和设备密度进行赋值，而后便进入看起来更为关键的decodeStream方法

public static Bitmap decodeStream(@Nullable InputStream is, @Nullable Rect outPadding,
            @Nullable Options opts) {
        ... ...
        try {
            if (is instanceof AssetManager.AssetInputStream) {
                final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();
                bm = nativeDecodeAsset(asset, outPadding, opts);
            } else {
                bm = decodeStreamInternal(is, outPadding, opts);
            }
        ... ...
        return bm;
    }

private static Bitmap decodeStreamInternal(@NonNull InputStream is,
            @Nullable Rect outPadding, @Nullable Options opts) {
        byte [] tempStorage = null;
        if (opts != null) tempStorage = opts.inTempStorage;
        if (tempStorage == null) tempStorage = new byte[DECODE_BUFFER_SIZE];
        return nativeDecodeStream(is, tempStorage, outPadding, opts);
    }

不得不进native，c++读起来确实有难度，又实在想看，紧(zhi)紧(kan)盯(de)住(dong)关键参数粗浅的验证一把思路吧！

static jobject nativeDecodeStream(JNIEnv* env, jobject clazz, jobject is, jbyteArray storage,
        jobject padding, jobject options) {

    jobject bitmap = NULL;
    std::unique_ptr<SkStream> stream(CreateJavaInputStreamAdaptor(env, is, storage));

    if (stream.get()) {
        std::unique_ptr<SkStreamRewindable> bufferedStream(
                SkFrontBufferedStream::Make(std::move(stream), SkCodec::MinBufferedBytesNeeded()));
        SkASSERT(bufferedStream.get() != NULL);
        bitmap = doDecode(env, std::move(bufferedStream), padding, options);
    }
    return bitmap;
}

找到bitmap和options，追随的步伐还需跟进

static jobject doDecode(JNIEnv* env, std::unique_ptr<SkStreamRewindable> stream,
                        jobject padding, jobject options) {
    int sampleSize = 1;
    bool onlyDecodeSize = false;
    ... ...
    float scale = 1.0f;
    ... ...
    if (options != NULL) {
        sampleSize = env->GetIntField(options, gOptions_sampleSizeFieldID);
        if (sampleSize <= 0) {
            sampleSize = 1;
        }

        if (env->GetBooleanField(options, gOptions_justBoundsFieldID)) {
            onlyDecodeSize = true;
        }
        ... ...
        if (env->GetBooleanField(options, gOptions_scaledFieldID)) {
            const int density = env->GetIntField(options, gOptions_densityFieldID);
            const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);
            const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
            if (density != 0 && targetDensity != 0 && density != screenDensity) {
                scale = (float) targetDensity / density;
            }
        }
    }
    ... ...

if (scale != 1.0f) {
        willScale = true;
        scaledWidth = static_cast<int>(scaledWidth * scale + 0.5f);
        scaledHeight = static_cast<int>(scaledHeight * scale + 0.5f);
    }
... ...

终于看到了关键的两行
scale = (float) targetDensity / density;
scaledWidth = static_cast<int>(scaledWidth * scale + 0.5f);
即 (int)内存中宽高=(float)图片本身宽高*设备密度/使用密度 + 0.5， 尤其注意0.5精度值
再往后就该把好不容易算出来的bitmap画出来了
那么？大功告成了？！再来实际验一把，实践是检验真理的唯一标准

把上边那张图放到不同dpi文件夹下验证数据

图片实际宽高：358*240；设备密度：480dpi

图片路径(使用密度)	展示宽高	占用内存
ldpi (120dpi)	1432 * 960	5498880B
mdpi (160dpi)	1074 * 720	3093120B
hdpi (240dpi)	716 * 480	1374720B
xhdpi (320dpi)	537 * 360	773280B
xxhdpi (480dpi)	358 * 240	343680B
xxxhdpi (640dpi)	269 * 180	193680B

符合公式推论，验证通过。

---

最后

• 图片占用内存的大小，与其自身大小并无关系，而与 图片格式 ， 设备密度 和 存放路径 息息相关
• 两个公式
  bitmap图片占用内存大小=图片高度 * 图片宽度 * 每像素占用位数
  (int)内存中宽高=(float)图片本身宽高*设备密度/使用密度 + 0.5

看来，切图还真不是随便就切，也更不能随手乱放的，否则内存占用可就成倍上涨， OOM 也要向我们招手了。
说到OOM，图片加载这么吃内存，有没有什么优化方案呢 ？ 刚刚源码中出现的sampleSize又有什么作用呢 ？

欲知后事如何，请听下回分解