¿Cuál es el ciclo de vida para Android StrictMode?

Question

Estoy tratando de minimizar el número de lugares en mi código en las que necesito StrictMode configuración. Pero no estoy seguro de si estoy bien o no se trata de lo siguiente.

La documentación para StrictMode de Android dice que se puede utilizar para aplicaciones, actividades y otros componentes. He leído que no es deseable extender la clase de aplicaciones, y yo preferiría no extender la aplicación simplemente para permitir StrictMode. Pero no creo que tengo que hacerlo.

Hay dos políticas que puede utilizar: ThreadPolicy (por un hilo) y VmPolicy (para todos los hilos). Por lo que parece que si StrictMode configuración de un hilo una vez, no importa desde donde lo hago, y violaciónes se informará a partir de entonces en ese hilo independientemente de otras llamadas o no en StrictMode. Sólo tengo que llamarlo de alguna parte antes de violaciónes podría ocurrir que quiero detectar. Y tiene que ser configurado para cualquier nuevos temas que se crean en mi solicitud que también desee comprobar.

Lo que creo que quiero evitar la acumulación está llamando () métodos más de lo que necesito. Poner StrictMode al comienzo de onCreate() en todas mis actividades medios que build () va a ser llamado más de una vez en ese hilo. Si tengo una actividad Launcher en mi solicitud, la creación de StrictMode en onCreate() de que la actividad debe ser suficiente para el resto de la aplicación. ¿Es eso cierto?

En segundo lugar, si mi actividad se reinicia aunque la aplicación no murió, es técnicamente necesario llamar StrictMode de nuevo? O es mi hilo sigue la configuración de violaciónes informe? Estaba pensando que podría haber algún valor en hacer un envoltorio de tipo de clase en torno StrictMode este 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...");
        }
    }
}

De este modo, en onCreate de mi actividad principal (), puedo simplemente llamar MyStrictModeSettings.init () y hacerse con él. Y que debería funcionar en las versiones de Android 2.3 antes también. Pero puede no valer la pena. Brad, ¿estás ahí? Gracias.

Editar Desde VmPolicy es para todos los hilos, técnicamente, sólo tiene que poner esto en marcha una vez por aplicación, ¿verdad? Así enableDefaults () es perder el esfuerzo para hacer de nuevo el VmPolicy cuando se llama a una segunda, tercera, etc tiempo? Una vez más, tal vez es más problemas de lo que vale para tratar de evitar las llamadas adicionales.

Answer 1

Sí, VmPolicy es para todo el proceso de hacerlo, una vez que está muy bien. Más veces es barato, sin embargo, así que no wory al respecto.

Y sí, sólo tiene que hacerlo en onCreate de su actividad / lanzador () --- que es el mismo hilo "principal", como todos sus otros componentes.

Answer 2

Mirando el código fuente, se puede ver que está siendo llamado estáticamente:

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

Y la propia política también se almacena de forma estática -. No hay variables de miembros no estáticos de la clase

    private static volatile VmPolicy sVmPolicy = VmPolicy.LAX;

Esto significa que sólo tiene que hacerlo una vez por cada aplicación, como en la actividad de lanzamiento / entrada para su aplicación.