None of the tools I know work well with images and I'm not sure how to
improve that. One way might be to use adb shell tools like dumpsys and
compare the numbers over time, I heard. Not very convenient.
I'm checking the difference between PNG8 and PNG24 now. From my
understanding this could save
Hi Romain,
Is there a list somewhere of devices with 24Mb per process ? Is there
a way to adjust this in the emulator ? Is there an API method allowing
to know the total memory available for the process ?
I'm writing a pictures manipulating app, and handling hires pics is
hard with only 16Mb.
Hi Kevin:
I think the memory for high megapixel images is not so important because u
usally will stream the image through a InputStream onto disk. You can then
read the image via BitmapFactory and set a inSampleSize to retrieve it.
BR,
Seb, starting up a WIKI for android memory issues..
On Fri,
That's right but there is some limitation though. I can't find a way to zoom
on a detail of an hires JPEG, for example.
Kevin
On Fri, Jun 25, 2010 at 8:41 AM, Sebastian Roth sebastian.r...@gmail.comwrote:
Hi Kevin:
I think the memory for high megapixel images is not so important because u
Are any of those tools helpful with bitmaps?
I've analyzed an HPRof where all the bitmaps are taking up32 bytes.
that would be nice if it were true. I know that bitmaps are not on the
regular heap, so the tools don't seem to find them.
Since the bitmaps are marked as purgeable, they could be
Hi Matt,
you could try explicitly freeing the resources your bitmaps use by
invoking Bitmap.recycle(). The description of this method reads
Free up the memory associated with this bitmap's pixels, and mark the
bitmap as dead, meaning it will throw an exception if getPixels() or
setPixels() is
If you're nulling your static bitmap in onPause why is it static to begin
with?
E.g. to have access to bitmaps outside of my activity, in classes that
don't have reference to my activities.
Or, in case there can be multiple instance of an activity, these
instances can share 'expensive' data.
You catch out of memory? I wasn't willing to do that yet, but it
would solve all my problems...
On Dec 11, 7:09 am, Streets Of Boston flyingdutc...@gmail.com wrote:
If you're nulling your static bitmap in onPause why is it static to begin
with?
E.g. to have access to bitmaps outside of my
It appears that static members of activity remain allocated and
referenced between consecutive runs of Activity. I can actually draw
the bitmap from the previous launch -- in a new launch (between finish
() calls). It's still there.
So not only is memory of static members not deallocated (which
On Dec 8, 12:28 pm, skominac stevan.komi...@gmail.com wrote:
So not only is memory of static members not deallocated (which is
actually not surprising), but the static references are still alive,
pointing to the memory, and can be used to invoke the members back.
This last part was surprising
I recommend the only things you make static be strings, and that for
everything else you are considering making static, instead write it to
file and use static methods, that expect to be passed a context, to
access the data.
I think my problems might be camera related, so my plan is to stop
using
Statically held (caches of) bitmaps may come in very very handy.
However, as soon as you do hold static references to 'expensive'
resources, be sure to have a proper clean-up strategy. E.g. make sure
the capacity of your cache of bitmaps is limited. Be sure to set the
static reference to null when
I don't get it. If you're nulling your static bitmap in onPause why
is it static to begin with?
Also what you want to do is probably very different for a game that is
basically all taking place in one activity and trying to avoid garbage
collecting at all, compared to your standard Android app
On Dec 6, 10:23 pm, Romain Guy romain...@android.com wrote:
How come you still have a reference to your bitmap when a new Activity
is created?
That confuses me, too, actually. I really want to find out how I made
this happen.
If you have this bitmap somewhere else than within the
Activity,
I had a similar issue. Calling finish() on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I
How come you still have a reference to your bitmap when a new Activity
is created? If you have this bitmap somewhere else than within the
Activity, then it's perfectly normal that it's not de-allocated when
the Activity disappears. In addition, if your Activity is not garbage
collected, you
My app involves taking a picture with the camera, or recording voice
using the microphone, and sending the results to the server. It's a
search tool. The UI isn't very complicated, as much as possible it is
done in XML. For the droid we added some layouts in res/long that
differ only in layout
Hi Matt,
I'm not aware of any other source. This we learned on our own on Friday,
November 6th (Droid release day :-)
To put it simply, say I have a 64x64 .png resource and use:
Bitmap b = BitmapFactory.decodeResource(...)
I will get a 64x64, 32-bit in-memory bitmap.
If I use the exact same
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and poorer performance,
blame it on your app for doing the wrong thing and abusing the Java
heap.
The app worked
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy romain...@android.com wrote:
The Droid has more pixels and a high display density, therefore
bitmaps
The new device does not have stricter limitations since it gives apps
more RAM (24 MB instead of 16 MB.)
On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen mathias...@gmail.com wrote:
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter
The same code works great on the G1 and the MyTouch. We've done some
testing on the Hero, and the Moment, but only on the Droid is the
issue significant. I've told my boss that I am spending time porting
to the Droid.
You have explained that bitmaps are scaled and require more memory.
This
IMHO, if the device offers 50% more memory per application, but the
bitmaps take up more than 50% more memory, then the net effect is a
stricter limitation.
i'm seeing some occasional OOMs only on Droid, and so i'm being extra
careful about recycling bitmaps and all that.
At 5:40 PM -0800
The bitmap issue on the Droid is really about whether you want to show more
graphics at smaller size, or the same graphics at larger size.
I don't know what you app does, but imagine that it's a 2d game, where the
graphics are re-used a lot (land tiles, character icons, etc.).
If you let the
a href=http://code.google.com/p/android/issues/detail?id=5045;Issue
5045/a
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen mathias...@gmail.com wrote:
This:
private static final int[] glowDrawableIds={
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to
Great guesses!
This happens randomly through my application, every half hour on a G1,
every 5 mins on the droid. The error happens randomly, usually in
setContentView, per another post of mine.
On Nov 25, 11:11 am, Streets Of Boston flyingdutc...@gmail.com
wrote:
As in the comment in your
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
Thank you, this is exactly the sort of workaround I was looking for.
I just filed the Media Recorder release bug, since the first bug got
closed so fast.
http://code.google.com/p/android/issues/detail?id=5047
On Nov 25, 11:43 am, Matt Hall matt.h...@gmail.com wrote:
Yeah, we've had a similar
I do this in my app as well, and it works fine using BitmapFactory.
But i make sure that this large bitmap (full-size image, 6Mpix) is
about the only one loaded in my application. If not, i get the same
exception.
Opening 2 of these large ones will give me this exception, whatever i
do.
On Apr
I've tried the unbind method and it doesnt seem to help my case :( It
is a good thing to know and keep in mind.
Rohit
On Jan 23, 2:07 pm, JP joachim.pfeif...@gmail.com wrote:
There's a bunch of discussions about this issue in this forum, just
dig a little and you will find what you need to
It seems that there my be a bug, memory leak with the BitmapFactory
when decoding, and reading bitmaps from file. I, and many other
developers have noticed similar problems to what you describe. I
haven't been able to get any official confirmation that this is a
known bug, but it looks like a
There's a bunch of discussions about this issue in this forum, just
dig a little and you will find what you need to know.
Also, Romain Guy posted a write-up about un-binding views (and
bitmaps) from activities.
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
Admittedly,
36 matches
Mail list logo
