Android: what is the heap size per intent/activity?

Question

As we all know, the VM Heap Size for Android Apps is limited. (mostly to 16,24,32,48 or 64 MB of RAM depending on the hardware)

we can get the actual Heap Size with

ActivityManager am = (ActivityManager)this.getSystemService(ACTIVITY_SERVICE);
Toast.makeText(this, "HEAP SIZE: " + am.getMemoryClass() + "MB", 1).show();

.

But, what is the memory strategy if I open a new Intent???:

Intent intent = new Intent(MainActivity.this, NewActivity.class);
MainActivity.this.startActivity(intent);

Does this new activity get the full heap size and the old activity is holding in the background, and its memory is cached?

Or does the intent get a complete new VM?

I have a very memory intense App with heavily filles Grid- and ListViews. Since Android 3.0, Bitmaps are allocated inside the Heap, and that causes a lot of headache and trouble with OutOfMemory Errors... I was wondering if I can outsorce the memory hungry Views in their own Intents. <-- does this make any sense?

All Activities of an App share the same Heap. If you would want to outsource it, your Activity must be in a different App (different Package name and also seperately uploaded to Play) - not very practical at all :-) — Thommy, Mar 26 '13 at 14:31

score 0 · Answer 1 · answered Mar 26 '13 at 14:23

Every process has one heap, of whatever size the device specifies (minimum 16 MB if Google Play is installed on the device).

All of your app's components must run within this heap, as your app is a single process. So all your Activities, Services, BroadcastReceivers share the same heap.

When you launch a new Activity, your previous Activity is pushed into the background. Due to this, its onPause() is called, and you should use that method to free up memory (remove loaded bitmaps etc) if you need to.

Also, outsorce the memory hungry Views in their own Intents makes no sense because Intents are used to start Application components like Activities and Services. You cannot use a View with an Intent. Instead, you should be scaling your bitmaps and loading only the required size, and make use of technique like lazy loading to make sure you don't have more bitmaps in memory than required.

when user goes back to the previous activity, what would happen to the bitmaps? since you mentioned in onPause you remove bitmaps loaded. — Raghunandan, Mar 26 '13 at 14:32
outsorce the memory hungry Views in their own Intents. i din;t understand that part of the question. All objects are stored in heap and gc does mark an sweep. — Raghunandan, Mar 26 '13 at 14:48

Raghunandan · Answer 2 · 2013-03-26T14:54:21.180

I agree with Raghav Sood. I have added a bit more of how to display images in listview or gridview.

I have used Universal Image loader to display large number of images in listview.

You should recycle bitmaps when not in use.

http://www.youtube.com/watch?v=_CruQY55HOk. Talk is about memoy management and memory leaks and how to avoid it. If you ever run into memory leaks you can use a MAT Analyzer to find memory leaks. The video also talks about using MAT Analyzer and demonstrates how to get rid of memory leaks.

When you display images in listview you need to recycle the views. Views that are visible are not recycled.

To display images in gridview or listview you can use univarsal image loader. A improved version of lazy loading. Images are cached. You can display images localy or from a server.

https://github.com/nostra13/Android-Universal-Image-Loader

 File cacheDir = StorageUtils.getOwnCacheDirectory(context, "your folder");

 // Get singletone instance of ImageLoader
 imageLoader = ImageLoader.getInstance();
 // Create configuration for ImageLoader (all options are optional)
 ImageLoaderConfiguration config = new ImageLoaderConfiguration.Builder(a)
      // You can pass your own memory cache implementation
     .discCache(new UnlimitedDiscCache(cacheDir)) // You can pass your own disc cache implementation
     .discCacheFileNameGenerator(new HashCodeFileNameGenerator())
     .enableLogging()
     .build();
 // Initialize ImageLoader with created configuration. Do it once.
 imageLoader.init(config);
 options = new DisplayImageOptions.Builder()
 .showStubImage(R.drawable.stub_id)//display stub image
 .cacheInMemory()
 .cacheOnDisc()
 .displayer(new RoundedBitmapDisplayer(20))
 .build();

In your getView()

 ImageView image=(ImageView)vi.findViewById(R.id.imageview); 
 imageLoader.displayImage(imageurl, image,options);//provide imageurl, imageview and options

You can configure with other options to suit your needs.

Along with Universal Image Loader you can view holder for smooth scrolling and performance. http://developer.android.com/training/improving-layouts/smooth-scrolling.html.

http://www.youtube.com/watch?v=wDBM6wVEO70. The talk is about viewholder and performance.

Android: what is the heap size per intent/activity?

2 Answers2