I'm using a RecyclerView with images (approx 140 items in the list).
I had memory issues before so I removed the images from the view completely, before I put the APP live.
Now I am using Picasso to load the images, but before I upload this new version to the PlayStore, I'd like to be confident that this has fixed the memory issue? The new phone I'm using to test this on has a lot more memory than my previous phone, so I cannot reproduce the original problem anymore.
I am resizing my image to match my screen width.
Related
Does anyone else have a issue with displaying File image in a gridview.builder or list? The images display but if I scroll fast logcat gives an out of memory exception and the app crashes.
I have tired clearing the cache, that doesn't help. Memory used by the app when you get out of memory varies, sometimes 100mb other times 500mb.
I have tried an example to rule out anything daft in code I'm doing by using someone else's example https://github.com/follow2vivek/FlutterGallery but still have the same issue when you scroll up and down fast.
I only have 18 pictures. I have tried a few phones too.
Why does using large images using cardview crash the android system? I used 1280 X 600 images for cardview, but launching the app after install crashes the system presents a out of memory error from the logcat.
I had atleast 400MB of RAM while launching the app(viewed using simple system monitor), but yet the app crashes. Is the cardview designed to work with only small images? What if we have to use larger images for larger dpi devices? The cardview was used with a recycler view and the OS which it was tested on was KitKat.
You may have 400 MB RAM but all the RAM will not be directly provided to your application so application will crash...if you want to use different dpi images for different devices then you can add that to drawable, drawable-mdpi, drawable-xhdpi,drawable-xxhdpi etc. folder so that system can select them automatically....if you are loading from a url...then you can use third party libraries like Picasso, Glide etc to load the image efficiently
Also, in your question you are saying that you are adding card view in recycler view...which means more than one 1280x600 images will be loaded which will take a lot of memory and make your app to crash.
For your question "Is the cardview designed to work with only small images?"
No, cardview is not related to your out of memory... its the image size and Memory provided for you...card view can work with any size of image.
Adding Adding android:largeHeap="true" to your menifest can help you to some extent
I was running into the same issue. Adding android:largeHeap="true" to tag in AndroidManifest.xml solved the issue for me on my physical Android but I'm a bit concerned that this might still be an issue for some devices with less memory?!?
You don't mention how you want to show the image is it card background or a imageview into a cardview. If you want to use ImageView into a CardView then you can use picasso or glide library to handle this issue.
Out of memory error is very common error when you are developing for a application that deals with multiple images sets or large bitmaps or some Animation stuff. In this case we have to be very careful and efficient while handling the images or object allocation and deallocation. OOM error comes when the allocation crosses the heap limit or your process demand a amount of memory that crosses the heap limit.
I'm working on an app that shows the floor plan of a trade fair. This is a high resolution (3500x4600), but fairly low file size (400kb) PNG image. I have a little component that allows to pan / zoom it.
Now it all works just fine on iOS, but on Android I just cannot get it to work. If I just try to load it in the normal RN (0.56) Image component I get a blank screen. I'm testing on an HTC One M8, which is not exactly brand new, but also not super low end (2 GB Ram). Funnily enough, if I convert it to a 2,6 MB jpg with the same dimensions, it will show up, though the quality is so bad, you cannot read any of the labels.
There are some mostly older github issues on this (like here and here), but none of those solutions (android:largeHeap="true") work for me.
I tried using react-native-svg, but it has the same problem (I guess it eventually gets rasterized?).
I also tried using react-native-fast-image, which uses Glide under the hood instead of Facebook's Fresco, but (you guessed it), it also doesn't work. If I just load the image, it will get downsampled (worse than the jpg). I tried to get Glide to stop doing that (using override), but then I get a blank screen again.
I found this library, which I guess does exactly what I want, but I'd have to wrap it for RN use... which would be quite a bit of work.
Anyone have an idea?
As I navigate through my NativeScript app, I keep running into out of memory crashes. I tried to resolve this by first upgrading {N} with #next for both tns-core-modules and tns-core-modules-widgets. I then installed nativescript-fresco and replaced all image tags with Fresco. It seems to of helped a bit but eventually if I navigate back and forth between a list view of images to another page, the app eventually crashes.
So I have a question regarding the usage of Fresco.
Let's say I have a bunch of images that is 1600 x 1200 and 1MB each.
And I use Fresco to display these images in a list view at thumbnail size like
100 x 100 square, does the app still load each of these images as a file size of 1MB each? Or does fresco create a thumbnail size and load a smaller file size version of the images?
I'm guessing that this maybe the reason why the app still crashes?
I am working on an Android app, that has lots of images (a few hundred) to be displayed in a grid format. I am using a custom HorizontalListView and a couple of LazyLoading, Caching techniques to achieve the required UI.
What I have noticed (in DDMS) is, the app consumes a lot more memory on Android 3.2 compared to Android 2.3.3 I was expecting a small difference, however my app consumes about 35Mb on Android 3.2 and only 12Mb on 2.3.3. Any particular reason for such a huge difference?
Are you considering supporting multiple screens while loading images?
I think your problem is screen type and the size of image. If you focus on this area, you may get improved results.