I am getting random out of memory exceptions in my app caused by inflate exceptions.
I have 7 fragment (difficulty) activities which launch their own activities via buttons. Each fragment has a scroll view with 30 buttons (levels).
I have set it up so that i can swipe across to each fragment and the fragment takes up the entire screen.
Occasionally when i swipe a few times and then select a random button from a group of 30 it will crash. It tries to load the activity and gives an out of memory exception with an inflate exception on a random line. The line always falls on an imageView or imageButton in the xml file. The activities that load are a grid of imageViews and imageButtons.
I do not get the exception much but it is something i want to fix. I have looked at many other out of memory exception questions although none have helped me. I have done a Memory analyser test and it shows nothing out of the ordinary.
I believe that the imageViews and imageButtons are using too much memory, although i only ever have one activity open at once.
It IS because of your images that are loading. When you load an image and you move around the page and view another image the heap increases. As you continue the process of viewing random images the heap grows even more until your app crashes. It's like stacking books on a glass table. You either move(cache) a book(image) or the glass(app) breaks. You should use an imageloader to load your images.
https://github.com/nostra13/Android-Universal-Image-Loader
You've mentioned that it always falls on an ImageView and ImageButton - and this is the clue to solve this problem. You get OOM 'cause background resource of this view has high resolution and takes a lot of memory. Try to lower resolution of this image.
Also you've mentioned that you have a ScrollView and this means that you keep in memory every 30 items. Probably you'd better change it to RecyclerView backed by adapter.
Just had the same problem and I'd like to simplify all the things said here:
Simply: reduce your images sizes.
Don't use 1080X1920 images... It's too high res.
Such image, even if compressed, when deployed will catch about 1080X1920X4B = 8.2MB (The GPU has to deploy it to it's full original resolution... That's why compression won't help but reducing the needed memory size...) and this i RAM that we're talking about..
Take Gimp or Photoshop and down scale the image to, say, 1/4: 540X960, and you won't feel the difference.. Belive me, been there already.
Beware of the memory consumption of images and videos.
Hope this helps,
James
Related
I am using itemTouchHelper to remove a cardView from a RecyclerView on swipe
my cardview is simple it just has a text and an image
but when i swipe to remove the card disappears but is never taken out of memory (i am saying this because the memory of the image never goes away and it causes an out of memory exception)
my code is very simple so i was wondering if there was a step i was messing that tells the recycler view to remove from memory?
my code is exactly like this one
Usually, images are loaded in android memory, scaled according to device screen resolution requirements, and kept there till the process dies or, is killed or, is collected by garbage collector.
It is possible that your image size in card view (or other images in your res folder) is/are large, and images after scaling by android is occupying too much of memory, to cause memory exception. Try reducing size of your image (Try compare size with the icon sizes that google icons has, they all are less than a Kb, amazing !).
If the above does not work, then create a drawable-nodpi folder in your res folder and put large size images in this folder, this will indicate android to not to scale these images and render it as it is. (make sure you test in all screen devices after following this approach, because now the image won't scale in different screen sizes).
Finally, if none of the above helps try running : System.gc() after there is a card swipe action performed by user. This will run garbage collector and your image will be removed from memory. (This approach does not guarantee garbage collector working in all devices, so make sure that you try for above two approaches, they should work).
Hope this helps !
I have a huge image to render (1024x25373p) cut into 99 images of 1024x256p.
I have tried to use a ListView, but without success : it crashes when scrolling, whithout any error (exept one line saying the proccess was stopped).
So, my question is, how do I render this huge image ?
Please note that I have tried to use TileView by moagrius, without success (I can't get it to work with navigation drawer)
As a suggestion ,
If this is listview, you may not need such larger size images "1024x256p" .
Actual size of your imageView may much for less than that. So its a wastage of
heap if you try to load those images directly without some processing.
Definitly you need to do some scaling down for your image based on actual size that you need. Nice exapmple and code has been published on the official doc
You need to deallocate memory or clear the all bitmaps which are not visible on the listview for particular moment.
You can use progressing loader in order to load your images in to the listview. Then loading will be happen based on the scrolling.
Also you can define lager heap enable in your manifest though it is not recommended but has to do in highly memory consumable apps.
android:largeHeap="true"
I know this question is asked several times, but still clarity to my situation would be helpful.
I am showing some images in 2 column grid view. When user taps on an image, I am displaying the image in ViewPager. The Image which is displayed in gridview is about 200X200px and I want to show the same image with enlarged size say about 800X800px in ViewPager in a DialogFragment.
The Actual size of images are huge with different resolutions. I have followed the link http://developer.android.com/training/displaying-bitmaps/index.html and I have scaled down images to size which is required for my app. In ViewPager fragment dialog I am also recycling the image with bitmap.recycle() and calling System.gc() explicitly(I know this is a bad practice) at PagerFragment onDestroy. But even then I am getting Out of memory error. On top of it, I am encountering this issue only in Android 4.2.1 (Nexus 7) but not on Android 4.1.2( Samsung Tab) and Android 4.4(Nexus 7).
For later 2 android versions, I do not have to call even System.gc(). It works very well without this. I have checked Viewpager with some 300 - 400 images. But for former after scrolling 60 images, App is crashing with OutOfmemory error. To resolve this I have used a workaround for now android:largeHeap="true" which I think is very bad for myapp and could not digest it.
I really appreciate if anyone who can help me avoid android:largeHeap="true".
In my app, I have to show around 6000 images in GridView and also an enlarged image in ViewPager linked to GridView. I am loading only 20 images from FileSystem asynchronously while scrolling gridview.
Thanks in advance...
Use an LRUCache to hold the images. Make that the only thing that holds a Bitmap that's not currently on screen. That way the older bitmaps will be kicked out and garbage collected quickly.
My app is getting crashed (throws OutOfMemoryError) when I try to load images in a ViewPager. Here are the details.
All the images are 720*1280 in dimension with 100-150KB in size.
I even tried using Fragments in a Viewpager to load images.. but after sliding one or two images the app gets crashed.
Any pointers on how to resolve this?
Thanks!!
720*1280*32 = 29491200 bits = 3.52 mb each one in memory.
Checkout this tutorial :)
Out of memory error means exactly what is stays. The application is trying to allocate to much memory. Android application are (depending on device) allowed to allocate 30-50MB.
The problem with the view pager is that it tries to hold at least 3 pages (current previous and next) to provide fluent UI work.
Bitmap to be displayed needs to uncompressed. So the only thing that matters is the size (pixel number) and color depth.
Usually 3 bitmaps of size you given should be quite easy hold on the device. I suppose that you are trying to process them in some not proper way, or you are missing releasing them from memory. Can't say more not knowing what are you doing with those bitmaps.
Hi guys i am new to android and i posted a question a week ago in this link which basically stated that i was getting a java.lang.outofmemory error when i was using a lot of different backgrounds for my activities.
why am I getting errors when I use different backgrounds in xml
So as a new developer I have searched and searched for a solution as to how to clear the memory as i go from activity but none have been clear or precise. Then i stumbled across this site http://androidactivity.wordpress.com/2011/09/24/solution-for-outofmemoryerror-bitmap-size-exceeds-vm-budget/
which described exactly what i was going through except they use 10 activities and i am only using 4. However when i implemented his code it my project i ended up with null pointer exceptions and after fiddling with his code I ended up back were i started with the same out of memory error.
So can anybody direct me to someone who can show me how to have as many backgrounds as i want with out running out of memory. Or does android as great as it is does not let you simply use more than a certain amount of backgrounds? help?
It's not that there is a limit on the amount of backgrounds, but each background image you load is a loaded into memory as a bitmap and held there until the activity is destroyed. If you are opening multiple activities one after another, each background image will need to be held in memory and so eventually you will get an out of memory exception.
If you set a large background image, you will also experience some blocking on the ui thread, while the image is loaded into memory.
One way around this that worked for me was to use an imageloader. This decodes the image off the ui thread, caches it on disk, loads it into memory and if memory is running low, will clear an image from memory and fallback to the disk cache. You may get a slight delay/fade in as the image is loaded but this is not so bad visually, and when loaded once, will load straight away if you go back to that activity.
Check out Picaso Picasso which is really easy to implement and a great api or Universal Image Loader.
My layouts were all RelativeLayouts and the first child (will be behind all other views) was an ImageView with scaleType centercrop and width and height set to match_parent. When each activity loads (onCreate), just grab a reference to the imageview in your layout and set the required background image using your ImageLoader of choice.
The other option is to have multiple copies of your background image in your resources, with each one resized to perfectly fit your resolutions of choice (drawable-mdpi/-hdpi/-xhdpi etc). This way, you ensure you are never loading images that are way bigger than you need to be displayed and your app will be more forgiving in terms of memory consumption.