Android memory management: Screen density, requested image sizes and available heap

Question

Guess what, another Android-Bitmap-OOM question!

Background

Whilst stress testing our application it has been noted that it is possible to max-out the app's process memory allocation after sustained, heavy usage (monkey runner like) with OutOfMemory exceptions being recorded within the ensuing stacktrace. The app downloads images (around 3 at a time) when a page under a ViewPager is selected. There can be 280+ images available for download when the length and breath of the app is exercised. The application uses Picasso by Square for it's image downloading abstraction. Notably, at no point in our application's code are we manipulating Bitmaps directly...we trust that the very talented Square Inc. employees are doing it better than we can.

Here is a picture

The below plot shows the heap allocations over time recorded under the dalvikvm-heap log message. The red dots indicates a user bringing a fresh set of articles into the application in order to bolster the amount of work outstanding and stress the app...

DALVIKVM heap allocations http://snag.gy/FgsiN.jpg Figure 1: Nexus One heap allocations; OOMs occur at 80MB+

Investigation to-date

Against a Nexus S, Nexus 4, Wildfire, HTC Incredible and a myriad of further test devices, anecdotal testing has shown the memory management to be sufficient with the DVM GC 'keeping up' with the heavy lifting work being completed by the app. However, on high end devices such as the Galaxy S II, III, IV and HTC One the OOM are prevalent. In fact given enough work to do, I would imagine all of our devices would eventually exhibit the failure.

The question

There is clearly a relationship between screen density (our requested image sizes are based off the size of the ImageView), the process memory allocation and the number of images at a given size that would result in the app exceeding it's heap limits. I am about to embark on quantifying this relationship but would like the SO community to cast their eyes over this problem and (a) agree or disagree that the relationship is worth making and (b) provide literature indicating how best to draw up this relationship.

It is important to note that if we destroy the image quality our OOM all disappear but alas the UX is poorer which is why we are wanting to be dicing with the most effective use of the available heap.

---

Side note: Here is the portion of code responsible for loading these images into the views that have been laid out;

picassoInstance.load(entry.getKey())
               .resize(imageView.getMeasuredWidth(), 
                       imageView.getMeasuredHeight())
               .centerCrop()
               .into(imageView);

The 'dashing of image quality' mentioned above is simply dividing the imageView.getMeasured... by a number like '4'.

Answer 1

First you need to manage the memories allocation ,its a big issue in android as bitmaps takes lots of memories ,for that memory allocation can be reduce by following ways

1. put all those images which are huge in size to assets folder instead of putting them in drawabable folder . because drawable resources takes memory for caching them .if you load from asset folder the image will not cache .and will takes less memory .

   1. study Lrucache which use for efficient memory management .
   2. put resources in tiny formats for that check TinyPNG
   3. if your images are too large in resolution , then try to use SVG files for images and load SVG file instead of image . check this SVG FOR ANDROID

finally i am not very good in English hope it may helps you.