Android中圖片占用內(nèi)存的深入分析
前言
Android 在加載圖片的時(shí)候一定會考慮到的一個(gè)點(diǎn)就是如何防止 OOM,那么一張圖片在加載的時(shí)候到底會占用多少內(nèi)存呢?有哪些因素會影響占用的內(nèi)存呢?知道了這些,我們才能知道可以從哪些點(diǎn)去優(yōu)化,從而避免 OOM。
一、圖片占用內(nèi)存與寬、高、色彩模式的關(guān)系
首先我們準(zhǔn)備一張 1920*1080 的圖片:

然后我使用的測試機(jī)是 Redmi Note 9 Pro,分辨率是 2400*1080,將這張圖片放到對應(yīng)分辨率的目錄下,也就是 drawable-xxhdpi 目錄下,然后使用不同的配置去加載圖片:
override fun initData() {
val options = BitmapFactory.Options()
val bitmap = BitmapFactory.decodeResource(resources, R.drawable.test_xxhdpi, options)
ShowLogUtil.info("width: ${options.outWidth},height: ${options.outHeight},config: ${options.inPreferredConfig},占用內(nèi)存: ${bitmap.allocationByteCount}")
options.inSampleSize = 2
val bitmap2 = BitmapFactory.decodeResource(resources, R.drawable.test_xxhdpi, options)
ShowLogUtil.info("width: ${options.outWidth},height: ${options.outHeight},config: ${options.inPreferredConfig},占用內(nèi)存: ${bitmap2.allocationByteCount}")
options.inPreferredConfig = Bitmap.Config.RGB_565
val bitmap3 = BitmapFactory.decodeResource(resources, R.drawable.test_xxhdpi, options)
ShowLogUtil.info("width: ${options.outWidth},height: ${options.outHeight},config: ${options.inPreferredConfig},占用內(nèi)存: ${bitmap3.allocationByteCount}")
}在上面的代碼中,第一次加載圖片時(shí)使用的是默認(rèn)配置,第二次加載圖片的時(shí)候修改了采樣率,采樣率必須設(shè)置為 2 的 n(n≥0) 次冪;第三次加載圖片的時(shí)候在修改采樣率的基礎(chǔ)上再修改了色彩模式。觀察 log:

可以看到第二次由于我們設(shè)置采樣率為 2,相當(dāng)于設(shè)置圖片壓縮比,然后加載時(shí)的寬和高都變成了第一次的 1/2,占用內(nèi)存為第一次的 1/4;第三次在第二次的基礎(chǔ)上再設(shè)置了色彩模式為 RGB_565,占用內(nèi)存為第二次的 1/2,第一次的 1/8。
其實(shí)還有其他的色彩模式,最后再解釋幾種色彩模式有什么區(qū)別,現(xiàn)在只需要知道 ARGB_8888 是 ARGB 分量都是 8 位,所以一個(gè)像素點(diǎn)占 32 位,也就是 4 字節(jié),它是最能保證圖片效果的一種模式。而 RGB_565 中 RGB 分量分別使用5位、6位、5位,沒有透明度,所以一個(gè)像素點(diǎn)占 16 位,也就是 2 字節(jié)。
那么我們可以簡單的看出,占位內(nèi)存是與加載寬高,與像素點(diǎn)大小成正比,且倍數(shù)關(guān)系,而且暫時(shí)認(rèn)為它們的關(guān)系為:
占用內(nèi)存=寬*高*像素點(diǎn)大小
二、圖片占用內(nèi)存與存放文件夾的關(guān)系
在日常開發(fā)中,UI 在切圖的時(shí)候通常會切不同分辨率的圖片,2 倍圖對應(yīng) Android 的 xhdpi 目錄,3 倍圖對應(yīng) Android 的 xxhdpi 目錄,那么為什么不同資源文件夾需要不同分辨率的圖片呢?只用一套圖片可不可以呢?我們來看看將同一張圖片放到不同目錄下,在加載的時(shí)候內(nèi)存占用情況分別如何。
我將上圖放在不同目錄下,分別命名為不同的名字:

這里圖片的分辨率都是一樣的,都是 1920*1080,只是放到了不同目錄下,然后我們再分別加載這三張圖片。
override fun initData() {
val options1 = BitmapFactory.Options()
val bitmap = BitmapFactory.decodeResource(resources, R.drawable.test_xxhdpi, options1)
ShowLogUtil.info(
"width: ${options1.outWidth},height: ${options1.outHeight},config: ${options1.inPreferredConfig},占用內(nèi)存: ${bitmap.allocationByteCount},inDensity: ${options1.inDensity},inTargetDensity: ${options1.inTargetDensity}"
)
val options2 = BitmapFactory.Options()
val bitmap2 = BitmapFactory.decodeResource(resources, R.drawable.test_xhdpi, options2)
ShowLogUtil.info(
"width: ${options2.outWidth},height: ${options2.outHeight},config: ${options2.inPreferredConfig},占用內(nèi)存: ${bitmap2.allocationByteCount},inDensity: ${options2.inDensity},inTargetDensity: ${options2.inTargetDensity}"
)
val options3 = BitmapFactory.Options()
val bitmap3 = BitmapFactory.decodeResource(resources, R.drawable.test_hdpi, options3)
ShowLogUtil.info(
"width: ${options3.outWidth},height: ${options3.outHeight},config: ${options3.inPreferredConfig},占用內(nèi)存: ${bitmap3.allocationByteCount},inDensity: ${options3.inDensity},inTargetDensity: ${options3.inTargetDensity}"
)
}在加載三張圖的時(shí)候分別傳入了一個(gè)默認(rèn)的 Options 對象,并在加載圖片完成后增加了 Options 的 inDensity 和 inTargetDensity 屬性的 log,觀察 log:

可以看到在加載 xhdpi 的圖片時(shí)內(nèi)存占用大于 xxhdpi 的內(nèi)存占用,為 xxhdpi 的 2.25 倍,在加載 hdpi 的圖片時(shí)內(nèi)存占用為 xxhdpi 的 4 倍,那這個(gè)倍數(shù)關(guān)系是怎么來的呢?別著急,一會兒通過源碼可以找到答案。
我們先修改一下圖片,將 xhdpi 目錄下的圖片分辨率改為 1280*720,hdpi 目錄下的圖片分辨率改為 960*540,再次運(yùn)行,觀察 log:

這時(shí)候我們發(fā)現(xiàn)加載不同分辨率下目錄的圖片的內(nèi)存占用都是一樣的了。
現(xiàn)在我們來查看一下 BitmapFactory.decodeResource() 方法的源碼了:
public static Bitmap decodeResource(Resources res, int id, Options opts) {
validate(opts);
Bitmap bm = null;
InputStream is = null;
try {
final TypedValue value = new TypedValue();
// 打開資源流,并初始化一些屬性。
is = res.openRawResource(id, value);
// 解析圖片資源。
bm = decodeResourceStream(res, value, is, null, opts);
} catch (Exception e) {
/* do nothing.
If the exception happened on open, bm will be null.
If it happened on close, bm is still valid.
*/
} finally {
try {
if (is != null) is.close();
} catch (IOException e) {
// Ignore
}
}
if (bm == null && opts != null && opts.inBitmap != null) {
throw new IllegalArgumentException("Problem decoding into existing bitmap");
}
return bm;
}decodeResource() 方法中 bitmap 對象是通過 decodeResourceStream() 方法去加載的,繼續(xù)查看 decodeResourceStream() 方法:
@Nullable
public static Bitmap decodeResourceStream(@Nullable Resources res, @Nullable TypedValue value,
@Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts) {
validate(opts);
// 檢查 Options 對象是否為空,為空則創(chuàng)建一個(gè)默認(rèn)對象。
if (opts == null) {
opts = new Options();
}
// 查看 Options 對象是否設(shè)置了 inDensity,這里是默認(rèn)的,所以沒有設(shè)置,TypedValue 對象在上面的 decodeResource() 方法中也是創(chuàng)建的一個(gè)默認(rèn)對象,所以不為 null,必然進(jìn)這個(gè) if 代碼塊。
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) {
// TypedValue 對象在上面的 decodeResource() 方法中調(diào)用 Resources.openRawResource() 方法的時(shí)候 density 會賦值成對應(yīng)的資源文件所在目錄的 density 值,所以會走到這里,給 Options 的 inDensity 屬性賦值。
opts.inDensity = density;
}
}
// Options 的 inTargetDensity 默認(rèn)沒有賦值,所以會進(jìn) if 代碼塊,賦值為手機(jī)屏幕的 densityDpi。
if (opts.inTargetDensity == 0 && res != null) {
opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
}
return decodeStream(is, pad, opts);
}該方法最后調(diào)用的是 decodeStream() 方法,繼續(xù)查看 decodeStream() 方法,這里我只解釋關(guān)鍵代碼,省略部分代碼:
@Nullable
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, Options.nativeInBitmap(opts),
Options.nativeColorSpace(opts));
} else {
// 這里的資源并非從 assets 目錄中加載,所以進(jìn)入 else 代碼塊。
bm = decodeStreamInternal(is, outPadding, opts);
}
...
} finally {
Trace.traceEnd(Trace.TRACE_TAG_GRAPHICS);
}
return bm;
}繼續(xù)查看 decodeStreamInternal() 方法:
private static Bitmap decodeStreamInternal(@NonNull InputStream is,
@Nullable Rect outPadding, @Nullable Options opts) {
// ASSERT(is != null);
byte [] tempStorage = null;
if (opts != null) tempStorage = opts.inTempStorage;
if (tempStorage == null) tempStorage = new byte[DECODE_BUFFER_SIZE];
return nativeDecodeStream(is, tempStorage, outPadding, opts,
Options.nativeInBitmap(opts),
Options.nativeColorSpace(opts));
}可以看到該方法中最終調(diào)用了 native 層中的 nativeDecodeStream() 方法,所以我們需要繼續(xù)追到 c++ 層,調(diào)用的是 /frameworks/base/core/jni/android/graphics/BitmapFactory.cpp,查看其 nativeDecodeStream 方法:
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;
}可以看到圖片的解碼是通過 doDecode() 方法完成,查看該方法,這里我只解釋關(guān)鍵代碼,省略部分代碼:
static jobject doDecode(JNIEnv* env, std::unique_ptr<SkStreamRewindable> stream,
jobject padding, jobject options) {
// Set default values for the options parameters.
...
// 初始化縮放比為 1.0
float scale = 1.0f;
...
if (options != NULL) {
...
// 獲取 java 中的 Options 對象中的 density,targetDensity,計(jì)算出縮放比,兩者都是在 java 代碼中的 decodeResourceStream() 方法賦值的。
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);
// 如加載的是 xhdpi 中的圖片則 inDensity 為 320,使用的測試機(jī)分辨率為 1920*1080,則 targetDensity 為 480,所以 scale 為 480/320=1.5
if (density != 0 && targetDensity != 0 && density != screenDensity) {
scale = (float) targetDensity / density;
}
}
}
...
int scaledWidth = size.width();
int scaledHeight = size.height();
...
// Scale is necessary due to density differences.
if (scale != 1.0f) {
// 需要縮放的話,計(jì)算縮放后的寬高。寬高分別乘以縮放比 scale。
willScale = true;
scaledWidth = static_cast<int>(scaledWidth * scale + 0.5f);
scaledHeight = static_cast<int>(scaledHeight * scale + 0.5f);
}
...
if (willScale) {
...
outputBitmap.setInfo(
bitmapInfo.makeWH(scaledWidth, scaledHeight).makeColorType(scaledColorType));
...
} else {
outputBitmap.swap(decodingBitmap);
}
...
// now create the java bitmap
return bitmap::createBitmap(env, defaultAllocator.getStorageObjAndReset(),
bitmapCreateFlags, ninePatchChunk, ninePatchInsets, -1);
}通過對源碼的簡單分析,我們可以得出的結(jié)論是,如果加載的圖片所處的分辨率與手機(jī)屏幕分辨率不一樣的話,會對圖片進(jìn)行縮放,寬高分別會乘以縮放比重新計(jì)算,所以它們的關(guān)系為:占用內(nèi)存=(寬*縮放比)*(高*縮放比)*像素點(diǎn)大小,即
占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小
這也就可以解釋為什么不同的資源目錄下需要不同分辨率的圖片了,主要是為了節(jié)省內(nèi)存。但是如果每一種分辨率都要去適配的話,那勢必會增加圖片,增加包體積,所以在做圖片適配的時(shí)候,要根據(jù)圖片使用頻率以及市場手機(jī)分辨率分布情況做好利弊權(quán)衡。
三、從文件中加載圖片和從網(wǎng)絡(luò)加載圖片占用內(nèi)存
這兩種加載圖片的方式的話,其實(shí)通過剛才的源碼分析,并不需要再通過實(shí)際運(yùn)行我們就可以知道,由于沒有設(shè)置 inDensity 和 inTargetDensity,所以占用內(nèi)存就是寬*高*像素點(diǎn)大小。由于它不會進(jìn)行縮放,所以我們在從文件中加載圖片和從網(wǎng)絡(luò)加載圖片的時(shí)候,尤其需要注意它的內(nèi)存占用情況,避免 OOM。
并且通過剛才的分析,我們可以知道除了可以設(shè)置 inSampleSize 來優(yōu)化占用內(nèi)存,也可以通過設(shè)置 inDensity 和 inTargetDensity 來通過縮放比間接地優(yōu)化占用內(nèi)存。
四、色彩模式
色彩模式在 Android 中主要有四種,介紹這個(gè)的文章很多,簡單提一下:
Bitmap.Config.ARGB_8888:ARGB 分量都是 8 位,總共占 32 位,還原度最高。
Bitmap.Config.ARGB_4444:ARGB 分量都是 4 位,總共占 16 位,保留透明度,但還原度較低。
Bitmap.Config.RGB_565:沒有透明度,RGB 分量分別占 5、6、5 位,總共占 16 位。
Bitmap.Config.ALPHA_8:只保留透明度,總共占 8 位。
這里重點(diǎn)不是為了介紹它們的區(qū)別,是要提一點(diǎn),并不是你設(shè)置了那個(gè)色彩模式就一定會按照這個(gè)色彩模式去加載,需要看圖片解碼器是否支持,比如我們?nèi)绻幸粋€(gè)灰度加載圖片的需求,那么這時(shí)候設(shè)置色彩模式為 Bitmap.Config.ALPHA_8 看起來是最簡單也最高效的方法,但實(shí)際可能并不是這樣,如果圖片解碼器不支持,那么還是會使用 Bitmap.Config.ARGB_8888 去加載,這里是一個(gè)坑,還希望出現(xiàn)這種情況的時(shí)候,小伙伴們能想到可能有這個(gè)原因。
附:inDensity,inTargetDensity,inScreenDensity, inScaled三者關(guān)系
通過追查代碼,我們可以看到圖片資源通過數(shù)據(jù)流解碼時(shí),會根據(jù)inDensity,inTargetDensity,inScreenDensity三個(gè)值和是否被縮放標(biāo)識inScaled
- inDensity:圖片本身的像素密度(其實(shí)就是圖片資源所在的哪個(gè)密度文件夾下,如在xxhdpi下就是480,如果在asstes、手機(jī)內(nèi)存/sd卡下,默認(rèn)是160);
- inTargetDensity:圖片最終在bitmap里的像素密度,如果沒有賦值,會將inTargetDensity設(shè)置成inScreenDensity;
- inScreenDensity:手機(jī)本身的屏幕密度,如我們測試的三星手機(jī)dpi=640, 如果inDensity與inTargetDensity不相等時(shí),就需要對圖片進(jìn)行縮放,inScaled = inTargetDensity/inDensity。
五、總結(jié)
1.圖片占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小,所以我們在優(yōu)化圖片占用內(nèi)存的時(shí)候主要考慮兩個(gè)方面:
1)控制圖像加載尺寸,這有兩種方式:
設(shè)置采樣率來控制加載的寬高;通過設(shè)置 inDensity 和 inTargetDensity 控制縮放比。
2)設(shè)置色彩模式來控制像素點(diǎn)大小,如果不需要透明度的圖片,可以設(shè)置色彩模式為 Bitmap.Config.RGB_565 直接減少一半內(nèi)存。
2.不同分辨率的文件夾下放不同分辨率的圖片是為了保證內(nèi)存開銷,但相應(yīng)的會增加包體積,所以需要根據(jù)實(shí)際情況權(quán)衡。
到此這篇關(guān)于Android中圖片占用內(nèi)存的文章就介紹到這了,更多相關(guān)Android圖片占用內(nèi)存內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Android PopupWindow被輸入法彈上去之后無法恢復(fù)原位的解決辦法
這篇文章主要介紹了Android PopupWindow被輸入法彈上去之后無法恢復(fù)原位的解決辦法,需要的朋友可以參考下2016-12-12
Android6.0獲取GPS定位和獲取位置權(quán)限和位置信息的方法
今天小編就為大家分享一篇Android6.0獲取GPS定位和獲取位置權(quán)限和位置信息的方法,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2018-07-07
android studio3.3.1代碼提示忽略大小寫的設(shè)置
這篇文章主要介紹了android studio3.3.1代碼提示忽略大小寫的設(shè)置,具有很好的參考價(jià)值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-03-03
Android樣式的開發(fā):layer-list實(shí)例詳解
本文主要介紹Android樣式開發(fā)layer-list,這里整理了詳細(xì)的資料,及簡單示例代碼有興趣的小伙伴可以參考下2016-09-09
Android實(shí)現(xiàn)密碼明密文切換(小眼睛)
這篇文章主要為大家詳細(xì)介紹了Android實(shí)現(xiàn)密碼明密文切換,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-08-08
android 上傳aar到私有maven服務(wù)器的示例
這篇文章主要介紹了android 上傳aar到私有maven服務(wù)器,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-11-11

