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?
Related
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 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.
I'm developing an app and I got several HD Images (PNG Files) throughout the app. To navigate through the app as quickly as possible, I want to load all pictures in RAM and display them when the certain activity starts.
Means each activity has a HD picture.
Since it is quite impossible to load a 32bit HD Image to the RAM of the app, I had to resize them using that bitmap shit of Android. But I don't want to resize them.
Is it possible to load all HD images at the beginning of the app to the RAM? I don't understand why there are HD 3D games like Modern Combat 5 have no problems with that and just take the amount of RAM they need and I can't even load 7 or 8 HD Images at once to my app. Is there a trick? How can I get a Heap large enough for all my stuff to load at once and keep it in RAM while the app is active?
Thank you in advance
You need to recycle() your bitmaps after you complete the work with bitmap, so that will clear your memory :). Read this Displaying Bitmaps Efficiently
I am building Javascript application for mobile browsers (not wrapped-as-native app).
I noticed that Android (tested 2.3 emulator and Galaxy S device) reduces the quality of loaded images if the image dimensions exceed certain threshold (width above 1400 px or so). This make it impossible to load big bitmap images (2000 x 2000 px) without the quality going unusable.
I tested this by
Loading one big image and drawing it on the - I got pixel garbage out. If I draw grid lines using lineTo() on they have perfect quality, so the bad must be in the image pixel data
Slicing the big image to 100 x 100 slices and drawing them to a canvas - this is the only method I found resulting no quality reduction. However, slicing is cumbersome, adds extra step to preprocess images and page loading times suffers
I tested tring to load image with new Image() object, tag and CSS background: everything suffers from the reduced quality, so I suspect the probelm is the image loader itself
I also tried everything with CSS image-rendering https://developer.mozilla.org/En/CSS/Image-rendering - no luck
Viewport tag seems to have no effect to the image loading - the data is already garbage when you try to touch the loaded pixel data. I tried all possible values suggested in Android's SDK documentation http://developer.android.com/reference/android/webkit/WebView.html
Tested also Firefox mobile, desktop browsers, iOS: everything is good there.
So, what is going on - Android WebView simply can't load big images?
(smiley of hung Android robot here)
Android unconditionally resamples images and reduces quality if a certain threshold of memory usage is exceeded.
https://android.googlesource.com/platform/external/webkit/+/android-3.2.4_r1/WebCore/platform/graphics/android/ImageSourceAndroid.cpp
There is no way to access the original image data in intact.
I posted a question regarding this to android-developers Google Group and kindly asking to maybe provide some kind of flag to opt-out from this behavior.
Meanwhile, if you are considering developing HTML5 web apps and you might use big images, you simply need to preprocess them on the server-side by slicing, send in smaller images to the device and then reconstuct the original image using or putting many tags inside a container element.
Another option would be load image "manually" by writing a PNG decoder which directly loads the image to , bypassing ImageSourceAndroid class.
The question is old so probably few things changed, but if you are having image quality issues with WebView then consider converting your image into PNG format.
Somehow when I load the jpeg version of the image the quality is low, while loading the png image with the same resolution the quality is high.
I have a gridview of images in my android app. It is an image gallery for an artist, so there are about 180 relatively high quality images in the resource folder. It works fine in the emulator and on my HTC Evo in debug mode. However when I publish it to the market and install it from there it crashes when the gridview is attempted to be loaded.
Is there a limit on locally defined images or is there a better way to manage so many images?
I went ahead and processed all the images into a worthwhile size for the respective
/res/drawable-hdpi (around 1000px wide or high)
/res/drawable-mdpi (max 300px)
/res/drawable-ldpi (max 75px)
and even though the compiled app is even bigger, it runs much better and does not crash on opening the gallery gridview.