2013-01-23 16 views
5

Ich habe ein Problem, das mich wild macht. Ich habe Google Map API V2 in meinem Code und wenn ich die Karte bewegen kann ich die folgenden Logcat-Ausgang (am Nexus 7) siehe:Heap wächst in Google Map API V2

01-23 21:17:10.724: D/dalvikvm(5484): GC_FOR_ALLOC freed 4531K, 21% free 12911K/16312K, paused 29ms, total 29ms 
01-23 21:17:10.724: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.043MB for 285724-byte allocation 
01-23 21:17:10.744: D/dalvikvm(5484): GC_FOR_ALLOC freed 200K, 22% free 12990K/16592K, paused 25ms, total 25ms 
01-23 21:17:12.074: D/dalvikvm(5484): GC_FOR_ALLOC freed 1326K, 23% free 12893K/16592K, paused 30ms, total 31ms 
01-23 21:18:04.854: D/dalvikvm(5484): Debugger has detached; object registry had 1 entries 
01-23 21:18:07.374: D/dalvikvm(5484): GC_FOR_ALLOC freed 658K, 23% free 12904K/16592K, paused 27ms, total 27ms 
01-23 21:18:07.384: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.763MB for 1048592-byte allocation 
01-23 21:18:07.404: D/dalvikvm(5484): GC_FOR_ALLOC freed 2K, 21% free 13925K/17620K, paused 27ms, total 27ms 
01-23 21:18:07.714: D/dalvikvm(5484): GC_FOR_ALLOC freed 2127K, 26% free 13054K/17620K, paused 29ms, total 29ms 
01-23 21:18:44.694: D/dalvikvm(5484): GC_CONCURRENT freed 1894K, 27% free 12970K/17620K, paused 4ms+5ms, total 56ms 
01-23 21:18:46.684: D/dalvikvm(5484): GC_CONCURRENT freed 1738K, 27% free 12996K/17620K, paused 4ms+2ms, total 53ms 
01-23 21:18:49.254: D/dalvikvm(5484): GC_CONCURRENT freed 1756K, 27% free 13014K/17620K, paused 2ms+8ms, total 77ms 
01-23 21:18:56.864: I/dalvikvm(5484): Jit: resizing JitTable from 8192 to 16384 
01-23 21:18:56.934: D/dalvikvm(5484): GC_CONCURRENT freed 1840K, 21% free 13010K/16312K, paused 2ms+4ms, total 49ms 
01-23 21:18:59.434: D/dalvikvm(5484): GC_CONCURRENT freed 1779K, 21% free 12995K/16312K, paused 4ms+5ms, total 50ms 
01-23 21:19:03.414: D/dalvikvm(5484): GC_CONCURRENT freed 1781K, 21% free 13007K/16312K, paused 2ms+3ms, total 48ms 

Der Haufen wächst und wächst, und ich habe keine Ahnung, was ich kann dagegen tun. Ich suchte im Internet und durch stackoverflow, aber es gab keine hilfreiche Antwort für mich. Ich hoffe, dass jemand von Ihnen den Fehler finden kann. Ich bin sehr neu in Android, also bitte schätzen.

EDIT1: Heapdump:

Here you can see what causes the heap allocation.

EDIT2: MAT Analyse

Verdächtiger 1:

One instance of "maps.by.a" loaded by "dalvik.system.PathClassLoader @ 0x4480cfa8" occupies 1.002.352 (22,33%) bytes. The memory is accumulated in one instance of "maps.by.d" loaded by "dalvik.system.PathClassLoader @ 0x4480cfa8". 

Keywords 
maps.by.a 
dalvik.system.PathClassLoader @ 0x4480cfa8 
maps.by.d 

Verdächtiger 2:

3.507 instances of "java.lang.Class", loaded by "<system class loader>" occupy 795.104 (17,72%) bytes. 

Biggest instances: 
•class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ 0x401fccc8 - 151.744 (3,38%) bytes. 
•class android.text.Html$HtmlParser @ 0x4016d288 - 126.592 (2,82%) bytes. 
•class org.apache.harmony.security.fortress.Services @ 0x40091188 - 51.456 (1,15%) bytes. 


Keywords 
java.lang.Class 

Verdächtiger 3:

8.168 instances of "java.lang.String", loaded by "<system class loader>" occupy 529.048 (11,79%) bytes. 

Keywords 
java.lang.String 
+0

Wenn Sie einen DDMS-Heap-Dump in MAT untersucht haben, was haben Sie herausgefunden, dass der Speicher belegt wurde? – CommonsWare

+0

meine Frage bearbeitet. –

+0

Ähm, während das eine interessante Tabelle ist, ist das für dich nur marginal nützlich. Vielleicht möchten Sie lesen [diese Android-Entwickler-Blog-Post über die Verwendung von MAT] (http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html), oder sehen [diese Google I | O 2011 Präsentation über die Verwendung von MAT und verwandten Tools] (http://www.youtube.com/watch?v=_CruQY55HOk), um mehr darüber zu erfahren, wie man Speicherlecks mit MAT findet. – CommonsWare

Antwort

3

Erstens, Ihr Haufen "wächst nicht weiter". Es schwebt zwischen 12893K und 13054K, steigt und fällt mit einem Ausreißer-Peak bei 13925K. Persönlich sehe ich nichts in diesem Protokoll, das mich beunruhigen würde.

In Bezug auf Ihre MAT-Ausgabe, wenn diese drei Top-Täter sind, sind keine überraschend. Die beiden letzteren sagen "Ich schreibe eine App für Android", da diese immer auf jeder Android-App verfügbar sind. Der erste gibt an, dass Maps V2 ein ziemlich dickliches Objekt hat. Auch hier sehe ich nichts, was auf ein Problem hindeutet.

+0

Nichts, worüber man sich Sorgen machen muss? Sollte ich diese Haufenwucherungen ignorieren? –

+0

@MichaelEder: Ihr Heap wird natürlich wachsen, wenn Ihre App verwendet wird, bis zum pro-process Heap-Limit des Geräts. Wenn Sie keinen Heap mehr haben, * dann * haben Sie ein Problem. Sie sind willkommen, sich jetzt Sorgen zu machen, wenn Sie wollen, aber da Sie "neu für Android" sind, haben Sie wahrscheinlich viel größere Fische zum Frittieren und viel mehr Erfahrung zu gewinnen, bevor Sie verstehen, was ein Speicherleck ist und was nicht. Das Aufspüren von Speicherlecks ist knifflige Angelegenheit (ich habe ein ganzes Kapitel über MAT in meinem Buch) und nichts, worüber sich die Leute im Allgemeinen Sorgen machen, bis sie sich den Heap-Grenzen viel näher kommen. – CommonsWare

+0

Ok danke! Ich werde das "Leck" ignorieren, bis ich mehr Erfahrung mit Android habe. –

Verwandte Themen