Quel est le cycle de vie pour Android StrictMode?

Question

Je suis en train de réduire le nombre de places dans mon code où je dois StrictMode de configuration. Mais je ne suis pas sûr si je suis bien ou pas sur les points suivants.

La documentation pour la StrictMode Android dit que vous pouvez l'utiliser pour les applications, activités et autres composants. J'ai lu qu'il n'est pas souhaitable d'étendre la classe d'application, et je préfère ne pas étendre une application juste pour permettre StrictMode. Mais je ne pense pas que je dois.

Il y a deux politiques que vous pouvez utiliser: ThreadPolicy (pour un fil) et VmPolicy (pour tous les threads). Donc, il semblerait que si je StrictMode d'installation sur un fil une fois, il n'a pas d'importance où je le fais, et les violations seront présentés par la suite sur ce fil indépendamment des autres appels ou non sur StrictMode. Je dois juste l'appeler de quelque part avant de violations pourraient se produire que je veux détecter. Et il doit être mis en place pour tous les nouveaux threads qui sont créées dans ma demande que je veux également vérifier.

Ce que je pense que je veux éviter appelle les méthodes plus build () je dois. Mettre StrictMode au début de onCreate() dans toutes mes activités signifie que la construction () va obtenir appelé plus d'une fois sur ce fil. Si j'ai une activité de lancement dans mon application, la mise en place StrictMode dans le onCreate() de cette activité devrait être suffisante pour le reste de l'application. Est-ce vrai?

En second lieu, si mon activité principale se redémarre, même si l'application ne meurt pas, il est techniquement nécessaire d'appeler à nouveau StrictMode? Ou est mon fil configuration encore à des violations du rapport? Je pensais qu'il pourrait y avoir une certaine valeur en faisant un emballage de type de classe autour StrictMode comme ceci:

public class MyStrictModeSettings {
    static private List<Long> setThreads = new ArrayList<Long>();

    // Prevent instantiation of this class
    private MyStrictModeSettings() {}

    static public synchronized void init() {
        try {
            Long tid = Thread.currentThread().getId();
            if(!setThreads.contains(tid)) {
                setThreads.add(tid);
                Class sMode = Class.forName("android.os.StrictMode");
                Method enableDefaults = sMode.getMethod("enableDefaults");
                enableDefaults.invoke(null);
            }
        }
        catch(Exception e) {
            // StrictMode not supported on this device, punt
            Log.v("StrictMode", "... not supported. Skipping...");
        }
    }
}

De cette façon, dans mon onCreate de l'activité principale (), je peux simplement appeler MyStrictModeSettings.init () et être fait avec elle. Et il devrait fonctionner sur les versions Android 2.3 avant aussi. Mais il ne peut pas valoir la peine. Brad, êtes-vous là? Merci.

Modifier Depuis VmPolicy est pour tous les threads, techniquement je ne doivent mettre en place que par application une fois, non? Alors enableDefaults () gaspille effort pour refaire le VmPolicy quand il est appelé un deuxième, troisième, etc temps? Encore une fois, peut-être il est plus d'ennuis que cela vaut la peine d'essayer d'éviter les appels supplémentaires.

Answer 1

Oui, VmPolicy est pour tout le processus, ce faisant, il est une fois bien. Plus de temps est pas cher, cependant, il ne faut pas Wory à ce sujet.

Et oui, il vous suffit de le faire dans onCreate () de votre activité principale / lanceur --- qui est le même fil « principal » que tous les autres composants.

Answer 2

En regardant le code source, vous pouvez voir qu'il est appelé statiquement:

public static void setVmPolicy(final VmPolicy policy) {
    synchronized (StrictMode.class) {
        sVmPolicy = policy;
        sVmPolicyMask = policy.mask;
        setCloseGuardEnabled(vmClosableObjectLeaksEnabled());

        Looper looper = Looper.getMainLooper();
        if (looper != null) {
            MessageQueue mq = looper.mQueue;
            if (policy.classInstanceLimit.size() == 0 ||
                (sVmPolicyMask & VM_PENALTY_MASK) == 0) {
                mq.removeIdleHandler(sProcessIdleHandler);
                sIsIdlerRegistered = false;
            } else if (!sIsIdlerRegistered) {
                mq.addIdleHandler(sProcessIdleHandler);
                sIsIdlerRegistered = true;
            }
        }
    }
}

Et la politique elle-même est également stockée statiquement -. Il n'y a pas de variables membres non statiques dans la classe

    private static volatile VmPolicy sVmPolicy = VmPolicy.LAX;

Cela signifie que vous suffit de le faire une fois par application telle que l'activité de lancement / entrée pour votre application.