概念回顾

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

• Bitmap格式

切入正题

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

什么？还要计算？难道不是图片本身的大小么？！
当然不是～
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)关键参数粗浅的验证一把思路吧！
进入BitmapFactory.cpp

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；图片格式 ARGB_8888

符合公式推论，验证通过。
可见在密度相同的设备上，随存放路径不同，图片实际占用的内存竟如此悬殊，真真差在来起跑线上

划一下重点

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

看来，切图还真不是随便就切，也更不能随手乱放的 ：160dpi 对应1dp=1px；320dpi 对应1dp=2px ，由此生成不同大小的图片并放到对应dpi文件夹下即可完美呈现，若放错了地方，内存占用很可能成倍上涨， OOM 也要向我们招手了。

说到OOM，加载图片这么吃内存，有没有优化良方呢 ？ 刚刚源码中出现的sampleSize又有什么作用呢 ？

如何让图片吃少吃好

首当其冲的——根据尺寸放到对应dpi文件夹

前文提及到不再赘述，这里补充一点。
因为现在多数手机像素密度为320dpi和480dpi，所以考虑到安装包大小等因素，很多项目只对xhdpi和xxhdpi提供切图

使用不同的图片格式

目前用的较多的有 ARGB_8888 和 RGB_565，占位分别为4B和2B
两种格式的主要差别在于RGB_565不支持透明通道且三个色值有所损失清晰度略低，但人家占位少啊！
还是用之前那张图片，拿这货验证一下格式改为 RGB_565 后的变化

bitmap = Bitmap.createBitmap(bpWidth, bpHeight, Bitmap.Config.RGB_565);

内存占用确实少了一半，是个降低内存的辙

设置inSampleSize

Options参数inSampleSize指定Bitmap原始宽高的缩小倍数
掏出源码 BitmapFactory.cpp

if (needsFineScale(codec->getInfo().dimensions(), size, sampleSize)) {
        willScale = true;
        scaledWidth = codec->getInfo().width() / sampleSize;
        scaledHeight = codec->getInfo().height() / sampleSize;
    }
... ...
if (scale != 1.0f) {
        willScale = true;
        scaledWidth = static_cast<int>(scaledWidth * scale + 0.5f);
        scaledHeight = static_cast<int>(scaledHeight * scale + 0.5f);
    }

我们可以设置bitmapFactoryOptions.inJustDecodeBounds = true(decodeFile并不分配空间只是读取图片尺寸和内存信息)根据图片实际需要显示的大小算出缩小比例，再行加载

及时回收

比如亲手改造你的 ImageView
在onDetachedFromWindow() 和 onStartTemporaryDetach() 回调里回收图片的ImageView setImageDrawable(null)

最后

看来图片这个内存大户的内心远比他的外表复杂啊，用起来可得多加小心。不过俗话说 “方法总比困难多” 相信人类的智慧，努把劲还是能搞定它的。