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 code, and the exact same resource (in the 'drawable' folder) on the Droid, I get a larger bitmap; I don't remember the exact size, but I'll guess 86x86 pixels. It's the same image, stretched by Android so that when rendered, it will take approximately the same real screen space (not pixel space). So, if I wanted to always get the raw 64x64 image, I'd need to do one of: 1) Load the image scaled, or 2) Place the 64x64 image in the "drawable-hdpi" folder I hope that's clearer. If you find a good resource for advice, please share :-) SoftwareForMe.com Makers of PhoneMyPC & Imagine Multi-touch On Thu, Dec 3, 2009 at 12:22 AM, Matt Kanninen <mathias...@gmail.com> wrote: > "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 margins. > > I, like a great many Android developers, had to re create the look and > feel that was established with our iPhone application. On the droid > we had gradient banding so we pre dithered a png, but that was the art > guy. The layouts could be simpler, but I have already repeatedly > simplified them from the first version that had the right look and > feel. > > I have some FrameLayouts, containing RelativeLayouts, containing > single Views. It seems like RelativeLayout has been redone and is > less brittle then I remember it, so I probably can start skipping the > FrameLayouts. Framelayouts just seem like the simple easy way to > control over lap of views, and I often have 4 over lapping views. I > also have some linear layouts in side other linear layouts, but all > with different weights. > > The 1 or 2 pixel differences between 1.5,1.6 and 2.0 make our > application look worse on the Hero. I use ListViews, that sometimes > are populated by CursorAdapters. I have gone back and forth between > letting the activity manage the cursors, and managing them myself. > > (I'm referencing AdMob and other's numbers to try and figure out what > Android versions I need to support, and what handsets I need to test > on > http://daringfireball.net/linked/2009/11/23/admob ) > > Much of the code for "my" app was written for Android 1.0, 1.1 etc. > and it has been maintained by different developers over the years. > > Now I guess my task is to go over every line of code and reduce how > much memory is used. I've tried to check every static reference that > wasn't a private static final constant primitive, to make sure we > weren't hindering garbage collection. I don't think I ever store a > context, but we pass them around everywhere as arguments. I can't > really recycle my drawables because I'm not managing them, I just call > setContentView. > > My activities have some member variables, views, etc. I create some > handlers, but more often just call runOnUiThread. I guess I can > explicitly set these to null in onStop... when I hear "improve memory > management" my first response is to set things null, my problem is the > unusual lifecycle of an Android application, it's activities, and it's > static variables. I'm already prepared for my major static variables, > strings, to unexpectedly become null, and write my strings to a > private preference, or save my camera or microphone content as a > private application file. > > It's all pretty vanilla. The networking is done using some included > apache jars, I guess I could redo all my networking to use something > else, that would make it even more vanilla. But I will probably wait > until my application becomes less vanilla and we need a push solution. > > SoftwareForMe, I have read your post a couple times now, I think it's > clear to me now. Generating a new version of most or all of our PNGs, > especially our largest, sounds like a good idea. Is there a good blog > post I can send to the art guy so he can understand what he needs to > do? I'd like not to have to go 11 more revisions on each asset. > > It'd be real cool if there was an easy way to just remove all my > unused PNGs from my project, before I double them. I have not go > through and removed every PNG that is no longer being referenced yet. > > My 2 cents, > Matt Kanninen > Android Developer > > On Dec 2, 8:38 pm, "SoftwareForMe.com SoftwareForMe.com" > <softwareforme....@gmail.com> wrote: > > 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 higher resolution screen show more of the game map at a > time, > > your program will consume NEARLY identical memory to what it would on > other > > devices. Why? Because the tiles will be the same size in memory; the only > > thing that would be larger would be the screen surface, and any back > buffers > > you use. > > > > On the other hand, if you want the graphics on the Droid to look the same > > (same game play area visible), then without work, your application will > take > > more memory on the Droid. Why? Because unless you explicitly avoid it, > > Android will scale your image up to higher resolution when you load them, > so > > they take more memory. > > > > The solutions are to: > > 1) Create high-density images that are simply smaller, but occupy the > same > > number of pixels. This way, loading resources on the denser devices won't > > take any memory, or > > 2) Resize the images after you load them, understanding that loading the > > exact same resource on two different devices may result in two different > > sized bitmaps in memory > > > > Of course approach #1 is the standard solution. > > > > I hope I am being clear. In short, if you want higher quality graphics, > of > > course they will take more memory. If you want the same exact graphics > > (which will appear smaller on the denser screen), then you must do the > work > > to make that happen, as it sounds like you are not now, so Android is > > scaling them up. > > > > SoftwareForMe.com > > Makers of PhoneMyPC > > > > On Wed, Dec 2, 2009 at 6:12 PM, Jason Proctor < > jason.android.li...@gmail.com > > > > > wrote: > > > 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 12/2/09, Romain Guy wrote: > > > >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 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 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 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 memory crash that occured during > > > > > >>> > glow.setBackgroundResource(glowDrawableIds[scale]); > > > > > >>> > We just don't set a new background resource anymore. > > > > > >>> > I had 10 animation frames, and the animation frame chosen was > based > > > >>> > upon the volume coming from the mic. > > > > > >>> > Now we take what was the last frame, and vary it's drawable's > > > >>> > transparency depending on volume. > > > > > >>> > glow.getBackground().setAlpha(alpha); > > > > > >>> > I will now start creating additional res/xml/files, so that LESS > > > >>> > complex layouts are used on the Verizon Motorola Droid with > firmware > > > >>> > 2.0 then we used on the G1. > > > > > >>> > The layouts, and the final resulting screens were approved by > > > >>> > management, so I will be trying hard not to change ANYTHING on > the > > > G1, > > > >>> > while adding support for the inferior memory handling on the > only > > > >>> > Android 2.0 handset. The one with better specs. > > > > > >>> > Can anyone recommend which Android debugging tool I should be > using > > > to > > > >>> > figure out what to optimize? > > > > > >>> > On Nov 25, 11:11 am, Streets Of Boston <flyingdutc...@gmail.com > > > > > >>> > wrote: > > > >>> >> 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 the size of your screen, if > possible. > > > Use > > > >>> >> BitmapFactory.decode and set the 'inSampleSize' of your > > > bitmap-options > > > > >> >> to scale down the size of the bitmap to be loaded and rendered > on > > > the > > > >>> >> screen. > > > > > >>> >> On Nov 25, 12:46 pm, MattKanninen<mathias...@gmail.com> wrote: > > > > > >>> >> > <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, MattKanninen<mathias...@gmail.com> > wrote: > > > > > >>> >> > > This: > > > >>> >> > > private static final int[] glowDrawableIds={ > > > >>> >> > > R.drawable.graphic_microphoneglow_01, > > > >>> >> > > R.drawable.graphic_microphoneglow_02, > > > >>> >> > > R.drawable.graphic_microphoneglow_03, > > > >>> >> > > R.drawable.graphic_microphoneglow_04, > > > >>> >> > > R.drawable.graphic_microphoneglow_05, > > > >>> >> > > R.drawable.graphic_microphoneglow_06, > > > >>> >> > > R.drawable.graphic_microphoneglow_07, > > > >>> >> > > R.drawable.graphic_microphoneglow_08, > > > > >> >> > > R.drawable.graphic_microphoneglow_09, > > > >>> >> > > R.drawable.graphic_microphoneglow_10 > > > > >> >> > > }; > > > >>> >> > > ... > > > >>> >> > > View glow = findViewById(R.id.glow); > > > >>> >> > > .. > > > > > >>> >> > > glow.setBackgroundResource(glowDrawableIds[scale]); > > > > > >>> >> > > is causing > > > > > >>> >> > > 11-25 09:21:02.046: WARN/UsageStats(1018): Failed to > > > >>>persist new stats > > > >>> >> > > 11-25 09:21:02.694: DEBUG/dalvikvm(2386): GC freed 298 > > > >>>objects / 15656 > > > >>> >> > > bytes in 61ms > > > >>> >> > > 11-25 09:21:02.952: ERROR/dalvikvm-heap(2386): 1111680-byte > > > external > > > >>> >> > > allocation too large for this process. > > > >>> >> > > 11-25 09:21:02.952: ERROR/(2386): VM won't let us allocate > > > 1111680 > > > >>> >> > > bytes > > > >>> >> > > 11-25 09:21:02.952: DEBUG/AndroidRuntime(2386): Shutting > down > > > VM > > > >>> >> > > 11-25 09:21:02.952: WARN/dalvikvm(2386): threadid=3: thread > > > exiting > > > >>> >> > > with uncaught exception (group=0x4001b180) > > > >>> >> > > 11-25 09:21:02.952: ERROR/AndroidRuntime(2386): Uncaught > > > handler: > > > >>> >> > > thread main exiting due to uncaught exception > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): > > > >>> >> > > java.lang.OutOfMemoryError: bitmap size exceeds VM budget > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.graphics.Bitmap.nativeCreate(Native Method) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.graphics.Bitmap.createBitmap(Bitmap.java:468) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.graphics.Bitmap.createBitmap(Bitmap.java:435) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.graphics.Bitmap.createScaledBitmap(Bitmap.java:340) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > > > android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:488) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > > > android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:462) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > > > > >>>android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java: > > > >>> >> > > 323) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.graphics.drawable.Drawable.createFromResourceStream > > > >>> >> > > (Drawable.java:697) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > > android.content.res.Resources.loadDrawable(Resources.java:1705) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > > android.content.res.Resources.getDrawable(Resources.java:580) > > > >>> >> > > 11-25 09:21:03.014: ERROR/AndroidRuntime(2386): at > > > >>> >> > > android.view.View.setBackgroundResource(View.java:7187)- > > > >>>Hide quoted text - > > > > > >>> >> > - Show quoted text - > > > > > >>> > -- > > > >>> > 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<android-developers%2bunsubscr...@googlegroups.com> > <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@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 > > > > ... > > > > read more ยป > > -- > 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<android-developers%2bunsubscr...@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
