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