Qual è il ciclo di vita per Android StrictMode?

Question

Sto cercando di ridurre al minimo il numero di posti in mio codice in cui ho bisogno di impostare StrictMode. Ma io non sono sicuro se ho ragione o no su quanto segue.

La documentazione per StrictMode di Android dice che si può utilizzare per le applicazioni, attività e altri componenti. Ho letto che non è auspicabile estendere la classe di applicazione, e io preferisco non estendere l'applicazione solo per consentire StrictMode. Ma io non credo di avere a.

Ci sono due criteri che è possibile utilizzare: ThreadPolicy (per un thread) e VmPolicy (per tutte le discussioni). Quindi sembrerebbe che se ho configurato StrictMode su un thread una volta, non importa da dove lo faccio, e le violazioni saranno riportati in seguito, su quel filo indipendentemente da altre chiamate o meno su StrictMode. Ho solo bisogno di chiamare da qualche parte prima violazioni possono verificarsi che voglio rilevare. E deve essere configurato per eventuali nuove discussioni che vengono creati nella mia richiesta che anche io voglio controllare.

Quello che penso che voglio evitare è chiamata la build () i metodi più che ho bisogno di. Mettere StrictMode all'inizio del onCreate() in tutte le mie attività significa che build () sta per arrivare chiamato più di una volta su quel thread. Se ho un'attività Launcher nella mia richiesta, la creazione di StrictMode in onCreate() che di attività dovrebbe essere sufficiente per il resto dell'applicazione. È vero?

In secondo luogo, se la mia attività principale viene riavviato anche se l'applicazione non è morto, è tecnicamente necessario chiamare di nuovo StrictMode? O è il mio thread ancora messa a punto per le violazioni dei rapporti? Stavo pensando che ci potrebbe essere qualche valore nel fare un involucro di tipo di classe intorno StrictMode in questo modo:

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...");
        }
    }
}

In questo modo, in onCreate della mia attività principale (), posso semplicemente chiamare MyStrictModeSettings.init () e da fare con esso. E dovrebbe funzionare su versioni di Android 2.3 prima di troppo. Ma non può essere valsa la pena. Brad, ci sei? Grazie.

Modifica Dal VmPolicy è per tutte le discussioni, tecnicamente ho solo bisogno di configurare il monitoraggio una volta per ogni applicazione, giusto? Così enableDefaults () sta sprecando tentativo di rifare il VmPolicy quando viene chiamato una seconda, terza, ecc volta? Anche in questo caso, forse è più problemi che vale la pena di cercare di evitare le chiamate in più.

Answer 1

Sì, VmPolicy è per l'intero processo in modo farlo una volta va bene. Più volte è a buon mercato, anche se, in modo da non wory su di esso.

E sì, avete solo bisogno di farlo in onCreate del principale attività / lanciatore () --- che è lo stesso thread "principale" come tutti gli altri componenti.

Answer 2

Guardando il codice sorgente, si può vedere che esso viene chiamato in modo statico:

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;
            }
        }
    }
}

E la politica stessa viene memorizzato anche staticamente -. Non ci sono variabili membro non statici della classe

    private static volatile VmPolicy sVmPolicy = VmPolicy.LAX;

Questo significa che solo bisogno di farlo una volta per applicazione come ad esempio nel / attività di immissione di lancio per la propria applicazione.