백그라운드에서 오래 실행되는 작업을 수행할 수 있는 어플리케이션 컴포넌트이다.
사용자에게 인터페이스(UI)를 제공하지 않는다
다른 어플리케이션 컴포넌트가 Service를 시작할 수 있고, 다른 어플로 전환하더라도 백그라운드에서 계속 실행된다
어플리케이션 컴포넌트와 Service를 바인딩하여 Service와 상호작용할 수 있고, 프로세스간 통신(IPC)도 실행이 가능하다.
Service는 별개의 프로세스가 아니며, 특별히 지정하지 않았을 경우 어플리케이션이 실행되고 있는 것과 동일한 스레드에서 실행된다
추가로 Service는 스레드가 아니다
Service는 앱에서 오직 1개의 인스턴스만을 생성할 수 있다.
네트워크 트랜잭션을 처리하거나, 음악을 재생하거나, 파일 입출력을 수행하는 등의 작업에 사용된다.
사용자에게 직접 보이는 작업을 수행한다
알림창을 통해서 Service가 실행중인 것을 나타낸다. 대신, 시스템에 의해서 강제로 종료되지 않는다
사용자가 앱과 상호작용 하지 않을 때에도 계속 실행된다.
예를 들면, 음악 앱일 경우 우리가 음악 트랙을 재생할 때 사용하는 것이 포그라운드 서비스이다.
사용자에게 보이지 않는 작업을 수행한다.
시스템에서 리소스가 부족할 경우에 강제 종료 될 수 있다.
API 26(오레오) 이상 부터 앱이 포그라운드에 있지 않을 때 백그라운드 서비스를 강제로 종료시킨다!(제한을 적용) 이를 위해, 앱이 scheduled job을 대체로 사용해야 한다
예를 들면, 사용자의 위치 정보를 가지고 올 때 사용된다.
서버 - 클라이언트 구조에서 서버에 해당된다.
액티비티와 같은 컴포넌트들이 바인드 한 후 요청을 보내고, 응답을 받고, 프로세스간 통신(IPC)를 할 수 있도록 만들 수 있다.
바인드된 서비스의 경우 보통 다른 앱 컴포넌트들에 바인드 되어 있는 동안 살아있어서 백그라운드에서 계속 실행되는 것은 아니다!
이 두가지 방식의 서비스는 같이 실행이 가능한데 이 말인 즉슨 한 서비스에서 bindService()와 startService()의 실행이 동시에 가능하다.
Service에서는 안드로이드의 다른 컴포넌트 처럼 생명주기 메서드들이 있다 이를 살펴보자
이 메서드가 실행될 시 백그라운드에서 무한히 실행되므로, 반드시 stopSelf() 혹은 stopService()로 서비스를 종료시켜야한다.
바인드 서비스만 이용하는 경우에 이 메서드를 사용하지 않아도 된다.
onStartCommand()의 Return값을 살펴보면 다음이 있다
START_NOT_STICKY : 시스템이 서비스의 onStartCommand()를 반환 후에 중단시키면 서비스를 재생성하면 안됨
START_STICKY : 시스템이 onStartCommand()를 반환 후 서비스를 중단하는 경우 서비스를 자동으로 다시 생성하고 마지막 인텐트는 전달하지 않는다. 이때 Intent를 null로 반환한다.
START_REDELIVER_INTENT : 시스템이 onStartCommand()를 반환 후에 서비스를 다시 생성하고 이 서비스에 전달된 마지막 인텐트로 onStartCommand()를 호출시 모든 보류 인텐트가 차례로 전달된다.
즉시 재개되어야 하는 작업을 수행하는데 파일 다운로드에 적합하다.
START_STICKY의 경우 필요에 의해 명시적으로 시작되고 중단되는 서비스에 사용되며
나머지 둘의 경우에는 전송된 명령을 처리하는 동안에만 서비스가 실행되어야 하는 경우에 사용된다.
안드로이드의 구성요소가 서비스에 바인딩하고자 하는 경우, 이 메소드가 호출된다.
이 메소드를 구현할 때에는 클라이언트가 서비스와 통신을 주고 받기 위해 사용할 인터페이스를 제공해야 하낟.
이를 위해 IBinder를 반환하면 된다.
이 메서드는 항상 구현해야 하지만, 바인딩을 허용하지 않으려면 null을 반환하면 된다.
서비스와 바인드 된 구성요소가 중단되거나 예기치 않게 서비스와 연결이 끊어졌을 때 호출된다.
unBind()를 통해 호출되었을 경우에는 호출되지 않는다.