Android中圖片占用內(nèi)存的深入分析
前言
Android 在加載圖片的時(shí)候一定會(huì)考慮到的一個(gè)點(diǎn)就是如何防止 OOM,那么一張圖片在加載的時(shí)候到底會(huì)占用多少內(nèi)存呢?有哪些因素會(huì)影響占用的內(nèi)存呢?知道了這些,我們才能知道可以從哪些點(diǎn)去優(yōu)化,從而避免 OOM。
一、圖片占用內(nèi)存與寬、高、色彩模式的關(guān)系
首先我們準(zhǔn)備一張 1920*1080 的圖片:
然后我使用的測(cè)試機(jī)是 Redmi Note 9 Pro,分辨率是 2400*1080,將這張圖片放到對(duì)應(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:
可以看到第二次由于我們?cè)O(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位,沒(méi)有透明度,所以一個(gè)像素點(diǎn)占 16 位,也就是 2 字節(jié)。
那么我們可以簡(jiǎn)單的看出,占位內(nèi)存是與加載寬高,與像素點(diǎn)大小成正比,且倍數(shù)關(guān)系,而且暫時(shí)認(rèn)為它們的關(guān)系為:
占用內(nèi)存=寬*高*像素點(diǎn)大小
二、圖片占用內(nèi)存與存放文件夾的關(guān)系
在日常開(kāi)發(fā)中,UI 在切圖的時(shí)候通常會(huì)切不同分辨率的圖片,2 倍圖對(duì)應(yīng) Android 的 xhdpi 目錄,3 倍圖對(duì)應(yīng) Android 的 xxhdpi 目錄,那么為什么不同資源文件夾需要不同分辨率的圖片呢?只用一套圖片可不可以呢?我們來(lái)看看將同一張圖片放到不同目錄下,在加載的時(shí)候內(nèi)存占用情況分別如何。
我將上圖放在不同目錄下,分別命名為不同的名字:
這里圖片的分辨率都是一樣的,都是 1920*1080,只是放到了不同目錄下,然后我們?cè)俜謩e加載這三張圖片。
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 對(duì)象,并在加載圖片完成后增加了 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)系是怎么來(lái)的呢?別著急,一會(huì)兒通過(guò)源碼可以找到答案。
我們先修改一下圖片,將 xhdpi 目錄下的圖片分辨率改為 1280*720,hdpi 目錄下的圖片分辨率改為 960*540,再次運(yùn)行,觀察 log:
這時(shí)候我們發(fā)現(xiàn)加載不同分辨率下目錄的圖片的內(nèi)存占用都是一樣的了。
現(xiàn)在我們來(lái)查看一下 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(); // 打開(kāi)資源流,并初始化一些屬性。 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 對(duì)象是通過(guò) 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 對(duì)象是否為空,為空則創(chuàng)建一個(gè)默認(rèn)對(duì)象。 if (opts == null) { opts = new Options(); } // 查看 Options 對(duì)象是否設(shè)置了 inDensity,這里是默認(rèn)的,所以沒(méi)有設(shè)置,TypedValue 對(duì)象在上面的 decodeResource() 方法中也是創(chuàng)建的一個(gè)默認(rèn)對(duì)象,所以不為 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 對(duì)象在上面的 decodeResource() 方法中調(diào)用 Resources.openRawResource() 方法的時(shí)候 density 會(huì)賦值成對(duì)應(yīng)的資源文件所在目錄的 density 值,所以會(huì)走到這里,給 Options 的 inDensity 屬性賦值。 opts.inDensity = density; } } // Options 的 inTargetDensity 默認(rèn)沒(méi)有賦值,所以會(huì)進(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; }
可以看到圖片的解碼是通過(guò) 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 對(duì)象中的 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,使用的測(cè)試機(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); }
通過(guò)對(duì)源碼的簡(jiǎn)單分析,我們可以得出的結(jié)論是,如果加載的圖片所處的分辨率與手機(jī)屏幕分辨率不一樣的話,會(huì)對(duì)圖片進(jìn)行縮放,寬高分別會(huì)乘以縮放比重新計(jì)算,所以它們的關(guān)系為:占用內(nèi)存=(寬*縮放比)*(高*縮放比)*像素點(diǎn)大小,即
占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小
這也就可以解釋為什么不同的資源目錄下需要不同分辨率的圖片了,主要是為了節(jié)省內(nèi)存。但是如果每一種分辨率都要去適配的話,那勢(shì)必會(huì)增加圖片,增加包體積,所以在做圖片適配的時(shí)候,要根據(jù)圖片使用頻率以及市場(chǎng)手機(jī)分辨率分布情況做好利弊權(quán)衡。
三、從文件中加載圖片和從網(wǎng)絡(luò)加載圖片占用內(nèi)存
這兩種加載圖片的方式的話,其實(shí)通過(guò)剛才的源碼分析,并不需要再通過(guò)實(shí)際運(yùn)行我們就可以知道,由于沒(méi)有設(shè)置 inDensity 和 inTargetDensity,所以占用內(nèi)存就是寬*高*像素點(diǎn)大小。由于它不會(huì)進(jìn)行縮放,所以我們?cè)趶奈募屑虞d圖片和從網(wǎng)絡(luò)加載圖片的時(shí)候,尤其需要注意它的內(nèi)存占用情況,避免 OOM。
并且通過(guò)剛才的分析,我們可以知道除了可以設(shè)置 inSampleSize 來(lái)優(yōu)化占用內(nèi)存,也可以通過(guò)設(shè)置 inDensity 和 inTargetDensity 來(lái)通過(guò)縮放比間接地優(yōu)化占用內(nèi)存。
四、色彩模式
色彩模式在 Android 中主要有四種,介紹這個(gè)的文章很多,簡(jiǎn)單提一下:
Bitmap.Config.ARGB_8888:ARGB 分量都是 8 位,總共占 32 位,還原度最高。
Bitmap.Config.ARGB_4444:ARGB 分量都是 4 位,總共占 16 位,保留透明度,但還原度較低。
Bitmap.Config.RGB_565:沒(méi)有透明度,RGB 分量分別占 5、6、5 位,總共占 16 位。
Bitmap.Config.ALPHA_8:只保留透明度,總共占 8 位。
這里重點(diǎn)不是為了介紹它們的區(qū)別,是要提一點(diǎn),并不是你設(shè)置了那個(gè)色彩模式就一定會(huì)按照這個(gè)色彩模式去加載,需要看圖片解碼器是否支持,比如我們?nèi)绻幸粋€(gè)灰度加載圖片的需求,那么這時(shí)候設(shè)置色彩模式為 Bitmap.Config.ALPHA_8 看起來(lái)是最簡(jiǎn)單也最高效的方法,但實(shí)際可能并不是這樣,如果圖片解碼器不支持,那么還是會(huì)使用 Bitmap.Config.ARGB_8888 去加載,這里是一個(gè)坑,還希望出現(xiàn)這種情況的時(shí)候,小伙伴們能想到可能有這個(gè)原因。
附:inDensity,inTargetDensity,inScreenDensity, inScaled三者關(guān)系
通過(guò)追查代碼,我們可以看到圖片資源通過(guò)數(shù)據(jù)流解碼時(shí),會(huì)根據(jù)inDensity,inTargetDensity,inScreenDensity三個(gè)值和是否被縮放標(biāo)識(shí)inScaled
- inDensity:圖片本身的像素密度(其實(shí)就是圖片資源所在的哪個(gè)密度文件夾下,如在xxhdpi下就是480,如果在asstes、手機(jī)內(nèi)存/sd卡下,默認(rèn)是160);
- inTargetDensity:圖片最終在bitmap里的像素密度,如果沒(méi)有賦值,會(huì)將inTargetDensity設(shè)置成inScreenDensity;
- inScreenDensity:手機(jī)本身的屏幕密度,如我們測(cè)試的三星手機(jī)dpi=640, 如果inDensity與inTargetDensity不相等時(shí),就需要對(duì)圖片進(jìn)行縮放,inScaled = inTargetDensity/inDensity。
五、總結(jié)
1.圖片占用內(nèi)存=寬*高*(手機(jī)屏幕密度/資源文件夾密度)²*像素點(diǎn)大小,所以我們?cè)趦?yōu)化圖片占用內(nèi)存的時(shí)候主要考慮兩個(gè)方面:
1)控制圖像加載尺寸,這有兩種方式:
設(shè)置采樣率來(lái)控制加載的寬高;通過(guò)設(shè)置 inDensity 和 inTargetDensity 控制縮放比。
2)設(shè)置色彩模式來(lái)控制像素點(diǎn)大小,如果不需要透明度的圖片,可以設(shè)置色彩模式為 Bitmap.Config.RGB_565 直接減少一半內(nèi)存。
2.不同分辨率的文件夾下放不同分辨率的圖片是為了保證內(nèi)存開(kāi)銷,但相應(yīng)的會(huì)增加包體積,所以需要根據(jù)實(shí)際情況權(quán)衡。
到此這篇關(guān)于Android中圖片占用內(nèi)存的文章就介紹到這了,更多相關(guān)Android圖片占用內(nèi)存內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Android動(dòng)畫實(shí)現(xiàn)原理和代碼
這篇文章主要介紹了Android動(dòng)畫實(shí)現(xiàn)原理和代碼分析,如果你對(duì)此感興趣,跟著小編學(xué)習(xí)下吧。2017-12-12Android PopupWindow被輸入法彈上去之后無(wú)法恢復(fù)原位的解決辦法
這篇文章主要介紹了Android PopupWindow被輸入法彈上去之后無(wú)法恢復(fù)原位的解決辦法,需要的朋友可以參考下2016-12-12Android6.0獲取GPS定位和獲取位置權(quán)限和位置信息的方法
今天小編就為大家分享一篇Android6.0獲取GPS定位和獲取位置權(quán)限和位置信息的方法,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2018-07-07android studio3.3.1代碼提示忽略大小寫的設(shè)置
這篇文章主要介紹了android studio3.3.1代碼提示忽略大小寫的設(shè)置,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2020-03-03Android樣式的開(kāi)發(fā):layer-list實(shí)例詳解
本文主要介紹Android樣式開(kāi)發(fā)layer-list,這里整理了詳細(xì)的資料,及簡(jiǎn)單示例代碼有興趣的小伙伴可以參考下2016-09-09Android實(shí)現(xiàn)密碼明密文切換(小眼睛)
這篇文章主要為大家詳細(xì)介紹了Android實(shí)現(xiàn)密碼明密文切換,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-08-08android 上傳aar到私有maven服務(wù)器的示例
這篇文章主要介紹了android 上傳aar到私有maven服務(wù)器,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2017-11-11