Comment puis-je éviter les retards de collecte des ordures dans les jeux Java? (Meilleures Pratiques) [fermé]

Bien que ce soit une question de 2 ans...

La seule et la meilleure approche pour éviter le décalage GC est d'éviter GC lui-même en allouant tous les objets requis quelque peu statiquement (y compris au démarrage). Pré-créez tous les objets requis et ne les supprimez jamais. Utilisez le regroupement d'objets pour réutiliser un objet existant.

De toute façon, vous pouvez avoir une pause éventuelle même après avoir fait toutes les optimisations possibles sur votre code. Parce que autre chose que le code de votre application est toujours en train de créer Objets GC en interne qui deviendront éventuellement des ordures. Par exemple, Bibliothèque de base Java. Même l'utilisation de la simple List classpeut créer des vêtements. (il faut donc éviter) Appeler l'une des API Java peut créer des garbages. Et ces allocations ne sont pas évitables lorsque vous utilisez Java.

Aussi, parce que Java est conçu pour utiliser GC, vous aurez des problèmes par manque de fonctionnalités si vous essayez vraiment d'éviter GC. (même la classe List doit être évitée) Car elle permet de la GC, toutes les bibliothèques peut utiliser GC, de sorte que vous pratiquement/presque pas de bibliothèque. Je considère qu'éviter GC sur le langage basé sur GC est une sorte d'essai fou.

En fin de compte, le seul moyen pratique est de descendre au niveau inférieur où vous pouvez contrôler complètement la mémoire vous-même. Tels que les langages de la famille C (C, C++, etc.). Alors allez à NDK.

Note

Maintenant, Google expédie incrémental (concurrent?) GC qui peut diminuer pause beaucoup. Quoi qu'il en soit, le GC incrémental signifie simplement distribuer la charge du GC au fil du temps, de sorte que vous voyez toujours une pause éventuelle si la distribution n'est pas idéale. En outre, les performances du GC elles-mêmes seront diminuées en raison de l'effet secondaire d'une réduction des frais généraux d'opération de traitement par lots et de distribution.

J'ai construit ma propre version sans déchets de String.format, du moins en quelque sorte. Vous le trouvez ici: http://pastebin.com/s6ZKa3mJ (veuillez excuser les commentaires allemands).

Utilisez-le comme ceci:

GFStringBuilder.format("Your score is: % and your name is %").eat(score).eat(name).result

Tout est écrit dans un tableau char[]. J'ai dû implémenter la conversion de l'entier en chaîne manuellement (chiffre par chiffre) pour me débarrasser de toutes les ordures.

En dehors de cela, j'utilise SparseArray si possible, car toutes les structures de données Java telles que HashMap, ArrayList etc. utiliser boxe afin de faire face aux types primitifs. Chaque fois que vous boxez un int à Integer, cet objet Integer doit être nettoyé par le GC.

Si vous ne voulez pas pré-rendre le texte comme cela a été proposé, drawText accepte tout CharSequence ce qui signifie que nous pouvons en faire notre propre implémentation intelligente:

final class PrefixedInt implements CharSequence {

    private final int prefixLen;
    private final StringBuilder buf;
    private int value; 

    public PrefixedInt(String prefix) {
        this.prefixLen = prefix.length();
        this.buf = new StringBuilder(prefix);
    }

    private boolean hasValue(){
        return buf.length() > prefixLen;
    }

    public void setValue(int value){
        if (hasValue() && this.value == value) 
            return; // no change
        this.value = value;
        buf.setLength(prefixLen);
        buf.append(value);
    }


    // TODO: Implement all CharSequence methods (including 
    // toString() for prudence) by delegating to buf 

}

// Usage:
private final PrefixedInt scoreText = new PrefixedInt("Your score is: ");
...
scoreText.setValue(Score.points);
canvas.drawText(scoreText, 0, scoreText.length(), x, y, paint);

Maintenant, dessiner le score ne provoque aucune allocation (sauf peut-être une ou deux fois au début lorsque le tableau interne de bufpeut devoir être développé, et tout ce que drawText fait).

Dans une situation où il est essentiel d'éviter les pauses GC, une astuce que vous pouvez utiliser est de déclencher délibérément GC à un point où vous savez que la pause n'a pas d'importance. Par exemple, si la fonction garbage intensive "showScores" est utilisée à la fin d'une partie, l'utilisateur ne sera pas trop distrait par un délai supplémentaire de 200 ms entre l'affichage de l'écran de score et le démarrage de la partie suivante ... vous pouvez donc appeler System.gc() une fois que l'écran scores a été peint.

Mais si vous avez recours à ceci astuce, vous devez faire attention à ne le faire qu'aux points où la pause du GC ne sera pas ennuyeuse. Et ne le faites pas si vous craignez de vider la batterie du combiné.

Et ne le faites pas dans des applications multi-utilisateurs ou non interactives, car vous rendrez probablement l'application plus lente en faisant cela.

En ce qui concerne l'allocation d'itérateurs, éviter les itérateurs sur ArrayList est facile. Au lieu de

for(GameObject gob : interactiveObjects)
    gob.onDraw(canvas);

Vous pouvez juste faire

for (int i = 0; i < interactiveObjects.size(); i++) {
    interactiveObjects.get(i).onDraw();
}