3

Basically my app keeps crashing. However, all my activities have 'finish();', which should end the activity and release the memory (at least that's my understanding). In the same vein, my images are only a few hundred KB if that, saved in the PNG format.

My code has no immediate errors amongst the Java package explorer at least. In DDMS I get the errors listed in the title. Following questions and answers on here I followed the most logical steps for my project but it hasn't worked. So far i've checked image sizes (which are low file sizes) and i've added finish(); to my activities.

Essentially I get about 10 activities in and it crashes. I have a total of around 60 activities, each with a image, imagebutton, and a scrolltextview. Some occasionally have a image on screen that pauses and continues to the next activity. I would post code up, but there's no one page of code that's immediately relevant - or at least that i can parse.

As for the AVD it's just a mid-range with a low SD-Card memory, however, even on a real device from mid-to-high range, the app has the same issues.

Any help is appreciated!

user2769265
  • 55
  • 6
  • Would using Fragments be better for your case? They get loaded and unloaded as needed. – andy256 Sep 18 '13 at 22:38
  • if you do not need to keep certain activities in the back stack, consider calling finish() on them after launching new intents. – John Leehey Sep 18 '13 at 22:41
  • Use MAT to determine where your memory leak resides, if indeed the problem is a true leak. Beyond that, you might consider editing your question to clarify where your images are coming from (resources? local files? downloaded on the fly from the Internet?). – CommonsWare Sep 18 '13 at 22:46
  • *"my images are only a few hundred KB if that, saved in the PNG format."* - Note that the file size is hardly relevant for the memory requirements. At runtime, Android will decode every image into a `Bitmap`, with, usually, 32 bits/pixel (= 4 bytes/pixel). As such, an 512 x 512 px image will require 1 MB of memory on mdpi. The same image on xhdpi will be scaled by a factor 2 in both dimensions, and hence require 4 MB. In short: pixel size will determine memory allocation, not file size. – MH. Sep 18 '13 at 22:57
  • Cheers for the explanation about bit-to-pixel conversion, it furthered my understanding a whole bunch! – user2769265 Sep 19 '13 at 18:12

1 Answers1

3

I've seen that behavior quiet often, first of all let me tell you that finishing an activity doesn't necessarily mean that the OS will release the resources, OS is smart enough to leave some resources around in case that you might decide to open again that activity even when you previously destroyed it, now as you open more activities the OS could decide to completely let go some resources of previous "destroyed" activities since it might need those resources for the newest activity.

Regarding to your memory issue I'm almost sure it has to do with the Image Resizing Mechanism, even when your application has images with just a few KBs, those images might become several MBs if not stored in the proper drawable-folder, because the OS will try to resize those images to fit properly in your activity by using the formula: ImageWidth * ImageHeight * 4Bytes, 1Byte for Alpha/R/G/B, and in the DDMS by tracking the Heap you can notice if when you go to one activity the Heap increases stupidly fast.

In order to make sure the issue is not related to the Resizing Mechanism, put all your drawables in a folder named: drawable-nodpi (This way you tell the OS NOT TO RESIZE), if you see a huge difference in performance then it means that the problem is that your drawables are not properly designed in size per each screen density...

Hope this helps.

Regards!

Martin Cazares
  • 13,637
  • 10
  • 47
  • 54
  • Thanks for such a detailed answer! It's a bit late now but i'll get on it first thing tomorrow and post the results. It makes perfect sense, thanks a lot! – user2769265 Sep 18 '13 at 22:52
  • Thanks a lot for this post! It solved my issues after some further messing around. Basically I lowered the pixel height to about 500 and saved them all in the nodpi folder, and everything is lightning fast with no crashes or memory leaks whatsoever. Thanks for sharing your experience so quickly and efficiently! – user2769265 Sep 19 '13 at 18:11
  • Hehehe, no problem, remember to always have the assets properly designed based on android guidelines this could save you alot of headaches... Regards... – Martin Cazares Sep 19 '13 at 18:21