StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Mimminito,</p> <p>The issue you are describing plagues many a developer on the Android platform. The reason for this is that when Google implemented View Drawables, they had to make a valid assumption that the previous Drawable may need to be kept. This is because more and more applications on an increasing number of platforms require this behavior.</p> <p>Ultimately, there are several ways to mitigate the issues, but there is no one catch all solution. </p> <ol> <li><p>When you replace the backgrounds, get the original background. If it is a Bitmap, <code>recycle()</code> it. If it is a Drawable, set the reference to null and remove its Callback via <code>setCallback</code> (This is especially important when you are changing orientations or switching Activities).</p></li> <li><p>Graphics are one of the most memory consuming resources. If you are using a Drawable or Bitmap, it uses 4 bytes per pixel. BUT if the image has to be resized to display properly, it actually uses quite a bit more whether the app is upsizing or downsizing. Creating the graphic in high resolution is awesome, but for mobile devices, you want to scale it to the sizes you are actually going to be using.</p></li> <li><p>If you are using a lot of graphics, you might consider using only the ones that are going to be visible. That is, if you have 32 items, but only 3 are visible, only load the 3 that are visible and maybe some immediate neighbors. Lazy Loading can be implemented for a number of the standardized controls.</p></li> <li><p>I recommend looking at .9.png files. These are great for optimizing graphics.</p></li> <li><p>If your buttons have text, do not draw it on the graphic file. Allow Android to place the text on the graphics file. Its treated much differently and the memory consumption is reduced considerably. While it may not be as aesthetically pleasing, it will increase reliability (which is why you are here)</p></li> <li><p>In some cases, it may be desirable to have the graphics be flat bitmaps, rather than a compressed format. This reduces load on the processor and memory, but at the cost of file size. This is because the compressed formats must be decompressed in memory to be used anyway, but the memory isn't freed until the file is actually closed. (This doesn't even include the memory for the runtime code used to decompress it, and is even MORE costly when the app has to resize the graphic).</p></li> <li><p>Putting in some extra System.gc() statements can help ease the load, but it isn't reliable as it only tells the system that it is ready for a garbage collection at its earliest convenience.</p></li> <li><p>Finally, you can have mutliple sizes according to the resolutions of the device. This is information you can transmit via your app. This is how we have to do multiple device support in a local application.</p></li> </ol> <p>All of these suggestions may help, but its a lot of information. Hopefully, I gave you enough for you to implement a solution that will cater to your needs.</p> <p>Hope this helps, FuzzicalLogic</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload