The callback onLowMemory() of my Activity kept on being called and so to investigate the issue, I wrote the following lines of code in the main game loop:
ActivityManager activityManager = (ActivityManager) Activity.getActivity().getSystemService(Activity.ACTIVITY_SERVICE);
MemoryInfo mi = new MemoryInfo();
activityManager.getMemoryInfo(mi);
Log.v("Tag", "Testing mem: " + mi.availMem);
The logs were very interesting: the availMem kept on decreasing. Now to make sure objects were being destroyed properly I I took hprof memory dumps. The objects that were being destroyed, as expected, are not showing in those dumps.
Also, availMem is supposed to be memory available to the whole system and not just my app, which makes it even weirder.
Can anybody help me understand whats going on here. Any help would be much appreciated. Thanks!
Related
I am writing android renderscript code which requires back to back kernel calls (sometimes output of one kernel become input of other). I also have some global pointers, binded to memory from Java layer. Each kernel updates those global pointers and outputs something. I hav e to make sure that execute of kernel1 is finished, before kernel2 starts execution.
I looked at android renderscript docs, but couldn't understand syncAll(Usage) and finish() well. Can anyone clarify how to achieve this behaviour?
Thanks
mScript.forEach_kernel1(mColorImageAllocation, tempAlloc);
// make sure kernel1 finishes, from android rs doc, copyTo should block
tempAlloc.copyTo(testOutputBitmap);
for (short i = 0; i < NUM_DIST; i++) {
mScript.set_gCurrentDistanceIndex(i);
mScript.forEach_kernel2(tempAlloc);
mRS.finish(); // wait till kernel2 finishes
}
In the above example, same kernel2 is called with different global parameters on kernel1's output.
For this code you don't need either. RS is a pipeline model so any work which could impact the result of a later command must be finished first by the driver.
syncAll() is used to sync memory spaces not execution. For example to propagate changes from script memory to graphics memory.
I had a user comment that after viewing a bunch of images in my app, it crashes (he believes that it is due to out of memory error). I have the following relevant code:
int themeID = mNav[mPos];
String icon = getThemeData(DbAdapter.KEY_ICON, themeID);
ImageView viewer = (ImageView)findViewById(R.id.viewer);
Bitmap bMap = null;
try {
bMap = getJPG(icon + ".jpg");
} catch (IOException e) {
e.printStackTrace();
}
viewer.setImageBitmap(bMap);
That gets reran as the user flips between images. From here I see that you should call recycle() on bitmaps. Do i need to call it on bMap after setting the image? Or is there some way to pull it from viwer prior to setting the next one?
According to the documentation for recycle (if I call it on bMap) it appears I don't need to use it: This is an advanced call, and normally need not be called, since the normal GC process will free up this memory when there are no more references to this bitmap.
If you need to explicitly call recycle() it probably means that you have memory leak. Calling it is almost never a solution.
Did you try to check your app for potential mmory leak?
To check it you can for example rotate your device a few times and check how the Garbage Collector behaves. You should have something like GC_... freed 211K, 71% free 300K/1024K, external 0K/0K, paused 1ms+1ms in your LogCat nearly every time you rotate. Watch for changes in this part: 300K/1024K. If you don't have memory leaks, the first part should grow and then get smaller after a few GCs. If you have a memory leak, it will grow and grow, to the point of OOM error.
Check out my other answer about a memory leak.
If you're sure you don't have a leak and you're operating on Honeycomb you can increase the heap size accessible for your app like this: android:largeHeap="true" but it's only recommended when you deal with some huuuge bitmaps or videos, so don't overuse it.
I have an app which consists of a service and some activities. The running size of app reported by settings is around 15MB which seems excessive to me. Eclipse MAT reports total size as only 2.2 MB in Leak Suspects. My questions are:-
Is my service running size actually only 2.2 MB ?
Is the 15 MB reported by settings something to do with backstack of activities and therefore I need not be worried ?
Thanks
use this code hope this help you
MemoryInfo mi = new MemoryInfo();
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
activityManager.getMemoryInfo(mi);
long availableMegs = mi.availMem / 1048576L;
Log.e("Avaliable start", " "+availableMegs);
I get a clasical "VM budget excedees memory - out of memory" type error crash report from the Android Market.
I checked the app for memory leaks over and over again. This error happens on a very small percent of total application installs, around 1-2% and it always happens on start-up. The app loads some bitmaps from internal memory for each activity, but does not crash on most devices. I thought all applications had a guaranteed minimum stack size for bitmaps so this should work for every device. Min SDK is 7.
Any reason why ? Does this sound familiar to anyone ?
I had quite a similar problem, and my images were simply too big for some devices.
I have read that you have one image per Activity and I guess this happens when switching from one to another as the newly allocated Drawable cannot fit. What you could do, to save some memory, would be to unload the background image of the Activities that are not shown:
#Override
protected void onResume() {
super.onResume();
Drawable d = loadMyDrawableFromDisk();
setBackgroundDrawable(d);
}
#Override
protected void onPause {
setBackgroundDrawable(null);
super.onPause();
}
It may help as the memory will be freed a few after onPause() is called, and not when the underlying View of your Activity will be unallocated by the system.
I've read How do I discover memory usage of my application in Android? and a bunch of other answers, but can't quite nail this down...
I have an Activity that will load a file from external storage into memory and do some parsing/manipulation/etc in-memory. Before I load it I want to guess whether or not doing so will cause an OutOfMemoryException and crash the Activity (I understand that exact answers aren't possible, an estimate is better than nothing.)
From the above-linked answer, I came up with:
ActivityManager activityManager = (ActivityManager) getApplicationContext().getSystemService(ACTIVITY_SERVICE);
MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(memoryInfo);
int pid [] = {android.os.Process.myPid()};
android.os.Debug.MemoryInfo[] mi = activityManager.getProcessMemoryInfo(pid);
// calculate total_bytes_used using mi...
long available_bytes = activityManager.getMemoryClass()*1024*1024 - total_bytes_used;
So, the questions:
1) am I crazy?
2) how to total the values from the MemoryInfo object to estimate the heap usage of the activity/task? (The above link gives an overview of pss/private-dirty/shared-dirty, but not enough info to guess how to do the total.)
3) does Debug always exist or only when debugging?
4) is there a smarter way?
Answers like these: Two questions about max heap sizes and available memory in android seem to imply that there isn't a better way than this?
I know that using less memory is a good thing, and I am. I'm interested to know how to code defensively, here. Seems weird to just wait for an exception to know that you're out of memory.
Thanks!
you may refer to this link.. A complete reserach on the same problem you are facing.
OOMRESEACH