About Oom Insights and solutions for Android using bitmap

Android development, starting from 2010 to learn to now independently complete an app, this long four years, has experienced a lot of bug torture, countless times of overtime training. However, since I think I already know more about Android, but recently in a project, because Oom and toss a week, back to the place, know their own shortcomings, feel that they are so rookie ah.

Well, no nonsense, when you use the development of Android, very little attention or awareness of the importance of releasing memory, because everyone in the use of the process, the picture resources involved, or more stable, back and forth to switch the interface, the picture is so few or use a few pictures are very small There is no way to feel a potential crisis caused by a picture taking up memory.

If your program uses a bit of functionality, you as a qualified Android development engineer, you need to pay attention to the potential crisis of Oom
1. Interface is more, and many of the interface background picture is not the same;

2. Related to skin changing function, define a variety of skins, the resources of the skin is not to use color but picture resources;

In both cases, if you do not pay attention to the reasonable release of memory, you will be the failure of their own program to pay the cost of the crash.

Do you think you don't need to free up memory in the Android program, whether you set the background using layout layouts or use the Setbackgroundresource setting background? This is definitely a wrong idea, absolutely wrong. Perhaps this wrong understanding will be on the big screen mobile phone, exposing your oom phenomenon, especially in Samsung's big screen mobile phone, the chance to explode oom is even greater.

Perhaps, everyone in the use of development, will pay attention to this point, the use of a way to solve the release of memory (many examples of the Internet use this way to release memory), such as:

View view = Findviewbyid (R.ID.PAGE_BG); Bitmapdrawable bitmapdrawable = (bitmapdrawable) view.getbackground (); View.setbackgroundresource (0); Bitmapdrawable.setcallback (NULL); Bitmap Bitmap = Bitmapdrawable.getbitmap (); if (Bitmap! = null &&!bitmap.isrecycled ()) {bitmap.recycle (); Bitmap = null;} System.GC ();

Take a look at the results of the Logcat printout from our test results

05-07 06:55:39.330:D/DALVIKVM (6988): Gc_for_alloc freed 4091K, 31% free 9715k/13936k, paused 44ms, total 45ms05-07 06:55: 39.340:i/dalvikvm-heap (6988): Grow Heap (Frag case) to 13.126MB for 3686416-byte allocation05-07 06:55:39.421:D/DALVIKVM  (6988): Gc_concurrent freed <1k, 5% free 13314k/13936k, paused 6ms+5ms, total 83ms05-07 06:55:39.600:d/dalvikvm (6988): Gc_for_alloc freed <1k, 5% free 13314k/13936k, paused 44ms, total 44ms05-07 06:55:39.670:i/dalvikvm-heap (6988): Grow Heap (Frag case) to 19.377MB for 6554896-byte allocation05-07 06:55:39.790:D/DALVIKVM (6988): Gc_concurrent freed 0K, 4% F Ree 19715k/20340k, paused 7ms+20ms, total 114ms05-07 06:55:40.011:i/system.out (6988): oncreate05-07 06:55:41.760:d/ DALVIKVM (6988): Gc_explicit freed 10759K, 56% free 9063k/20340k, paused 4ms+7ms, total 111ms05-07 06:55:41.821:D/DALVIKVM  (6988): Gc_explicit freed <1k, 56% free 9062k/20340k, paused 4ms+7ms, total 62ms05-07 06:55:41.821:i/system.out (6988): OnDestroy

From the above logcat, we see gc_expltcit for us to release 10759k of memory, this is very impressive, perhaps this moment you will be complacent, will think you have solved the program of oom potential crisis.

However, in fact, you have raised another potential problem, if you have a and B interface, and use a background, you release in A, in B to use, it will lead to error Logcat

05-07 07:00:37.250:D/DALVIKVM (6988): Gc_explicit freed 6411K, 81% free 2692k/13936k, paused 4ms+6ms, total 105ms05-07 07: 00:37.310:D/DALVIKVM (6988): Gc_explicit freed 88K, 82% free 2604k/13936k, paused 3ms+8ms, total 59ms05-07 07:00:37.310:i /system.out (6988): ondestroy05-07 07:00:37.891:d/androidruntime (6988): Shutting down vm05-07 07:00:37.891:W/DALVIKVM (6988): Threadid=1:thread exiting with uncaught exception (group=0x40a71930) 05-07 07:00:37.991:e/androidruntime (6988) : FATAL exception:main05-07 07:00:37.991:e/androidruntime (6988): java.lang.RuntimeException:Canvas:trying to use a rec ycled Bitmap [email protected]05-07 07:00:37.991:e/androidruntime (6988): at Android.graphics.Canvas.throwIfRecycled (canvas.java:1026) 05-07 07:00:37.991:e/androidruntime (6988): at Android.graphics.Canvas.drawBitmap (canvas.java:1127) 05-07 07:00:37.991:e/androidruntime (6988): at Android.graphics.drawable.BitmapDrawable.draw (bitmapdrawable.java:393) 05-07 07:00:37.991:e/androidruntime (6988): At Android.view.View.draw (view.java:13697) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.View.draw ( view.java:13596) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewGroup.drawChild (Viewgroup.java : 2928) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewGroup.dispatchDraw (viewgroup.java:2797) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.View.draw (view.java:13594) 05-07 07:00:37.991:e/ Androidruntime (6988): at Android.view.ViewGroup.drawChild (viewgroup.java:2928) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewGroup.dispatchDraw (viewgroup.java:2797) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.View.draw (view.java:13594) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewGroup.drawChild (viewgroup.java:2928) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewGroup.dispatchDraw (viewgroup.java:2797) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.View.draw (view.java:13715) 05-07:00:37.991:e/androidruntime (6988): at Android.widget.FrameLayout.draw (framelayout.java:467) 05-07 07:00:37.991 : E/androidruntime (6988): at Com.android.internal.policy.impl.phonewindow$decorview.draw (PhoneWindow.java:2211) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewRootImpl.drawSoftware (viewrootimpl.java:2281) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.ViewRootImpl.draw (viewrootimpl.java:2177) 05-07 07:00:37.991: E/androidruntime (6988): at Android.view.ViewRootImpl.performDraw (viewrootimpl.java:2045) 05-07 07:00:37.991:e/ Androidruntime (6988): at Android.view.ViewRootImpl.performTraversals (viewrootimpl.java:1854) 05-07 07:00:37.991:e/ Androidruntime (6988): at Android.view.ViewRootImpl.doTraversal (viewrootimpl.java:989) 05-07 07:00:37.991:e/ Androidruntime (6988): at Android.view.viewrootimpl$traversalrunnable.run (viewrootimpl.java:4351) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.choreographer$callbackrecord.run (Choreographer.java:749) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.Choreographer.doCallbacks (choreographer.java:562) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.Choreographer.doFrame (choreographer.java:532) 05-07 07:00:37.991:e/androidruntime (6988): at Android.view.choreographer$framedisplayeventreceiver.run ( choreographer.java:735) 05-07 07:00:37.991:e/androidruntime (6988): at Android.os.Handler.handleCallback ( handler.java:725) 05-07 07:00:37.991:e/androidruntime (6988): at Android.os.Handler.dispatchMessage (handler.java:92 ) 05-07 07:00:37.991:e/androidruntime (6988): at Android.os.Looper.loop (looper.java:137) 05-07 07:00:37.991:e/ Androidruntime (6988): at Android.app.ActivityThread.main (activitythread.java:5041) 05-07 07:00:37.991:e/ Androidruntime (6988): at Java.lang.reflect.Method.invokeNative (Native Method) 05-07 07:00:37.991:e/androidruntime ( 6988): At Java.lang.reflect.Method.invoke (method.java:511) 05-07 07:00:37.991:e/androidruntime (6988): at Com.android.internal.os.ZygoteIniT$methodandargscaller.run (zygoteinit.java:793) 05-07 07:00:37.991:e/androidruntime (6988): at Com.android.internal.os.ZygoteInit.main (zygoteinit.java:560) 05-07 07:00:37.991:e/androidruntime (6988): at Dalvik.system.NativeStart.main (Native Method)

It feels strange to put, because you in this sentence logcat, can not find the wrong place and why such a mistake, but this error is fatal. Understood from the literal meaning of English: You use an already released bitmap to draw your interface.

In this case, perhaps 40% of Android programmers do not know what is wrong, because we can not grasp the error in the place, perhaps you think you are based on the activity of the life cycle to fill the background and release the background, but there are such errors.

The information on the Internet explains, you can understand, but still can not find the specific problem.

I have experienced the pain of this problem, read the online explanations and solutions, there is no reliable. I do not give up on this issue, and after many tests and validations, the problem arises in two possible ways:
Situation 1, you use a a.png image in the interface, and then did a jump, finish a interface, finish, you use a bit of code to release the memory:

View view = Findviewbyid (R.ID.PAGE_BG); Bitmapdrawable bitmapdrawable = (bitmapdrawable) view.getbackground (); View.setbackgroundresource (0); Bitmapdrawable.setcallback (NULL); Bitmap Bitmap = Bitmapdrawable.getbitmap (); if (Bitmap! = null &&!bitmap.isrecycled ()) {bitmap.recycle (); Bitmap = null;} System.GC ();

Then go to the A interface again and it is very likely that the problem occurs.

In case 2, you used the a.png image in the A interface, and then used the a.png in the B interface, the A interface did not finish,b the interface using Finsh, and freed up the memory using the same method as above. Then we normally, a interface will go through Onresume way to display, but at this time, our a.png in memory has been released, so it will trigger the above

05-07 07:00:37.991:e/androidruntime (6988): java.lang.RuntimeException:Canvas:trying to use a recycled bitmap [email pro Tected]

It is simple and easy to understand, but it is not an easy thing to find the problem in practice.

Perhaps you have been mad at this moment, and there is no way to free up memory to solve a potential oom problem?
The answer is. Big companies like Google, which provide APIs that consider potential problems more than the normal programmers consider, are more than n times.

The individual read the relevant API and came up with a solution to free up memory and unlock our potential oom situation.

Whether you are using the layout in XML:

Android:background ,

Or is it called in the Java code:

SetBackground (background);

Setbackgrounddrawable (background)

Setbackgroundresource (resid)

The way to set the background image.

When using, please call the corresponding method:
Setbackgroundresource and android:background→ setbackgroundresource (0);

setbackgrounddrawable (background)→setbackgrounddrawable(null)

SetBackground (background) → setbackground(null)

And then call System.GC () in ondestory;
The above code, we modified to:

View view = Findviewbyid (R.ID.PAGE_BG); View.setbackgroundresource (0); System.GC ();

We are looking at the results of our Logcat:

05-07 07:29:18.941:D/DALVIKVM (7598): Gc_for_alloc freed 27K, 65% free 9791k/27452k, paused 43ms, total 58ms05-07 07:29:18 .970:i/dalvikvm-heap (7598): Grow Heap (Frag case) to 13.203MB for 3686416-byte allocation05-07 07:29:19.041:D/DALVIKVM (7 598): Gc_for_alloc freed 83K, 52% free 13308k/27452k, paused 72ms, total 72ms05-07 07:29:19.140:d/dalvikvm (7598): Gc_conc Urrent freed <1k, 52% free 13308k/27452k, paused 4ms+29ms, total 105ms05-07 07:29:19.240:d/dalvikvm (7598): GC_FOR_ALLO C freed <1k, 52% free 13307k/27452k, paused 40ms, total 40ms05-07 07:29:19.310:i/dalvikvm-heap (7598): Grow Heap (Frag case) to 19.373MB for 6554896-byte allocation05-07 07:29:19.420:D/DALVIKVM (7598): Gc_concurrent freed 0K, 29% free 19709K /27452k, paused 4ms+31ms, total 106ms05-07 07:29:19.590:i/system.out (7598): oncreate05-07 07:29:21.290:D/DALVIKVM (  7598): Gc_explicit freed 10749K, 56% free 9064k/20340k, paused 3ms+8ms, total 125ms05-07 07:29:21.290:i/system.out (7598): OnDestroy

The above interface is not the same as the way we call manual release? Oh, repeated testing repeatedly, see if it will lead to the java.lang.RuntimeException:Canvas:trying to use a recycled bitmap

In fact, our program will no longer have the above problem, and solve the potential crisis of Oom. So simple, so convenient.

Similarly: If we use ImageView in our program, we can also use
Imageview.setimageresource (0); This way, to release our set of Android:src or bitmap and so on.

So, about the picture of oom potential problems, we come to an conclusion, from this experience, let me more in-depth understanding of the Java language Memory recovery mechanism, summed up a sentence: As far as possible to let the system to free memory, we are only responsible for marking the memory to be freed. Popular point: We just mark the people who need to kill, who will kill, let the killer look at the office.

Springsky 
Source: http://blog.csdn.net/springsky_/article/details/25212419
Blog:Http://blog.csdn.net/springsky_
This article is copyrighted by the author and Csdn, welcome reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.