今天面试遇到同学说做过内存优化,于是我一般都会问那Bitmap的像素内存存在哪?大多数同学都回答在javaheap里面,就比较尴尬,理论上你做内存优化,如果连图片这个内存大户内存存在哪都不清楚,实在不太能说得过去。 Bitmap可以说是安卓里面最常见的内存消耗大户了,我们开发过程中遇到的oom问题很多都是由它引发的。谷歌官方也一直在迭代它的像素内存管理策略。从Android2。3。3以前的分配在native上,到2。37。1之间的分配在java堆上,又到8。0之后的回到native上。几度变迁,它的回收方法也在跟着变化。一、Android2。3。3以前 2。3。3以前Bitmap的像素内存是分配在natvie上,而且不确定什么时候会被回收。根据官方文档的说法我们需要手动调用Bitmap。recycle()去回收: https:developer。android。comtopicperformancegraphicsmanagememory 在Android2。3。3(API级别10)及更低版本上,位图的后备像素数据存储在本地内存中。它与存储在Dalvik堆中的位图本身是分开的。本地内存中的像素数据并不以可预测的方式释放,可能会导致应用短暂超出其内存限制并崩溃。 在Android2。3。3(API级别10)及更低版本上,建议使用recycle()。如果您在应用中显示大量位图数据,则可能会遇到OutOfMemoryError错误。利用recycle()方法,应用可以尽快回收内存。 注意:只有当您确定位图已不再使用时才应该使用recycle()。如果您调用recycle()并在稍后尝试绘制位图,则会收到错误:Canvas:tryingtousearecycledbitmap。二、Android3。0Android7。1 虽然3。07。1的版本Bitmp的像素内存是分配在java堆上的,但是实际是在natvie层进行decode的,而且会在native层创建一个c的对象和java层的Bitmap对象进行关联。 从BitmapFactory的源码我们可以看到它一路调用到nativeDecodeStream这个native方法:BitmapFactory。javapublicstaticBitmapdecodeFile(StringpathName,Optionsopts){。。。streamnewFileInputStream(pathName);bmdecodeStream(stream,null,opts);。。。}publicstaticBitmapdecodeStream(InputStreamis,RectoutPadding,Optionsopts){。。。bmdecodeStreamInternal(is,outPadding,opts);。。。}privatestaticBitmapdecodeStreamInternal(InputStreamis,RectoutPadding,Optionsopts){。。。returnnativeDecodeStream(is,tempStorage,outPadding,opts);} nativeDecodeStream实际上会通过jni创建java堆的内存,然后读取io流解码图片将像素数据存到这个java堆内存里面:BitmapFactory。cppstaticjobjectnativeDecodeStream(JNIEnvenv,jobjectclazz,jobjectis,jbyteArraystorage,jobjectpadding,jobjectoptions){。。。bitmapdoDecode(env,bufferedStream,padding,options);。。。}staticjobjectdoDecode(JNIEnvenv,SkStreamRewindablestream,jobjectpadding,jobjectoptions){。。。outputAllocator是像素内存的分配器,会在java堆上创建内存给像素数据,可以通过BitmapFactory。Options。inBitmap复用前一个bitmap像素内存SkBitmap::AllocatoroutputAllocator(javaBitmap!NULL)?(SkBitmap::Allocator)recyclingAllocator:(SkBitmap::Allocator)javaA。。。将内存分配器设置给解码器decodersetAllocator(outputAllocator);。。。解码if(decoderdecode(stream,decodingBitmap,prefColorType,decodeMode)!SkImageDecoder::kSuccess){returnnullObjectReturn(decoderdecodereturnedfalse);}。。。returnGraphicsJNI::createBitmap(env,javaAllocator。getStorageObjAndReset(),bitmapCreateFlags,ninePatchChunk,ninePatchInsets,1);}Graphics。cppjobjectGraphicsJNI::createBitmap(JNIEnvenv,android::Bitmapbitmap,intbitmapCreateFlags,jbyteArrayninePatchChunk,jobjectninePatchInsets,intdensity){java层的Bitmap对象实际上是natvie层new出来的native层也会创建一个android::Bitmap对象与java层的Bitmap对象绑定bitmapjavaByteArray()代码bitmap的像素数据其实是存在java层的byte数组中jobjectobjenvNewObject(gBitmapclass,gBitmapconstructorMethodID,reinterpretcastjlong(bitmap),bitmapjavaByteArray(),bitmapwidth(),bitmapheight(),density,isMutable,isPremultiplied,ninePatchChunk,ninePatchInsets);。。。} 我们可以看最后会调用javaAllocator。getStorageObjAndReset()创建一个android::Bitmap类型的native层Bitmap对象,然后通过jni调用java层的Bitmap构造函数去创建java层的Bitmap对象,同时将native层的Bitmap对象保存到mNativePtr:Bitmap。javaConvenienceforJNIaccessprivatefinallongmNativePPrivateconstructorthatmustreceivedanalreadyallocatednativebitmapint(pointer)。calledfromJNIBitmap(longnativeBitmap,byte〔〕buffer,intwidth,intheight,intdensity,booleanisMutable,booleanrequestPremultiplied,byte〔〕ninePatchChunk,NinePatch。InsetStructninePatchInsets){。。。mNativePtrnativeB。。。} 从上面的源码我们也能看出来,Bitmap的像素是存在java堆的,所以如果bitmap没有人使用了,垃圾回收器就能自动回收这块的内存,但是在native创建出来的nativeBitmap要怎么回收呢?从Bitmap的源码我们可以看到在Bitmap构造函数里面还会创建一个BitmapFinalizer去管理nativeBitmap:Privateconstructorthatmustreceivedanalreadyallocatednativebitmapint(pointer)。calledfromJNIBitmap(longnativeBitmap,byte〔〕buffer,intwidth,intheight,intdensity,booleanisMutable,booleanrequestPremultiplied,byte〔〕ninePatchChunk,NinePatch。InsetStructninePatchInsets){。。。mNativePtrnativeBmFinalizernewBitmapFinalizer(nativeBitmap);。。。} BitmapFinalizer的原理十分简单。Bitmap对象被销毁的时候BitmapFinalizer也会同步被销毁,然后就可以在BitmapFinalizer。finalize()里面销毁native层的nativeBitmap:privatestaticclassBitmapFinalizer{privatelongmNativeB。。。BitmapFinalizer(longnativeBitmap){mNativeBitmapnativeB}。。。Overridepublicvoidfinalize(){try{super。finalize();}catch(Throwablet){Ignore}finally{setNativeAllocationByteCount(0);nativeDestructor(mNativeBitmap);mNativeBitmap0;}}}三、Android8。0之后 8。0以后像素内存又被放回了native上,所以依然需要在java层的Bitmap对象回收之后同步回收native的内存。 虽然BitmapFinalizer同样可以实现,但是Java的finalize方法实际上是不推荐使用的,所以谷歌也换了NativeAllocationRegistry去实现:Privateconstructorthatmustreceivedanalreadyallocatednativebitmapint(pointer)。calledfromJNIBitmap(longnativeBitmap,intwidth,intheight,intdensity,booleanisMutable,booleanrequestPremultiplied,。。。mNativePtrnativeBlongnativeSizeNATIVEALLOCATIONSIZEgetAllocationByteCount();NativeAllocationRegistryregistrynewNativeAllocationRegistry(Bitmap。class。getClassLoader(),nativeGetNativeFinalizer(),nativeSize);registry。registerNativeAllocation(this,nativeBitmap);} NativeAllocationRegistry底层实际上使用了sun。misc。Cleaner,可以为对象注册一个清理的Runnable。当对象内存被回收的时候jvm就会调用它。importsun。misc。CpublicRunnableregisterNativeAllocation(Objectreferent,Allocatorallocator){。。。CleanerThunkthunknewCleanerThunk();CleanercleanerCleaner。create(referent,thunk);。。}privateclassCleanerThunkimplementsRunnable{。。。publicvoidrun(){if(nativePtr!0){applyFreeFunction(freeFunction,nativePtr);}registerNativeFree(size);}。。。} 这个Cleaner的原理也很暴力,首先它是一个虚引用,registerNativeAllocation实际上创建了一个Bitmap的虚引用:Cleaner。javapublicclassCleanerextendsPhantomReference{。。。publicstaticCleanercreate(Objectob,Runnablethunk){。。。returnadd(newCleaner(ob,thunk));}。。。privateCleaner(Objectreferent,Runnablethunk){super(referent,dummyQueue);this。}。。。publicvoidclean(){。。。thunk。run();。。。}。。。} 虚引用的话我们都知道需要配合一个ReferenceQueue使用,当对象的引用被回收的时候,jvm就会将这个虚引用丢到ReferenceQueue里面。而ReferenceQueue在插入的时候居然通过instanceof判断了下是不是Cleaner:ReferenceQueue。javaprivatebooleanenqueueLocked(R?extendsTr){。。。if(rinstanceofCleaner){Cleanercl(sun。misc。Cleaner)r;cl。clean();。。。}。。。} 也就是说Bitmap对象被回收,就会触发Cleaner这个虚引用被丢入ReferenceQueue,而ReferenceQueue里面会判断丢进来的虚引用是不是Cleaner,如果是就调用Cleaner。clean()方法。而clean方法内部就会再去执行我们注册的清理的Runnable。最后 在这里还分享一份由大佬亲自收录整理的学习PDF架构视频面试文档源码笔记,高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理,帮助大家在未来取得一份不错的答卷。 当然,你也可以拿去查漏补缺,提升自身的竞争力。 真心希望可以帮助到大家,Android路漫漫,共勉! 如果你有需要的话,只需私信我【进阶】即可获取