android内存机制
16lz
2021-12-04
android内存回收
Since it seems a lot of misinformation is being spread in this ticket, I wanted to try and address a few things that might help people before they are led down the wrong path.
First, you must understand a few things about bitmaps and the garbage collector. A bitmap (as of 2.x and earlier), has memory in both the Dalvik and native heap (with the majority of it stored on the native side). The garbage collector is only capable of freeing memory in the Dalvik heap. Native memory for each bitmap is freed using a finalizer.
The exact steps in dalvik to collect a bitmap is as follows:
1) A bitmap becomes eligible for garbage collection
2) The GC eventually runs and sees that the object requires finalization
3) The bitmap is placed onto the finalizer queue
4) The finalizer eventually runs and native memory is freed (at this point, most of the memory you assigned to the bitmap is freed)
5) The GC eventually runs again and the bitmap is removed from the Dalvik heap. This "remainder" object is relatively small when compared to the previously in-use native memory
There are a few things you should understand about finalizers. The following is some data I extracted from http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.50%2Fhtml%2Fmm_gc_coexist.html
Finalizers:
Are not run in any particular sequence
Are not run at any particular time
Are not guaranteed to run at all
Will run asynchronously to the Garbage Collector
So lets talk about what does happen when you try to allocate a bitmap and there is no memory available:
1) A bitmap or large chunk of memory tries to be allocated
2) The JVM realizes there isn't enough memory available
3) The JVM kicks off a GC to prevent an out of memory error (http://download.oracle.com/javase/1.4.2/docs/api/java/lang/OutOfMemoryError.html)
4) The GC completes and the allocation is attempted again. If it fails, an out of memory error is thrown, Otherwise, you get the memory
So, the key thing to notice in the above steps is that the finalizer queue is NOT run until its empty or even mentioned at all. The main problem everyone is having is that they are stuck waiting for the finalizer thread to allow the release of the native memory bitmaps are using.
To fix this problem, simply be sure to call recycle() on bitmaps when you are done using them. This will free the large portion of native memory they use, and will prevent the problems everyone has been having.
Fast Tips:
1) NEVER call System.gc() yourself. This has been propagated as a fix here, and it doesn't work. Do not do it. If you noticed in my explanation, before getting an OutOfMemoryError, the JVM already runs a garbage collection so there is no reason to do one again (its slowing your program down). Doing one at the end of your activity is just covering up the problem. It may causes the bitmap to be put on the finalizer queue faster, but there is no reason you couldn't have simply called recycle on each bitmap instead.
2) Always call recycle() on bitmaps you don't need anymore. At the very least, in the onDestroy of your activity go through and recycle all the bitmaps you were using. Also, if you want the bitmap instances to be collected from the dalvik heap faster, it doesn't hurt to clear any references to the bitmap.
3) Calling recycle() and then System.gc() still might not remove the bitmap from the Dalvik heap. DO NOT BE CONCERNED about this. recycle() did its job and freed the native memory, it will just take some time to go through the steps I outlined earlier to actually remove the bitmap from the Dalvik heap. This is NOT a big deal because the large chunk of native memory is already free!
4) Always assume there is a bug in the framework last. Dalvik is doing exactly what its supposed to do. It may not be what you expect or what you want, but its how it works.
Finalizer:
Since it seems a lot of misinformation is being spread in this ticket, I wanted to try and address a few things that might help people before they are led down the wrong path.
First, you must understand a few things about bitmaps and the garbage collector. A bitmap (as of 2.x and earlier), has memory in both the Dalvik and native heap (with the majority of it stored on the native side). The garbage collector is only capable of freeing memory in the Dalvik heap. Native memory for each bitmap is freed using a finalizer.
The exact steps in dalvik to collect a bitmap is as follows:
1) A bitmap becomes eligible for garbage collection
2) The GC eventually runs and sees that the object requires finalization
3) The bitmap is placed onto the finalizer queue
4) The finalizer eventually runs and native memory is freed (at this point, most of the memory you assigned to the bitmap is freed)
5) The GC eventually runs again and the bitmap is removed from the Dalvik heap. This "remainder" object is relatively small when compared to the previously in-use native memory
There are a few things you should understand about finalizers. The following is some data I extracted from http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=%2Fcom.ibm.java.doc.diagnostics.50%2Fhtml%2Fmm_gc_coexist.html
Finalizers:
Are not run in any particular sequence
Are not run at any particular time
Are not guaranteed to run at all
Will run asynchronously to the Garbage Collector
So lets talk about what does happen when you try to allocate a bitmap and there is no memory available:
1) A bitmap or large chunk of memory tries to be allocated
2) The JVM realizes there isn't enough memory available
3) The JVM kicks off a GC to prevent an out of memory error (http://download.oracle.com/javase/1.4.2/docs/api/java/lang/OutOfMemoryError.html)
4) The GC completes and the allocation is attempted again. If it fails, an out of memory error is thrown, Otherwise, you get the memory
So, the key thing to notice in the above steps is that the finalizer queue is NOT run until its empty or even mentioned at all. The main problem everyone is having is that they are stuck waiting for the finalizer thread to allow the release of the native memory bitmaps are using.
To fix this problem, simply be sure to call recycle() on bitmaps when you are done using them. This will free the large portion of native memory they use, and will prevent the problems everyone has been having.
Fast Tips:
1) NEVER call System.gc() yourself. This has been propagated as a fix here, and it doesn't work. Do not do it. If you noticed in my explanation, before getting an OutOfMemoryError, the JVM already runs a garbage collection so there is no reason to do one again (its slowing your program down). Doing one at the end of your activity is just covering up the problem. It may causes the bitmap to be put on the finalizer queue faster, but there is no reason you couldn't have simply called recycle on each bitmap instead.
2) Always call recycle() on bitmaps you don't need anymore. At the very least, in the onDestroy of your activity go through and recycle all the bitmaps you were using. Also, if you want the bitmap instances to be collected from the dalvik heap faster, it doesn't hurt to clear any references to the bitmap.
3) Calling recycle() and then System.gc() still might not remove the bitmap from the Dalvik heap. DO NOT BE CONCERNED about this. recycle() did its job and freed the native memory, it will just take some time to go through the steps I outlined earlier to actually remove the bitmap from the Dalvik heap. This is NOT a big deal because the large chunk of native memory is already free!
4) Always assume there is a bug in the framework last. Dalvik is doing exactly what its supposed to do. It may not be what you expect or what you want, but its how it works.
Finalizer:
收尾:每个类都有一个特殊的方法finalizer，它不能被直接调用，而被JVM在适当的时候调用，通常用来处理一些清理资源的工作，因此称为收尾机制。
相关链接：
1.How to discover memory usage of my application in Android
2.Android内存情况 ； http://blog.csdn.net/wangqilin8888/article/details/7737278
3.http://my.oschina.net/kangchunhui/blog/67613
4.http://47.lyywin.com/news1/679.html
5.http://blog.csdn.net/jianzhengzhouzjz/article/details/7623516
6.http://blog.csdn.net/shlpyy/article/details/6831104
更多相关文章
- Android事件处理
- 自定义组件
- Android短信----发送流程---框架层（Frameworks）
- Android和H5的交互
- Android(安卓)N画中画模式
- android基础（对话框风格Activity实现)
- android基础（对话框风格Activity实现)
- Android指定调用系统自带浏览器打开链接
- Android与JS互调