Comment gérer :java.util.de façon concomitante.TimeoutException: android.os.BinderProxy.finalize() a expiré au bout de 10 secondes d'erreurs?

Divulgation complète - je suis l'auteur de parler dans TLV DroidCon.

J'ai eu la chance d'examiner cette question dans de nombreuses applications Android, et d'en discuter avec d'autres développeurs qui ont rencontré - et nous nous sommes tous au même point: ce problème ne peut pas être évitée, seulement réduit.

J'ai pris un peu plus près l'implémentation par défaut de l'Android Garbage collector code, pour mieux comprendre pourquoi cette exception est Levée et sur ce que pourrait être les causes possibles. J'ai même trouvé une cause possible pendant l'expérimentation.

La racine du problème est au point un dispositif de "Veille" pendant un certain temps, ce qui signifie que l'OS a décidé d'abaisser la consommation de la batterie par l'arrêt de la plupart des Utilisateurs des Terres des processus pendant un certain temps, et en tournant l'Écran éteint, la réduction des cycles de CPU, etc. La manière dont c'est fait - est sur un système Linux niveau où les processus sont en Pause en milieu de course. Cela peut se produire à tout moment pendant le fonctionnement normal de l'exécution de l'Application, mais il s'arrête à un Natif du système d'appel, comme le changement de contexte est réalisé au niveau du noyau. - C'est où le Dalvik GC rejoint l'histoire.
Le Dalvik code GC (tel que mis en œuvre dans le Dalvik projet dans le PSBA site) n'est pas compliquée morceau de code. Le fonctionnement de base de ce travail est couvert dans mes DroidCon diapositives. ce que je n'ai pas de couverture est la base GC boucle - au moment où le collecteur a une liste d'Objets à finaliser (et détruire). la boucle de la logique à la base peut être simplifiée comme ceci:

1. prendre starting_timestamp,
2. de supprimer l'objet de la liste des objets à la libération,
3. la libération de l'objet finalize() et appel natif destroy() si nécessaire,
4. prendre end_timestamp,
5. calculer (end_timestamp - starting_timestamp) et comparez-les avec une codés en dur valeur de temporisation de 10 secondes,
6. si le délai est atteint - jeter le concurrent.TimeoutException et de tuer le processus.

Maintenant, considérons le scénario suivant:

Application longe faire sa chose. ce n'est pas un Utilisateur face à la demande, il s'exécute en arrière-plan. Au cours de cette opération en arrière-plan, les Objets sont créés, utilisés et doivent être recueillies afin de libérer de la mémoire. L'Application ne prend pas la peine avec un Wakelock, ce qui affecte la batterie de façon défavorable, et semble inutile. cela signifie que l'Application appelle le GC de temps à autre. Normalement, le GC fonctionne sans accroc. Parfois (très rarement) le Système va décider de Dormir dans le milieu de la GC exécuter. Cela se produit si vous exécutez votre application assez longtemps, et de surveiller le Dalvik mémoire journaux de près. Maintenant considérer le timestamp de la logique de base GC en boucle, il est possible de l'appareil pour commencer la course, prendre un start_stamp, et aller dormir à l' destroy() appel des indigènes sur un objet système. quand il se réveille et reprend la course, le destroy() va se terminer, et la prochaine end_stamp sera le temps qu'il a fallu le destroy() appel+le temps de dormir. Si le temps de sommeil a été long plus de 10 secondes, le simultanées.délai d'attente exception sera levée.

J'ai vu cela dans les graphiques générés à partir de l'analyse de script python pour Android les Applications du Système, non seulement ma propre surveillé apps. recueillir suffisamment de journaux, vous le verrez par la suite.

Ligne du bas:

Le problème ne peut pas être évitée - vous le rencontrerez si votre application s'exécute en arrière-plan. Vous pouvez atténuer en prenant un wakelock, et empêcher l'appareil de dormir, mais c'est une autre histoire, et un nouveau mal de tête, et peut-être un autre discours dans un autre con.

Vous pouvez minimiser le problème en réduisant GC appels de décisions que le scénario le moins probable. des conseils sont dans les diapositives.

Je n'ai pas encore eu la chance d'aller sur le Dalvik 2 (un.k.un ART) code GC - qui dispose d'une nouvelle Générations de Compactage fonctionnalité, ou effectué des expériences sur Android Lollipop.

Ajouté 7/5/2015:

Après avoir examiné les rapports de Plantage de l'agrégation pour ce crash type, il semble que ces accidents à partir de la version 5.0+ de système d'exploitation Android (Lollipop avec l'ART) ne compte que pour 5% de ce crash type. Cela signifie que l'ART GC changements a réduit la fréquence de ces accidents.

Ajouté 6/1/2016:

Ressemble le projet Android a ajouté beaucoup d'informations sur la façon dont le GC fonctionne en Dalvik 2.0 (un.k.un ART). Vous pouvez lire à ce sujet ici - Débogage de l'ART de la Collecte des Ordures
. Il traite également des outils pour obtenir des informations sur le comportement du GC pour votre application. L'envoi d'un SIGQUIT à votre app processus consistera essentiellement à cause d'une ANR, et le vidage de l'état de l'application dans un fichier journal pour l'analyse.

OriginalL'auteur oba

J'ai trouvé quelques diapositives sur ce problème.

http://de.slideshare.net/DroidConTLV/android-crash-analysis-and-the-dalvik-garbage-collector-tools-and-tips

Dans ce diapositives de l'auteur raconte qu'il semble y avoir un problème avec le GC, si il y a beaucoup d'objets ou des objets dans le tas. La diapositive également inclure une référence à un exemple d'application et un script python pour analyser cette question.

https://github.com/oba2cat3/GCTest

https://github.com/oba2cat3/logcat2memorygraph

En outre, j'ai trouvé une astuce en commentaire #3 de ce côté: https://code.google.com/p/android/issues/detail?id=53418#c3

OriginalL'auteur Christopher

Nous avons résolu le problème en arrêtant le FinalizerWatchdogDaemon.

public static void fix() {
    try {
        Class clazz = Class.forName("java.lang.Daemons$FinalizerWatchdogDaemon");

        Method method = clazz.getSuperclass().getDeclaredMethod("stop");
        method.setAccessible(true);

        Field field = clazz.getDeclaredField("INSTANCE");
        field.setAccessible(true);

        method.invoke(field.get(null));

    }
    catch (Throwable e) {
        e.printStackTrace();
    }
}

Vous pouvez appeler la méthode dans l'Application du cycle de vie, comme attachBaseContext().
Pour la même raison, vous pouvez également spécifique du téléphone fabrication pour résoudre le problème, il est à vous.

OriginalL'auteur Enaoi

try {
    Class<?> c = Class.forName("java.lang.Daemons");
    Field maxField = c.getDeclaredField("MAX_FINALIZE_NANOS");
    maxField.setAccessible(true);
    maxField.set(null, Long.MAX_VALUE);
} catch (ClassNotFoundException e) {
    e.printStackTrace();
} catch (NoSuchFieldException e) {
    e.printStackTrace();
} catch (IllegalAccessException e) {
    e.printStackTrace();
}

OriginalL'auteur kot32

Pour les classes que vous créez (ie. ne font pas partie de l'Android) son possible pour éviter le crash complètement.

Toute classe qui implémente finalize() a quelques inévitables probabilité de s'écraser comme expliqué par @oba. Donc, au lieu d'utiliser les finaliseurs pour effectuer le nettoyage, utilisez un PhantomReferenceQueue.

Pour un exemple de vérifier la mise en œuvre de Réagir Natif: https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/jni/DestructorThread.java

OriginalL'auteur Ben