Android. view. InflateException: Binary XML file line #95: Error inflating class (out of m ),

Android. view. InflateException: Binary XML file line #95: Error inflating class (out of m ),

Today's exception is very interesting, called android. view. InflateException: Binary XML file line #95: Error inflating class (out of memory ).

Because of the out of memory, xml cannot be successfully inflated. Therefore, in the onCreate method of the activity,

SetContentView (R. layout. ***) cannot be called successfully.

He showed up with multiple teaching animations and played animations Based on imageView. The background of imageView is a large image of our project.

Error scenario: open an activity, which is only used to play an animation. Then manually back and turn off activity (finish ). Open the second activity. The layout bound to the second activity is different from that bound to the first activity. Play another animation. Manual back to turn off the activity.

Similarly, after multiple runs, android. view. InflateException: Binary XML file line #95: Error inflating class will appear.

Caused by out of memory.

At the beginning, I didn't want to understand how the memory is insufficient when I finish all my activities.

So the Internet to find the answer, in the dear stackoverflow found the comment of the great God, (the great god please step: http://stackoverflow.com/questions/7536988/android-app-out-of-memory-issues-tried-everything-and-still-at-a-loss/7576275), the original problem of the brother also tried everything, haha.

In fact, we didn't recycle resources manually. In other words, java's garbage collection mechanism is not so clever. We finish the process, but the related resources in it may not be recycled. Maybe he thinks he is smart and waits for us to use it next time. Therefore, we need to manually release large resources such as imageView in the onStop method.

The statement is as follows:

Drawable d = imageView.getDrawable();  if (d != null) d.setCallback(null);  imageView.setImageDrawable(null);  imageView.setBackgroundDrawable(null);

The following code is also configured in the five teaching activities 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 solved.

The exception is classic and exclusive.

Tips:

Some tips:

1. Make sure you are not leak activity context.

2. Make sure you are don't keep references on bitmaps. Clean all of your ImageView's in Activity # onStop, something like this:

   Drawable d = imageView.getDrawable();  if (d != null) d.setCallback(null);  imageView.setImageDrawable(null);  imageView.setBackgroundDrawable(null);

3. Recycle bitmaps if you don't need them anymore.

4. If you use memory cache, like memory-lru, make sure it is not using to much memory.

5. Not only images take alot of memory, make sure you don't keep too much other data in memory. this easily can happens if you have infinite lists in your app. try to cache data in DataBase.

6. On android 4.2, there is a bug (stackoverflow #13754876) with hardware acceleration, so if you usehardwareAccelerated=trueIn your manifest it will leak memory.GLES20DisplayList-Keep holding references, even if you did 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

7. For Android 3 + you can try to useandroid:largeHeap="true"In yourAndroidManifest. But it will not solve your memory problems, just postpone them.

8. If you need, like, infinite navigation, then Fragments-shoshould be your choice. so you will have 1 activity, which will just switch between fragments. this way you will also solve some memory issues, like number 4.

9. Use Memory Analyzer to find out the cause of your memory leak.
   Here is very good video from Google I/O 2011: Memory management for Android Apps
   If you dealing with bitmaps this shoshould be a must read: Displaying Bitmaps Efficiently

Caused by: androidviewInflateException: Binary XML file line #2

It looks okay. I guess it's a problem with your PullToRefreshView.

An error occurred while using the android custom View in xml? How should I use it? Advice

Android. view. InflateException: Binary XML file line #8: Error inflating class cm. test. testview

1. Confirm the correct package name "cm. test. testview" -->
2. Confirm inflate usage
[Code] LayoutInflater can be generated in three ways:
　　
LayoutInflaterinflater = LayoutInflater. from (this );
　　
LayoutInflaterinflater = getLayoutInflater ();
　　
LayoutInflaterinflater = (LayoutInflater) this. getSystemService (LAYOUT_INFLATER_SERVICE );
　　
Call the inflate method to convert the xml layout file to View.
　　
PublicViewinflate (intresource, ViewGrouproot, booleanattachToRoot)
　　
The inflate method is also available in the View class.
　　
PublicstaticViewinflate (Contextcontext, intresource, ViewGrouproot)
[/Code]