Today's anomaly is interesting, called Android.view.InflateException:Binary XML file line #95: The Error inflating class (out of memory).
In fact, because the out of memory, resulting in XML is not possible to be inflated successfully, so the activity of the OnCreate method,
Setcontentview (r.layout.***) is not likely to be successfully invoked.
He appeared in I have multiple instructional animations, and the animated animation that is based on the Imageview,imageview background is a large picture of our project.
The error situation is: Open an activity, the activity is only used to play an animation. Then manually back, turn off activity (finish). Second activity, the second activity bound layout is different from the first one, and another animation is played. Manually back, turn off activity.
And so on, the android.view.InflateException:Binary XML file line #95 will appear after multiple runs: Error inflating class.
caused by out of memory.
At first I did not want to understand, every time my activity is finish, how can not memory.
So the Internet to find the answer, on the dear StackOverflow found the great God of the comments, (the Great god please: http://stackoverflow.com/questions/7536988/ android-app-out-of-memory-issues-tried-everything-and-still-at-a-loss/7576275), originally raised the question the everything, haha.
In fact, because we do not recycle resources manually, in other words, Java garbage collection mechanism is not so smart, we finish off, but the relevant resources in it may not be recycled. It's possible that he thinks he's smart enough to stay and wait for our next use. So we need to manually release large resources such as ImageView in the OnStop method.
The great God's wording is as follows:
drawable d = imageview.getdrawable (); if (d! = null) d.setcallback (null); Imageview.setimagedrawable (null); Imageview.setbackgrounddrawable (NULL);
I then also configured the following code in the five animated teaching activity in our project:
@Overrideprotected void OnStop () {releaseimageviews (); Super.onstop ();} private void Releaseimageviews () {Releaseimageview (mterminal); Releaseimageview (mfingerpressinnerring); Releaseimageview (mfingerpressmiddlering); Releaseimageview (mfingerpressouterring); ReleaseImageView (mInnerRing); Releaseimageview (mmiddlering); Releaseimageview (mouterring); Releaseimageview (Mphone); ReleaseImageView (MScreen);} private void Releaseimageview (ImageView ImageView) {drawable d = imageview.getdrawable (); if (d! = null) D.setcallback ( NULL); imageview.setimagedrawable (null); imageview.setbackgrounddrawable (null);}
This problem is resolved.
The exception is very classic, special record.
Tips from the Great God:
Some tips:
Make sure is not leak activity context.
Make sure is don ' t keep references on bitmaps. Clean all of your ImageView's in activity#onstop, something like this:
drawableD=ImageView.getdrawable(); if (D!= NULL)D.Setcallback(NULL);ImageView.setimagedrawable(NULL);ImageView.setbackgrounddrawable(NULL);
Recycle bitmaps If you don ' t need them anymore.
If you use the memory cache, like MEMORY-LRU, make sure it isn't using to much memory.
Images take alot of memory, make sure you don't keep too much other data in memory. This easily can happens if you have the infinite lists in your app. Try-to-cache data in DataBase.
On Android 4.2, there are a bug (stackoverflow#13754876) with hardware accelerationhardwareAccelerated=true
In your manifest it'll leak memory.GLES20DisplayList
-Keep holding references, even if you do step (2) and no one else is referencing to this bitmap. Here you need:
A) Disable hardware acceleration for API 16/17;
Or
b) Detach view that holding bitmap
for Android use android:largeheap=" true "
in your androidmanifest
. But it'll not solve your memory problems, just postpone them.
If you need, like, infinite navigation and then fragments-should be your choice. So you'll have 1 activity, which'll just switch between fragments. This is also solve some memory issues, like number 4.
Use memory Analyzer to find out the cause of your Memory leak.
Here are very good video from Google I/O 2011:memory management for Android Apps
If you dealing with bitmaps this should be a must read:displaying bitmaps efficiently