Android中圖片占用內(nèi)存的深入分析
前言
Android 在加載圖片的時候一定會考慮到的一個點(diǎn)就是如何防止 OOM,那么一張圖片在加載的時候到底會占用多少內(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}")
}在上面的代碼中,第一次加載圖片時使用的是默認(rèn)配置,第二次加載圖片的時候修改了采樣率,采樣率必須設(shè)置為 2 的 n(n≥0) 次冪;第三次加載圖片的時候在修改采樣率的基礎(chǔ)上再修改了色彩模式。觀察 log:

可以看到第二次由于我們設(shè)置采樣率為 2,相當(dāng)于設(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 位,所以一個像素點(diǎn)占 32 位,也就是 4 字節(jié),它是最能保證圖片效果的一種模式。而 RGB_565 中 RGB 分量分別使用5位、6位、5位,沒有透明度,所以一個像素點(diǎn)占 16 位,也就是 2 字節(jié)。
那么我們可以簡單的看出,占位內(nèi)存是與加載寬高,與像素點(diǎn)大小成正比,且倍數(shù)關(guān)系,而且暫時認(rèn)為它們的關(guān)系為:
占用內(nèi)存=寬*高*像素點(diǎn)大小
二、圖片占用內(nèi)存與存放文件夾的關(guān)系
在日常開發(fā)中,UI 在切圖的時候通常會切不同分辨率的圖片,2 倍圖對應(yīng) Android 的 xhdpi 目錄,3 倍圖對應(yīng) Android 的 xxhdpi 目錄,那么為什么不同資源文件夾需要不同分辨率的圖片呢?只用一套圖片可不可以呢?我們來看看將同一張圖片放到不同目錄下,在加載的時候內(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}"
)
}在加載三張圖的時候分別傳入了一個默認(rèn)的 Options 對象,并在加載圖片完成后增加了 Options 的 inDensity 和 inTargetDensity 屬性的 log,觀察 log:

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

這時候我們發(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)建一個默認(rèn)對象。
if (opts == null) {
opts = new Options();
}
// 查看 Options 對象是否設(shè)置了 inDensity,這里是默認(rèn)的,所以沒有設(shè)置,TypedValue 對象在上面的 decodeResource() 方法中也是創(chuàng)建的一個默認(rèn)對象,所以不為 null,必然進(jìn)這個 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() 方法的時候 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,計算出縮放比,兩者都是在 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) {
// 需要縮放的話,計算縮放后的寬高。寬高分別乘以縮放比 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)行縮放,寬高分別會乘以縮放比重新計算,所以它們的關(guān)系為:占用內(nèi)存=(寬*縮放比)*(高*縮放比)*像素點(diǎn)大小,即
占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小
這也就可以解釋為什么不同的資源目錄下需要不同分辨率的圖片了,主要是為了節(jié)省內(nèi)存。但是如果每一種分辨率都要去適配的話,那勢必會增加圖片,增加包體積,所以在做圖片適配的時候,要根據(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ò)加載圖片的時候,尤其需要注意它的內(nèi)存占用情況,避免 OOM。
并且通過剛才的分析,我們可以知道除了可以設(shè)置 inSampleSize 來優(yōu)化占用內(nèi)存,也可以通過設(shè)置 inDensity 和 inTargetDensity 來通過縮放比間接地優(yōu)化占用內(nèi)存。
四、色彩模式
色彩模式在 Android 中主要有四種,介紹這個的文章很多,簡單提一下:
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è)置了那個色彩模式就一定會按照這個色彩模式去加載,需要看圖片解碼器是否支持,比如我們?nèi)绻幸粋€灰度加載圖片的需求,那么這時候設(shè)置色彩模式為 Bitmap.Config.ALPHA_8 看起來是最簡單也最高效的方法,但實(shí)際可能并不是這樣,如果圖片解碼器不支持,那么還是會使用 Bitmap.Config.ARGB_8888 去加載,這里是一個坑,還希望出現(xiàn)這種情況的時候,小伙伴們能想到可能有這個原因。
附:inDensity,inTargetDensity,inScreenDensity, inScaled三者關(guān)系
通過追查代碼,我們可以看到圖片資源通過數(shù)據(jù)流解碼時,會根據(jù)inDensity,inTargetDensity,inScreenDensity三個值和是否被縮放標(biāo)識inScaled
- inDensity:圖片本身的像素密度(其實(shí)就是圖片資源所在的哪個密度文件夾下,如在xxhdpi下就是480,如果在asstes、手機(jī)內(nèi)存/sd卡下,默認(rèn)是160);
- inTargetDensity:圖片最終在bitmap里的像素密度,如果沒有賦值,會將inTargetDensity設(shè)置成inScreenDensity;
- inScreenDensity:手機(jī)本身的屏幕密度,如我們測試的三星手機(jī)dpi=640, 如果inDensity與inTargetDensity不相等時,就需要對圖片進(jìn)行縮放,inScaled = inTargetDensity/inDensity。
五、總結(jié)
1.圖片占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小,所以我們在優(yōu)化圖片占用內(nèi)存的時候主要考慮兩個方面:
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實(shí)現(xiàn)一個倒計時自定義控件
大家好,本篇文章主要講的是Android實(shí)現(xiàn)一個倒計時自定義控件,感興趣的同學(xué)趕快來看一看吧,對你有幫助的話記得收藏一下2022-02-02
android中NFC讀寫功能的實(shí)現(xiàn)方法
這篇文章主要為大家詳細(xì)介紹了android中NFC讀寫功能的實(shí)現(xiàn)方法,文中示例代碼介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們可以參考一下2021-09-09
Android編程之電池電量信息更新的方法(基于BatteryService實(shí)現(xiàn))
這篇文章主要介紹了Android編程之電池電量信息更新的方法,主要基于BatteryService實(shí)現(xiàn)該功能,以實(shí)例形式分析了Android獲取電池電量的具體步驟與實(shí)現(xiàn)技巧,需要的朋友可以參考下2015-11-11
Android自定義SeekBar實(shí)現(xiàn)視頻播放進(jìn)度條
這篇文章主要為大家詳細(xì)介紹了Android自定義SeekBar實(shí)現(xiàn)視頻播放進(jìn)度條的相關(guān)資料,文中示例代碼介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-03-03
Android實(shí)現(xiàn)短信驗(yàn)證碼自動填寫
這篇文章主要為大家詳細(xì)介紹了Android短信驗(yàn)證碼自動填寫功能的實(shí)現(xiàn)過程,感興趣的小伙伴們可以參考一下2016-08-08
Android?adb?shell?dumpsys?audio?信息查看分析詳解
文章詳細(xì)介紹了如何使用dumpsysaudio命令查看和分析Android設(shè)備的音頻信息,包括音頻流狀態(tài)、音量、外設(shè)連接情況等,文章還提供了示例日志分析和源碼鏈接,幫助開發(fā)者更好地理解和調(diào)試Android音頻系統(tǒng)2024-11-11
Android使用PullToRefresh實(shí)現(xiàn)上拉加載和下拉刷新效果的代碼
這篇文章主要介紹了Android使用PullToRefresh實(shí)現(xiàn)上拉加載和下拉刷新效果 的相關(guān)資料,需要的朋友可以參考下2016-07-07
使用RecylerView完成拖動排序高仿qq側(cè)滑刪除功能
最近在做一個android項(xiàng)目,使用到Recylerview完成拖動排序,側(cè)滑刪除功能,今天小編把思路分享到腳本之家平臺,供大家學(xué)習(xí)2016-10-10
Android Flutter實(shí)現(xiàn)圖片滑動切換效果
Flutter 為了簡化開發(fā),提供了不少轉(zhuǎn)換動畫組件,這類組件通常命名為 xxTransition。本篇要介紹的就是 SlideTransition,并用它實(shí)現(xiàn)圖片滑動切換效果,感興趣的可以了解一下2022-04-04

