ContentObserver vs BroadCastReceiver: Uso de la batería, RAM, CPU?

Service ejecutando vs no Service running

Cada aplicación tiene al menos un Process que se inicia cuando se ejecuta la aplicación. Ese proceso utiliza al menos un poco de memoria y la gente le gusta usar asesinos de tareas para liberar que aunque Android hace que automáticamente una vez que la memoria es realmente necesario. Esta memoria es definitivamente una desventaja para el caso del Service .

El uso de la CPU / batería sólo se incrementa cuando algo está sucediendo y, por lo tanto, utiliza activamente la CPU o cuando la aplicación obliga al sistema a mantener los recursos habilitados, por ejemplo, cuando mantiene un WakeLock . Si no hace nada de esto, la aplicación utiliza aproximadamente 0 CPU / batería y actúa como una aplicación detenida que se mantiene en la memoria para acelerar la reinicialización. La probabilidad de que usted use algunos recursos de forma inadvertida es ciertamente más alta si su código se está ejecutando.

Si no se ejecuta ningún Service / Activity y solo registra un BroadcastReceiver en su manifiesto, básicamente le dice al sistema que incluya a su receptor en la lista de receptores que comprueba al enviar emisiones. Muy poco trabajo extra.

Los receptores manifiestos también tienen la ventaja de que el sistema no puede morir cuando la presión de la memoria es alta. Esos receptores apenas trabajan y usted no necesita importar en todos. Incluso puede habilitarlos o deshabilitarlos si así lo desea.

ContentObserver vs BroadcastReceiver

Ambos deben utilizar el mecanismo de ActivityThread / Looper / MessageQueue normalmente denominado "UI Thread", que entrega todos los eventos a su aplicación y llama a todos los onCreate , onTouch etc. Fácilmente visible cuando miras un stacktrace cuando algo se rompe en estos métodos:

 AndroidRuntime(521): FATAL EXCEPTION: main AndroidRuntime(521): java.lang.RuntimeException: MotionEvent{405215b0 action=0 x=66.0 y=78.0 pressure=1.0 size=0.0} recycled twice! AndroidRuntime(521): at android.view.MotionEvent.recycle(MotionEvent.java:659) AndroidRuntime(521): at android.view.ViewRoot.handleMessage(ViewRoot.java:1880) AndroidRuntime(521): at android.os.Handler.dispatchMessage(Handler.java:99) AndroidRuntime(521): at android.os.Looper.loop(Looper.java:123) AndroidRuntime(521): at android.app.ActivityThread.main(ActivityThread.java:3647) 

Si no se envía ninguna notificación de cambio de contenido o difusión, el hilo simplemente espera. La espera no utiliza la CPU (es decir, activa el ciclo en un bucle todo el tiempo), pero le dice al sistema que no necesita programar el tiempo de procesamiento para ese hilo. El uso de la CPU es efectivamente 0 en ese tiempo. Así que la OMI no hay ninguna diferencia en absoluto entre el registro de uno de los dos en tiempo de ejecución.

La única diferencia que podría dar ventajas a uno de los métodos sería si uno si los métodos desencadenar más a menudo.

1 vs 5 de ellos

No importa. Hay tantos receptores / observadores en el sistema que realmente no importa si agrega 1 o 5. Si agrega como 1000 probablemente notará

En un sidenote: No bloquear el hilo de interfaz de usuario de hacer su trabajo. Aunque los receptores y servicios no tienen UI sus métodos de devolución de llamada se ejecutan en el subproceso de interfaz de usuario. Así que si haces alguna operación de larga duración como descargar cosas en cualquiera de los onReceive / Service#onCreate etc., que conducirán a ANRs de la misma manera que lo hace por ejemplo en Activity#onCreate .