Wie viel ist zu viel Speicherzuweisung in NDK?

Question

Der NDK Download-Seite stellt fest, dass, „Typische gute Kandidaten für das NDK sind in sich geschlossene, CPU-intensive Operationen, die, wie Signalverarbeitung, Physik-Simulation, und so weiter nicht viel Speicher zuweisen.“

Ich kam von einem C-Hintergrund und war aufgeregt zu versuchen, die NDK zu verwenden, um die meisten meiner OpenGL ES-Funktionen und alle nativen Funktionen im Zusammenhang mit Physik, Animation von Vertices, etc ... Ich finde, dass ich Ich verlasse mich ein wenig auf nativen Code und frage mich, ob ich vielleicht Fehler mache. Ich hatte zu diesem Zeitpunkt keine Probleme mit Tests, aber ich bin gespannt, ob ich in Zukunft Probleme bekommen könnte.

Zum Beispiel habe ich Spielstruktur definiert (etwa wie im San-Angeles-Beispiel gesehen). Ich lade Vertexinformation für Objekte dynamisch (genau das, was für einen aktiven Spielbereich benötigt wird), so gibt es ziemlich viel Zuordnungsspeicher für Ecken geschieht, Normalen, Texturkoordinaten, Indizes und Textur Grafikdaten ... nur das Wesentliche zu nennen . Ich bin ziemlich vorsichtig damit, was zwischen Spielbereichen aufgeteilt wird.

Wäre ich sicherer, einige Caps auf Array-Größen zu setzen, oder sollte ich tapfer vorwärts gehen, wie ich jetzt gehe?

Answer 1

Da sich Anwendungen, die den NDK verwenden, ähnlich wie SDK entwickeln sollten, denke ich, dass die beste Anleitung für eine vernünftige Heap-Verwendung aus den Kommentaren von ActivityManager.java stammt.

/** 
* Return the approximate per-application memory class of the current 
* device. This gives you an idea of how hard a memory limit you should 
* impose on your application to let the overall system work best. The 
* returned value is in megabytes; the baseline Android memory class is 
* 16 (which happens to be the Java heap limit of those devices); some 
* device with more memory may return 24 or even higher numbers. 
*/ 
public int getMemoryClass() { 
    return staticGetMemoryClass(); 
} 

/** @hide */ 
static public int staticGetMemoryClass() { 
    // Really brain dead right now -- just take this from the configured 
    // vm heap size, and assume it is in megabytes and thus ends with "m". 
    String vmHeapSize = SystemProperties.get("dalvik.vm.heapsize", "16m"); 
    return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length()-1)); 
} 

Der Code, der die Speichergröße für die Dalvik VM unterscheidet, ist in AndroidRuntime.cpp und liefert ein Beispiel dafür, wie eine grobe Grenze für Heapzuweisungen in nativen Code unter Verwendung der property_get Funktion zu bestimmen.

strcpy(heapsizeOptsBuf, "-Xmx"); 
property_get("dalvik.vm.heapsize", heapsizeOptsBuf+4, "16m"); 
//LOGI("Heap size: %s", heapsizeOptsBuf); 
opt.optionString = heapsizeOptsBuf; 
mOptions.add(opt); 

Der Standardwert von 16m ist wahrscheinlich wichtig, da keiner der beiden Android-Handys ich die standardmäßig dalvik.vm.heapsize Eigenschaft besitzen müssen.