Android: Update Thread verursacht GC eine Tonne laufen

Question

Ich schreibe eine etwas komplexe Spielengine in Android.

Derzeit habe ich einen Thread zum Aktualisieren von Subsystemen verwendet.

Innerhalb der Update-Methode befindet sich die Methode zum Aktualisieren der Spiellogik, die auf dem aktuellen Spielstatus basiert.

Der Spielstatus hat eine Szene, die aktualisiert wird. Szenen bestehen aus einem Wurzelknoten, der eine einfache Szenengraphstruktur erzeugt.

Wurzeln sind Knoten, die Kinder haben, die auch aktualisiert werden und so weiter und so weiter.

Wie auch immer, das ist alles nett und dandy und funktioniert gut, bis ich eine Million davon in meinem Logcat: 03-29 09: 23: 22.866: D/dalvikvm (18554): GC_CONCURRENT befreit 511K, 52% kostenlos 2773K/5767K, externe 77K/587K, pausiert 2ms + 3ms

Ich habe die Ursache des Lecks als die Update-Schleife isoliert, als wenn ich meine Methode auskommentieren Subsysteme zu aktualisieren, gibt es keine GC-Nachrichten. Außerdem habe ich mich tief in die Update-Schleife und bis zu dem Punkt geäußert, an dem das Child-Update des Root-Knotens der Punkt ist, an dem der GC rasend schnell laufen würde.

(GameLgoic) 
public void onUpdate(float deltaTime) 
    { 
     if (gameState != null) 
      gameState.onUpdate(deltaTime); 
    } 
(GameState) 
public void onUpdate(float deltaTime) 
    { 
     scene.onUpdate(deltaTime); 
    } 
(Scene) 
public void onUpdate(float deltaTime) 
    { 
     root.onUpdate(deltaTime); 
    } 
(SceneNode) 
public void onUpdate(float deltaTime) 
    { 
     for (int i = 0; i < children.size(); ++i) 
     { 
      children.get(i).onUpdate(deltaTime); // Memory leak runs crazily here 
     } 
    } 

Wenn ich children.get (i) auf Kommentar .onUpdate (DELTA) Es gibt keine Lecks! Mein Verstand ist so verblüfft. Danke Leute.

Answer 1

Ich stieß auf ähnliches Problem, wenn ich ein Spiel für Android machte. Der einzige Weg, um hier rauszukommen, ist Embedded-C-Style zu programmieren. Wenn Sie also eine Schleife möchten, Ihre Zählvariable wiederzuverwenden, sowie Ihre Begrenzungs Variable, wann immer möglich, etwa so:

int i; 
int max 
void loop(){ 
    max = bla.size(); 
    for(i=0; i<max; i++){ ... } 
} 

Das gleiche gilt für buchstäblich alles, was Sie berühren. Sie könnten also erwägen, Verweise auf Objekte, die Sie nicht mehr benötigen, zu behalten und sie später wiederzuverwenden.

Es ist verrückt, welchen Unterschied es zu meinem Spiel gemacht hat, diese Änderungen zu implementieren. Framerate verdoppelt, enorme Reduzierung von Verzögerungen und so weiter.

Sie sollten in das DDMS-Tool schauen, welches das Eclipse Android SDK liefert. Sie können damit Zuordnungen aufspüren, um diese Probleme zu vermeiden.

Zusätzlich sollten Sie alle Interaktoren entfernen, da sie jedes Mal zugewiesen werden, wenn Sie in eine Schleife springen und nicht wiederverwendet werden können. Daher ist es besser, manuell eine Schleife zu erstellen und mehrmals durch Ihre Listen zu gehen (get(x) in Schleife), als auf lange Sicht auf den Garbage Collector warten zu müssen.

Answer 2

Zuerst zur Klärung der Terminologie - Sie nicht haben a memory leak. Ein Speicherverlust tritt auf, wenn die Speichernutzung Ihrer App wächst und wächst, da sie nicht mehr den Speicher freigibt, den sie nicht mehr verwendet. Sie haben die gegenüber Problem - Sie veröffentlichen eine Menge ungenutzten Speicher, der garbage collected sein muss.

Freigeben von ungenutztem Speicher ist normalerweise eine gute Sache; Es wird nur ein Problem, wenn die Garbage Collection, die zum Bereinigen des freigegebenen Speichers erforderlich ist, Leistungsprobleme verursacht, die Sie hier sehen.

Es gibt nichts Schlimmeres mit dem Code, den Sie bisher gepostet haben.Das Problem scheint innerhalb der onUpdate() Methode zu liegen, so dass Sie den Code dafür schreiben könnten.

Im Allgemeinen können Sie Garbage Collections reduzieren, indem Sie Objekte wo möglich wiederverwenden, anstatt sie zu zerstören und zu erstellen.

Schließlich ist ein kleiner Punkt, können Sie ersetzen:

for (int i = 0; i < children.size(); ++i) 
{ 
    children.get(i).onUpdate(deltaTime); // Memory leak runs crazily here 
} 

mit a for loop:

for (SomeClass child : children) { 
    child.onUpdate(deltaTime); 
}