¿El servicio Android se ejecuta desde un hilo separado en lugar de la interfaz de usuario?

Actualmente estoy usando alarmmanager para comenzar un servicio para publicar mi ubicación en http. El problema es cuando el administrador inicia y ejecuta los servicios, la interfaz de usuario parece detenerse por un tiempo. Me gustaría preguntar si el hilo de servicio está separado del hilo de la interfaz de usuario.

Copiado de los documentos de Android:

Precaución: un servicio se ejecuta en el hilo principal de su proceso de alojamiento: el servicio no crea su propio hilo y no se ejecuta en un proceso separado (a menos que especifique lo contrario). Esto significa que, si su servicio va a hacer un trabajo intensivo de CPU u operaciones de locking (como reproducción de MP3 o redes), debe crear un nuevo hilo dentro del servicio para hacer ese trabajo. Al usar un hilo separado, reducirá el riesgo de errores de la aplicación que no responde (ANR) y el hilo principal de la aplicación puede permanecer dedicado a la interacción del usuario con sus actividades.

http://developer.android.com/guide/topics/fundamentals/services.html

Use IntentService si no quiere manipular los hilos por su cuenta. O use AsyncTasks.

Para aclarar: el hilo principal de la aplicación no siempre es el hilo de la interfaz de usuario. Por ejemplo: si se detiene una actividad, se invoca onStop (), por lo tanto, el hilo de la IU se elimina de esa actividad y se mueve a otra actividad dentro de la misma aplicación o una diferente.

Sin embargo , esto no significa que esta aplicación ya no esté activa. Además, si hay un servicio (iniciado) ejecutándose en segundo plano, puede continuar por un tiempo, hasta que finalice o el sistema operativo Android lo finalice debido a la falta de recursos.

¿Quién dirige este servicio durante ese tiempo? ¿Quién desencadena el onStop () o el onDestroy ()? Es el hilo principal de la aplicación que hace eso.

El hilo de UI es una especie de Singleton. Puede ser utilizado solo por una actividad visible a la vez. O el hilo principal de la aplicación se une / se adjunta al hilo de UI u otro lo consigue. Sin embargo, esto no significa que la aplicación no tenga un hilo principal propio.

Este comportamiento proviene de la base Linux \ Unix del sistema Android. Lo que la mayoría de los desarrolladores desconocen: la aplicación es un “usuario” dentro del sistema operativo Linux \ Unix.

Cada vez que se invoca una aplicación, es similar a un usuario que inicia sesión en el sistema. En el caso de la aplicación, la identificación del usuario es la única identificación de la aplicación, mientras que no se requiere contraseña. El nuevo “usuario” conectado (es decir, la aplicación Android) obtiene un proceso y recursos tales como una instancia de la Máquina Virtual Java. El proceso está dedicado a este usuario y los recursos, incluida la cuota del sistema de archivos, los descriptores de archivos y los manejadores, le permiten comunicarse con el sistema operativo.

El hilo principal de la aplicación Android es el hilo raíz que se crea a partir del proceso que el sistema operativo Android entrega a esa aplicación. Todos los hilos nuevos creados en esta aplicación siempre volverán al hilo principal.

Uno de los recursos del sistema al que puede acceder el hilo principal de la aplicación es el hilo de la interfaz de usuario. Por lo tanto, la aplicación puede solicitar el hilo principal, sin embargo, la solicitud puede ser rechazada (o concedida). Un ejemplo: en caso de que el proceso de la aplicación supere el tamaño de asignación de memoria permitido, el sistema operativo Android puede decidir denegar el acceso al subproceso de interfaz de usuario e incluso destruir la aplicación y finalizar el proceso.

Es posible definir más que en proceso para una aplicación (bifurcación de proceso de Unix) a través de la definición en AndroidManifest.xml. Sin embargo, tenga en cuenta que los recursos asignados a cada proceso serán diferentes, es decir, cada proceso tendrá su propia máquina virtual, por lo tanto, los objetos mantenidos en los diferentes procesos no podrán compartir información a través del mismo montón de JVM.

Del desarrollador de Android:

¿Qué es un servicio?

La mayoría de la confusión sobre la clase de servicio en realidad gira en torno a lo que no es:

Un servicio no es un proceso separado. El objeto de servicio en sí no implica que se esté ejecutando en su propio proceso; a menos que se especifique lo contrario, se ejecuta en el mismo proceso que la aplicación de la que forma parte. Un servicio no es un hilo. No es un medio para hacer el trabajo fuera del hilo principal (para evitar errores de la aplicación no responde). Por lo tanto, un servicio en sí mismo es realmente muy simple, brindando dos características principales:

Un recurso para que la aplicación le informe al sistema sobre algo que quiere hacer en segundo plano (incluso cuando el usuario no está interactuando directamente con la aplicación). Esto corresponde a las llamadas a Context.startService (), que le pide al sistema que programe el trabajo para el servicio, para que se ejecute hasta que el servicio u otra persona lo detenga explícitamente. Una instalación para que una aplicación exponga parte de su funcionalidad a otras aplicaciones. Esto corresponde a las llamadas a Context.bindService (), que permite establecer una conexión de larga duración con el servicio para interactuar con él. Cuando se crea realmente un componente de servicio, por cualquiera de estos motivos, todo lo que el sistema realmente hace es instanciar el componente y llamar a onCreate () y cualquier otra callback apropiada en el hilo principal. Depende del Servicio implementarlos con el comportamiento apropiado, como crear un hilo secundario en el que haga su trabajo.

Tenga en cuenta que dado que el Servicio en sí es tan simple, puede hacer que su interacción con él sea tan simple o complicada como lo desee: tratarlo como un objeto Java local que haga llamadas directas al método (como se ilustra en el Ejemplo de servicio local), para proporcionar una interfaz remota completa que usa AIDL.