Android Broadcast Receiver vs Servicio

Estoy tratando de aclarar la diferencia entre un receptor de difusión y el servicio en android.

Entiendo que una actividad puede iniciar un servicio llamando a startService con una intención.

Un receptor de difusión puede ser registrado en el código o el manifiesto y puede ser llamado con sendBroadcast .

¿Cuándo usarías uno contra el otro?

Entiendo que el receptor múltiple de la difusión puede estar escuchando para la misma intención y éste NO es el caso con un servicio.

3 Solutions collect form web for “Android Broadcast Receiver vs Servicio”

Los servicios están destinados a realizar una acción en segundo plano durante algún período de tiempo, independientemente de lo que el usuario esté haciendo en primer plano (el usuario podría cambiar de actividad). Un buen ejemplo sería un servicio de reproductor de música – el usuario comienza a reproducir música a través de una aplicación de reproductor de música, pero cuando salen de la aplicación de la música sigue jugando.

Los servicios también son útiles para proporcionar / administrar acceso común a un recurso a través de múltiples aplicaciones. Esto se utiliza a menudo para los recursos del sistema, como los sensores.

Los receptores de difusión tienen la intención de responder a una intención (normalmente enviada por un servicio o un evento del sistema), hacer algo y hacerse. Un ejemplo aquí puede ser que el usuario toque un teléfono habilitado para NFC a una etiqueta, el sistema crea una intención para ello, y un receptor registrado lo maneja para cambiar algunos ajustes (cambiar volumen, encender bluetooth, etc.).

Cuando se transmite una intención a través de sendBroadcast, ésta se enviará a todos los receptores que tengan filtros de intenciones coincidentes. Sin embargo, es importante tener en cuenta que en API26 + la mayoría de los receptores registrados en el manifiesto ya no se invocan en tales situaciones, consulte la documentación de Google para obtener más información .


Ejemplo 1: Supongamos que desea exponer una función (que estará disponible en cualquier aplicación que quiera usarla) que pida a un sitio web que calcule los grados de separación de Kevin Bacon.

Tenga en cuenta que este ejemplo es "hacer algo y devolver", en lugar de realizar una operación de fondo de larga ejecución.

Puede implementar esto de varias maneras:

Cree un proyecto de biblioteca que todos los usuarios compilen en su aplicación.

  • Ahora hay varias copias de su código y todas podrían ser versiones diferentes.
  • No se pueden realizar batch o caché de solicitudes ya que cada solicitud se gestiona de forma independiente.

Cree un receptor de difusión para manejar cada solicitud.

  • Su aplicación registra un receptor de difusión para aceptar un intento de hacer la pregunta Bacon
  • Cada aplicación envía una intención de hacer la pregunta.
  • El receptor de la emisión acepta el Inten-
    • Pasa la solicitud a un servicio para realizar el procesamiento, lo que envía una Intención al solicitante con el resultado
    • Envía una solicitud al servidor que responderá con Google Cloud Messaging cuando se haya completado
  • Debido a que todas las solicitudes pasan por una aplicación, puede realizar batch / cache de resultados
  • Esto siempre es asincrónico
  • API es "Intenciones" – no es la forma más amigable de exponer su funcionalidad

Crear un servicio para manejar cada solicitud

  • Su aplicación crea un servicio para manejar las solicitudes y expone una API a través de un Binder o utilizando AIDL
  • La API puede ser síncrona (llamada directa y devolución) o asíncrona (permite el registro del oyente y llama al oyente cuando el resultado está listo). Usted debe elegir solamente síncrono si se espera que el proceso sea muy rápido; Las llamadas a servidores deben ser manejadas asincrónicamente
  • API es "método de llamadas" – una forma mucho más amigable para exponer la funcionalidad

Ejemplo 2: Desea realizar algunos análisis de datos para encontrar algunos patrones en sus datos

Hilo de fondo Si todo el procesamiento debe ocurrir mientras el usuario está en la misma aplicación y en la misma Actividad, un hilo de fondo (o un AsyncTask que gestiona un hilo de fondo) sería un buen enfoque

Servicio Si desea permitir al usuario salir de la aplicación mientras se está realizando el procesamiento (y notificarlos de los resultados más adelante) o permitirles progresar a través de múltiples actividades en la misma aplicación mientras se realiza el procesamiento, Ser un mejor enfoque

Receptor de radiodifusión

Al manejar una emisión, la aplicación recibe un conjunto fijo de tiempo (actualmente 10 segundos) en el que realizar su trabajo. Si no se completa en ese momento, se considera que la aplicación se está portando mal, y su proceso es lanzado de inmediato al estado de fondo para que sea destruido por la memoria si es necesario.

Los receptores de difusión están limitados por la cantidad máxima de tiempo (10 segundos en general), tienen que terminar.

Servicio

Si su acción toma un tiempo más largo (la conexión a Internet puede tomar algunos). Más preferiblemente como la ejecución en el fondo. Usted definitivamente debe llamar a un servicio del receptor o actividad para este propósito. Son últimos para ser matados por el sistema operativo androide.

Conclusión:

  1. En general, todo el trabajo (búsqueda, análisis, almacenamiento en caché, actualización de la base de datos) que es importante para su aplicación debe moverse a Service ya que son de larga vida en Android. Como usted casi ha considerado que todos los sitios de redes sociales tienen STICKY_SERVICES que hace todo el trabajo problemático.

  2. BroadcastReceiver se utilizan principalmente para iniciar el servicio. Generalmente depende de la aplicación. La mayor parte de la aplicación utiliza ConnectivityManager para transmitir siempre que la red esté ENCIMA O ABAJO. Con la ayuda de estos Service son iniciados por BroadcastReceiver .

En primer lugar, lea la documentación tanto para Broadcast Receiver como para Servicios .

Puede encontrar tutoriales útiles aquí y aquí .

Por fin, para hacer la larga historia:

El servicio comienza con su solicitud (startService (intención)). Se puede pensar en el receptor Broadcast como un oyente intencionado.

  • Android: startActivityForResult no llamando aActivityResult
  • Descargar varios archivos con una barra de progreso en ListView Android
  • Lanzar el servicio desde el inicio de la aplicación, sin actividad
  • Android: ¿Cómo forzar onStartCommand () que se llama antes de onBind ()?
  • Servicio de Android Creación de una nueva instancia de clase Singleton
  • START_STICKY y START_NOT_STICKY
  • ¿Es mejor usar AsyncTask o Service para cargar un archivo en segundo plano?
  • Llamar setVolumeControlStream desde un servicio
  • El servicio no se detiene incluso después de que el método onDestroy se llama en Android
  • Android verificar el estado WIFI (desconectado o el usuario ha cambiado WIFI) ¿Cómo FLAG?
  • El proceso del servicio se cancela después de que la aplicación se elimina de la bandeja de aplicaciones
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.