I'll assume response is a String. The reason why you are still seeing the whole response data is because of how Strings are implemented in Java. For instance, if you have a 100kB String and you write the following:
String a = // 100kB; String b = a.substring(0, 1); return b; The String b shares the same data as String a but "shows" only 1 character. Thus if you GC the String a, the data is still held onto by String b. >From your observations it seems like the split() method works in a similar way and causes you to keep a reference to the original response data. You can try to fix this by replacing your fields[*] statements with new String(fields[*]). This will create copies that won't share the original response data. On Fri, Dec 4, 2009 at 6:59 AM, freezy <[email protected]> wrote: > Hello, > In my app, I'm fetching data via HTTP and use the response string to create > an ArrayList of objects. So what I'm doing once I get the response is: > String[] fields = response.split("<field>"); > and use the field[] values like this: > ArrayList<Movie> movies = new ArrayList<Movie>(); > for (int row = 1; row < fields.length; row += 9) { > movies.add(new Movie(fields[row], fields[row + 1], ..., fields[row + 8]); > } > Now, when I load the heap dump of the app into Eclipse's Memory Analyzer > Tool[1], the response string still shows up (about 800KB - 28%), as well as > the ArrayList (245KB - 8.7%). I suppose the size of the ArrayList is about > right, since some of the field values are stored as integers and there is no > overhead of the <field></field> tags. > But I don't understand why the response string is still living. I've tried > setting response = null after creating the array, but it still shows up. > Shouldn't it be GCed? Then when I go back to my home activity, leaving the > activity that fetched the data and kept the ArrayList in its adapter, both > objects *still* show up. Does that mean there is a leak somewhere? Android > is supposed to destroy a closed activity and its references (if not > referenced elsewhere), right? > I've read Romain's blog entry about memory leaks and some more other blog > entries like this[2] and this[3] one but I still can't figure this out. My > real code can be found here[4]. > Suggestions and hints appreciated! > > [1] http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-android.html > [2] http://java.dzone.com/news/how-fix-memory-leaks-java > [3] http://kohlerm.blogspot.com/2009/02/memory-leaks-are-easy-to-find.html > [4] http://code.google.com/p/android-xbmcremote/source/browse/trunk/XBMC%20Remote/src/org/xbmc/httpapi/client/VideoClient.java#221 > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer [email protected] 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 public forums, where I and others can see and answer them -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
