概念回顾
px, dp, dpi
px-像素；dp-密度无关像素(Density Independent Pixels)；dpi-像素密度(dots per inch)
dpi=px/尺寸；160dpi为基准, 1dp=1px；320dpi下，1dp=2pxmdpi, 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 | 特点 |
|---|---|---|
| ARGB_8888 | 4byte | 四个通道每个占8bit |
| RGB_565 | 2byte | 红绿蓝分别占5,6,5bit |
| ALPHA_8 | 1byte | 只有alpha通道 |
| ARGB_4444 | 2byte | 质量较低API 13后不建议使用 |
切入正题
？如何计算资源图片占用的内存
什么？还要计算？难道不是图片本身的大小么？！
当然不是～
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
| 图片路径(使用密度) | 展示宽高 | 占用内存 |
|---|---|---|
| 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
看来，切图还真不是随便就切，也更不能随手乱放的 ：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);
| 图片路径(使用密度) | 展示宽高 | ARGB_8888占用内存 | RGB_565占用内存 |
|---|---|---|---|
| ldpi (120dpi) | 1432 * 960 | 5498880B | 2749440B |
| mdpi (160dpi) | 1074 * 720 | 3093120B | 1546560B |
| hdpi (240dpi) | 716 * 480 | 1374720B | 687360B |
| xhdpi (320dpi) | 537 * 360 | 773280B | 386640B |
| xxhdpi (480dpi) | 358 * 240 | 343680B | 171840B |
| xxxhdpi (640dpi) | 269 * 180 | 193680B | 96840B |
内存占用确实少了一半，是个降低内存的辙
设置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)
作者：苹果tree
链接：https://www.jianshu.com/p/2507df56f235