StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I want to try and tackle this from a completely different perspective. Memory trouble on Android = the damn native heap and bitmaps 90% of the time.. But this doesn't add up here. As far as I recall, the native heap has very little limitations and can grow as much as it wants. The only limitation I recall is a manual test in the dalvik GC that makes sure your <strong>used</strong> dalvik heap plus your <strong>used</strong> native heap don't surpass your app heap limit.</p> <p>What if your troubles are not related to the native heap - only your dalvik heap.</p> <p>I assumed that your failing 500kb allocation is in the native heap (for the bitmap pixels). There's a chance this allocation is actually in your dalvik heap. Since your heap is so fragmented, the system cannot find a continuous 500kb chunk in your dalvik heap and you crash.</p> <p>Which bitmap decoding function are you using? Some methods decode directly from a resource to the native heap and some methods (like the ones using a byte array), are decoding from buffers on the dalvik heap which would explain a big allocation there.</p> <p>To fix this either change your bitmap decoding function and make sure it doesn't allocate on the dalvik heap at all, or better yet, let's fix your entire fragmentation problem at the source.</p> <p>Here are some ideas to work around fragmentation issues in general (apply these during your JSON handling part in the beginning):</p> <ol> <li><p>Run <code>System.gc()</code> manually in strategically placed locations. Popular locations are during destruction of large objects like activity onDestroy. Or whenever you finish with a large JSON chunk, throw a manual GC in there.</p></li> <li><p>Assist the System GC free resources faster. This will prevent your heap from becoming fragmented in the first place. Plenty of material on the net on how to do that. Some from the top of my head:</p> <ul> <li>If you have frequent small allocations, try to adopt a memory reuse scheme like making a pool of objects, and reusing objects in the pool instead of allocating new ones. This optimization is often seen in android adapters (like view reuse in listviews)</li> <li>Manually set variables to null when you don't need them in order to explicitly disconnect them from the reference graph and mark them for easy GC (same goes for explicitly clearing data collections)</li> <li>Avoid immutable classes when you have plenty of operations, like concatenation of strings, use <code>StringBuilder</code> instead of regular <code>String</code>s</li> <li>Avoid finalizers completely</li> <li>Avoid circular references, or at least change one of them to a weak reference</li> <li>Use weak references in general where they're needed</li> </ul></li> </ol> <p>You can measure how successful you are by making sure your heap does not grow to huge sizes when you're only using a small part of it</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