"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> > > >>> > 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
