概念回顾
- 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又有什么作用呢 ？
欲知后事如何，请听下回分解
网友评论