[android-developers] Memory leaks when using bitmaps in android
I know this question has been asked over and over again in these
forums. But the reason I am posting it again is because I have nt
received a clear answer to it. It would be great if someone could help
me with this.
I am current using opencv + android to make some simple app that will
do image manipulation like edge, blur etc and display it using an
imagebutton. The images are being loaded through the gallery. There
are 3 buttons to blur, edge, and reset to original which will display
the modified image on the image button. given below is my code.
package com.example;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.RandomAccessFile;
import java.nio.Buffer;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.channels.FileChannel.MapMode;
import android.app.Activity;
import android.content.Intent;
import android.graphics.*;
import android.graphics.Bitmap.Config;
import android.net.Uri;
import android.os.Bundle;
import android.os.Debug;
import android.provider.MediaStore;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.ImageButton;
import android.widget.ImageView;
import org.opencv.core.*;
import org.opencv.imgproc.*;
import org.opencv.android.*;
import org.opencv.highgui.*;
import dalvik.system.VMRuntime;
import android.graphics.Color;
public class ImageProcessing extends Activity implements
View.OnClickListener{
private ImageButton choice;
private Button Blur;
private Button Canny;
private Button Reset;
Uri photoUri;
static private Bitmap bitmap;
static private Bitmap mutBitmap;
private static String TAG = ImageProcessing;
private static int TAKE_GALLERY_REQUEST = 2;
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.img);
choice = (ImageButton) findViewById(R.id.imagechoice);
Blur = (Button) findViewById(R.id.Blur);
Canny = (Button) findViewById(R.id.edge);
Reset = (Button) findViewById(R.id.reset);
choice.setOnClickListener(this);
Blur.setOnClickListener(this);
Canny.setOnClickListener(this);
Reset.setOnClickListener(this);
}
@Override
public void onClick(View v) {
if(v.getId() == R.id.imagechoice)
{
Intent pickPhoto = new Intent(Intent.ACTION_PICK);
pickPhoto.setType(image/*);
startActivityForResult(pickPhoto, TAKE_GALLERY_REQUEST);
}
if(v.getId() == R.id.Blur)
{
if(mutBitmap != null)
mutBitmap.recycle();
mutBitmap = bitmap.copy(Config.ARGB_, true);
choice.setImageBitmap(mutBitmap);
Mat mImg = Utils.bitmapToMat(mutBitmap);
Size ksize = new Size(15,15);
Imgproc.blur(mImg, mImg, ksize);
mutBitmap.recycle();
mutBitmap = Bitmap.createBitmap(mImg.cols(), mImg.rows(),
Bitmap.Config.ARGB_);
Utils.matToBitmap(mImg, mutBitmap);
choice.setImageBitmap(mutBitmap);
}
if(v.getId() == R.id.edge)
{
if(mutBitmap != null)
mutBitmap.recycle();
mutBitmap = bitmap.copy(Config.ARGB_, true);
choice.setImageBitmap(mutBitmap);
Mat mImg = new Mat();
mImg = Utils.bitmapToMat(mutBitmap);
/**Converting to grayscale**/
Mat mGray = new Mat(mImg.rows(), mImg.cols(), CvType.CV_8UC1,
new Scalar(0));
Imgproc.cvtColor(mImg , mGray, Imgproc.COLOR_BGRA2GRAY, 4);
/**Applying Canny**/
Imgproc.Canny(mGray, mGray, 80, 90);
//Converting back to 4 channel image
Imgproc.cvtColor(mGray , mImg, Imgproc.COLOR_GRAY2RGBA, 4);
mutBitmap.recycle();
mutBitmap = Bitmap.createBitmap(mImg.cols(), mImg.rows(),
Bitmap.Config.ARGB_);
Utils.matToBitmap(mImg, mutBitmap);
choice.setImageBitmap(mutBitmap);
}
if(v.getId() == R.id.reset)
{
choice.setImageBitmap(bitmap);
}
}
@Override
protected void onPause() {
super.onPause();
Log.v(TAG,on pause called);
Log.v(TAG,Allocated memoryin on pause before recycle done:
+Debug.getNativeHeapAllocatedSize());
choice.setImageBitmap(null);
if(bitmap != null)
{
Log.v(TAG,bitmap is not null);
bitmap.recycle();
if(bitmap.isRecycled())
Log.v(TAG,bitmap is recycled);
bitmap = null;
}
if(mutBitmap != null)
{
mutBitmap.recycle();
if(mutBitmap.isRecycled())
Log.v(TAG,mutBitmap is recycled);
mutBitmap = null;
}
Log.v(TAG,Allocated memory on pause after recycle done:
+Debug.getNativeHeapAllocatedSize());
}
@Override
[android-developers] Memory Leaks in Native Code (No Valgrind)
Hi , I would like to know , how we can identify memory leaks in Native code (C/C++ Libraries). There are tools like Valgrind, but it doesn't support all features for ARM . Do i need to write my Malloc Wrapper or Is there any stuff i need to do with libc or anythin else? Please provide your suggestions. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory Leaks? references help by ApplicationContext and DecorView ok?
Hi All, I've been using Eclipse MAT to find a memory leak in my app. Using the histogram I was able to discover that my Activity had multiple instances if I ran the app twice and then ran the hprof dump. Using that info I fixed one of the context leaks shown by Show GC roots without weak references. Now I only have 1 instance of my activity if I run the app multiple times. There still exist the following strong references to my activity - note these results are from an hprof dump after exiting my app with the home button: Class Name | Shallow Heap | Retained Heap -- com.MyActivity @ 0x43796b98 | 160 | 1,904 |- mOuterContext android.app.ApplicationContext @ 0x43796c98 | 128 | 256 | '- context android.app.ActivityThread$ContextCleanupInfo @ 0x437a7030 | 24 | 136 | '- Java Local java.lang.Thread @ 0x4001ab08 main Thread | 72 | 1,176 |- mContext com.android.internal.policy.impl.PhoneWindow$DecorView @ 0x437bab98| 352 | 760 -- Is this normal? Shouldn't I see no strong references to my activity at this point? Are my bitmaps never going to be garbage collected because of this? (NOTE: I'm using the application context to load them). Any help would be awesome! thanks. Chad -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory Leaks in application
I developed a simple application in which I just logged the Native heap size. Why our native heap size is increased every time we run the application? I logged the size with Debug.getNativeHeapAllocatedSize(). -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Memory Leaks in application
On Thu, Apr 7, 2011 at 5:16 AM, NURAIZ yousuf_...@yahoo.com wrote: Why our native heap size is increased every time we run the application? Based on the detailed information you provided, I can conclude with confidence that it's because you're using more memory every time you run the application. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Memory Leaks with a ListView
John,
I've seen something similar causing memory leaks, preventing GC from
working, although not in Android:
public class Item {
static HashtablegHash = new Hashtable();
private String key;
public Item(String key) {
this.key = key;
gHash.put(key, this);
}
public void finalize() {
gHash.remove(this.key);
}
}
In your example, there is a circular reference, but the entire object is
orphaned. GC should work here, so there must be more to it.
I'd recommend you try switching to a separate class for the adapter.
Making it an non-static inner class of GListView would be quite convenient.
-- Kostya
20.10.2010 8:53, John Gaby пишет:
I have a class 'GListView' which extends ListView and acts as it's own
adapter. It is declared thus:
public class GListView extends ListView implements ListAdapter
In it's constructor, I set it's adapter to itself as follows:
public GListView(Context context ...)
{
...
setAdapter(this);
...
}
I then add this GListView to a ViewGroup. Later I release all
references to the ViewGroup, and yet the ViewGroup and the GListView
are never garbage collected.
Now if I don't do the 'setAdapter(this)' call, everything the garbage
collection works as expected, so it seems that setting the adapter to
itself is creating some kind of circular references that the garbage
collector is not able to sort out
I have tried calling setAdapter(null) when I no longer need the view,
but that does not seem to help.
Is having my GListView act as it's own ListAdapter something I simply
cannot do, or is there some way to make this work?
Thanks.
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory Leaks with a ListView
I have a class 'GListView' which extends ListView and acts as it's own
adapter. It is declared thus:
public class GListView extends ListView implements ListAdapter
In it's constructor, I set it's adapter to itself as follows:
public GListView(Context context ...)
{
...
setAdapter(this);
...
}
I then add this GListView to a ViewGroup. Later I release all
references to the ViewGroup, and yet the ViewGroup and the GListView
are never garbage collected.
Now if I don't do the 'setAdapter(this)' call, everything the garbage
collection works as expected, so it seems that setting the adapter to
itself is creating some kind of circular references that the garbage
collector is not able to sort out
I have tried calling setAdapter(null) when I no longer need the view,
but that does not seem to help.
Is having my GListView act as it's own ListAdapter something I simply
cannot do, or is there some way to make this work?
Thanks.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory Leaks
I appear to have a memory leak(s) in my application, and I am trying
to get a handle on it by trying to understand more about garbage
collection. I have created the following application.
Here I have a class 'MyClass', and I create an instance of that class
in my 'onCreate'. I then null out the pointer which should leave no
references to that instance.
In 'MyClass', I override the finalize method so that I can see when
the object is destroyed. When I run this program, the finalize method
is never called, even if I call System.gc(), from within my program,
or use the 'Cause GC' button using DDMS. (This is the same behavior
that I see in my full application, by the way).
Can someone explain to me more about what is going on here. I believe
that in my main application, that I have objects that are not being
freed. Is there some strategy for identifying those objects?
Thanks.
/*
* Main Activity
*/
package com.gabysoft.memoryleak;
import android.app.Activity;
import android.os.Bundle;
public class MemoryLeak extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
MyClass mc = new MyClass();
mc = null;
setContentView(R.layout.main);
System.gc();
}
}
/*
* My Class
*/
package com.gabysoft.memoryleak;
import android.util.Log;
public class MyClass extends Object
{
MyClass()
{
Log.d(GabySoft, MyClass::MyClass() + this);
}
@Override
protected void finalize()
{
Log.d(Gabysoft, MyClass::finalize() + this);
}
}
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Memory Leaks
On Mon, Oct 18, 2010 at 4:58 PM, John Gaby jg...@gabysoft.com wrote: I appear to have a memory leak(s) in my application, and I am trying to get a handle on it by trying to understand more about garbage collection. I have created the following application. Here I have a class 'MyClass', and I create an instance of that class in my 'onCreate'. I then null out the pointer which should leave no references to that instance. In 'MyClass', I override the finalize method so that I can see when the object is destroyed. When I run this program, the finalize method is never called, even if I call System.gc(), from within my program, or use the 'Cause GC' button using DDMS. (This is the same behavior that I see in my full application, by the way). Can someone explain to me more about what is going on here. I believe that in my main application, that I have objects that are not being freed. Is there some strategy for identifying those objects? Thanks. Ok, few things first: - Android does not reclaim the memory straight away even after the application gets closed. - System.gc() does not guarantee garbage collection in a timely manner. - When overriding finalize() you have to call super.finalize(). The fact that you did not see the log from finalize() does not mean it did not happen. Daniel -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
回复： [android-developers] Memory leaks???
My God. The statements to send messages cause memory leak. I should use the
following statements instead.
Message message = m_handler.obtainMessage();
message.what = 1;
message.what = obj;
message.sendToTarget();
--- 10年5月21日，周五, Jiang webs...@yahoo.cn 写道：
发件人: Jiang webs...@yahoo.cn
主题: [android-developers] Memory leaks???
收件人: android-developers@googlegroups.com
日期: 2010年5月21日,周五,上午11:50
1, In a thread, I send a gread many of messages with followign statements:
Message message = new Message();
message.what = 1;
message.what = obj;
m_handler.sendMessage(message)
message = null;
2, In a acvity
class MyActivity extends Activity
{
class MyHandler extends Handler
{
public void handleMessage(Message msg)
{
handleActivityMessage(msg);
}
}
public handleActivityMessage(Message msg)
{
}
}
When returned from MyActivity, System.gc() is called, but I found the memory
usage grows compared to the stage before entering MyActivity, does memory leak
during message processing?
Thanks.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory leaks???
1, In a thread, I send a gread many of messages with followign statements:
Message message = new Message();
message.what = 1;
message.what = obj;
m_handler.sendMessage(message)
message = null;
2, In a acvity
class MyActivity extends Activity
{
class MyHandler extends Handler
{
public void handleMessage(Message msg)
{
handleActivityMessage(msg);
}
}
public handleActivityMessage(Message msg)
{
}
}
When returned from MyActivity, System.gc() is called, but I found the memory
usage grows compared to the stage before entering MyActivity, does memory leak
during message processing?
Thanks.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory leaks in activities and views
We found there are very nasty memory and resource leaks in activities and views that we don't know how to handle. I have test app that basically starts activity A, that immediately starts activity B and B starts A and so forth in infinite loop. Each activity displays its own bitmap in image view. After X cycles JVM runs out of memory. There are no static or any other references to bitmaps or views or anything else. It seems that when one activity launches another a new instance of that activity is created (constractor is called, then onCreate, then onResume, the launching activity is paused and its onPause is called). onDestroy is almost never called. When new instance is created old one probably still holds references to view and bitmap so they are not freed. The only way we found to prevent JVM from running out of memory is to do ALL this from onPause and onDestroy: 1. Get image view drawable and set its callback to null. 2. Set image view background drawable to null. 3. Set ANOTHER view to activity (probably this removes activity reference from the image view). 4. Get the bitmap, call its recycle() method, set its handle to null and then run GC with System.gc(). If ALL these steps are executed JVM flips these image activities infinitely without running out of memory. Obviously, it is very hard to implement this solution when you have complex view with zillion of different images and more then a dozen of activities. What's the best and proper solution to aforementioned problem? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Memory leaks in activities and views
There must be something else going on in your app. All standard apps rely on onDestroy() being called and certainly do not do all you mentioned in your message. Be very careful with what you do with the Context. An Activity is a Context and you might be leaking it without knowing it. What you are observing is definitely not a normal behavior. On Mon, May 17, 2010 at 3:20 PM, ls02 agal...@audible.com wrote: We found there are very nasty memory and resource leaks in activities and views that we don't know how to handle. I have test app that basically starts activity A, that immediately starts activity B and B starts A and so forth in infinite loop. Each activity displays its own bitmap in image view. After X cycles JVM runs out of memory. There are no static or any other references to bitmaps or views or anything else. It seems that when one activity launches another a new instance of that activity is created (constractor is called, then onCreate, then onResume, the launching activity is paused and its onPause is called). onDestroy is almost never called. When new instance is created old one probably still holds references to view and bitmap so they are not freed. The only way we found to prevent JVM from running out of memory is to do ALL this from onPause and onDestroy: 1. Get image view drawable and set its callback to null. 2. Set image view background drawable to null. 3. Set ANOTHER view to activity (probably this removes activity reference from the image view). 4. Get the bitmap, call its recycle() method, set its handle to null and then run GC with System.gc(). If ALL these steps are executed JVM flips these image activities infinitely without running out of memory. Obviously, it is very hard to implement this solution when you have complex view with zillion of different images and more then a dozen of activities. What's the best and proper solution to aforementioned problem? -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Memory leaks in Android Application / Framework
Hello again, We've been chasing a wide variety of memory leaks or things that look like potential memory leaks in our program that uses MapViews heavily. The diagnosis so far is sadly not great. I'm hoping someone can help. I've filed a bug on this, but I am looking for advice from people or comments about whether or not they see the same behavior. I am guessing that there is stuff in the Maps application that works around at least some of these issues. I am attaching 3 screenshots of the Eclipse Memory Analyzer: 1) Shows the MapActivity (subclassed by HistoryDetailsActivity for us) not releasing their connection to system classes, and thus being held in memory. http://android.googlecode.com/issues/attachment?aid=-6844645649729699418name=MapActivity_leaks.PNG Are there any Android Maps calls that you know that can help avoid this? 2) Shows maps using 23% of process memory (600K at this point) after zooming and panning the map for 20 seconds. This is normally okay, since this is a cache, but the cache looks like it's not using SoftReferences, which seems to make it inflexible/unusuable for apps that actually do want to use the memory. (http://android.googlecode.com/issues/attachment? aid=-1304590382087797856name=Maphog23percent_afterzoomdragresize.PNG http://android.googlecode.com/issues/attachment?aid=-5424879574327685477name=MapTiles_lnoweakrefs.PNG) In conclusion, I just wanted to make a wish: let's make more of the maps stuff open source, so people like me can fix these issues. Except for a tiny part of the code, there is no good reason to keep anything closed. P.S. I've added all of this info to: http://code.google.com/p/android/issues/detail?id=2181 -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] memory leaks
can anyone tell me any solution or tool provided by Android to find the exact place of memory leaking? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] memory leaks
Any idea how to track memory leaks in android...I am looking for specific answers Thanks Android guy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Memory Leaks, sigh
Hi I'm trying to track down memory leaks in my application. It seems the total amount of memory the app really needs is perhaps around 3MB (Maximum, on average it's around 2.1MB). There's only one activity in the whole app which uses max amount of memory. However, every time I switch from that activity back to the main entry- point activity (which shows the user an index of available options), it seems the previous activity was not garbage collected. I have the following concerns: 1. I'm not sure if this is because I've kept a reference to some global resource in the previous activity that it's not being collected 3. I'm not sure if this is how Android works, i.e. GC on activities are delayed. I'm using a lot of drawables (included as assets and resource) in the other memory-hogging activity. Am I supposed to 'reset' the views somehow in order to remove the reference to these globally accessible resources? I'm also reading a number of files from the SD Card (saved/ created in a separate activity). Or am I supposed to somehow ensure that the activity is 'killed' in a way? In order to get back to the main Index (from which the user navigates to the other activity), I'm simply calling startActivity(new Intent(com.blah.MAININDEX)); Any help would be much appreciated. I'm not sure if I completely understand how references are incremented and decremented for a given view in Android. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
