안드로이드 서비스

* 서비스: 유저와 상호작용없이 장시간동안 백그라운드로 동작하는 애플리케이션 컴포넌트

각 서비스 클래스는 패키지의 AndroidManifest.xml에 자신과 일치하는 <service> 태그가 있어야 한다.

서비스는 Context.startService()나 Context.bindService()로 시작할 수 있다. 

* 비활성 액티비티보다 더 높은 우선순위를 갖는다. 

* 서비스의 시작과 종료는 다른 서비스, 액티비티, 브로드캐스트 수신자를 포함한 다른 애플리케이션으로부터 조작이 가능

* 인텐트 오브젝트를 받을 수 있는 시점: onStart(), onBind(), onUnbind()

Service Lifecycle Changes 

안드로이드 플랫폼과 Service 간 상호작용시 서비스가 정상 종료되지 않고 백그라운드에 남아 있는 경우가 있다. 

1. 애플리케이션이 startService를 호출

2. Service의 onCreate, onStart() 함수가 호출되고, 특정한 작업을 수행하기 위해 백그라운드 스레드가 생성

3. 시스템이 메모리 부족으로 현재 작동중인 서비스를 강제로 종료

4. 메모리 상황이 호전되면 서비스가 재시작, 이때 서비스의 onCreate함수는 호출되지만 onStart는 호출되지 않는다. 

문제점 >> 이와 같은 경우 서비스는 생성된 채로 남아있게 된다. 어떠한 일을 수행하지도 않으면서 어떤 시점에서 종료되어야 하느지도 알 수 없다.  

위와 같은 문제를 해결하기 위해 안드로이드 2.0에서 서비스에서 onStart()는 더이상 사용되지 않는다.

대신 Service.onStartCommand() 콜백함수가 사용된다. 기존 API와는 달리 onStartCommand()는 결과 값을 반환한다. 안드로이드 플랫폼은 이 결과값을 기반으로 만일 작동중인 서비스가 강제로 종료될 경우, 어떠한 일을 수행해야 하는지 판단한다. 

* Service onStartCommand의 return 값

• START_STICKY 기본적으로 이전과 동일하게 작동. 이전 버전과의 차이점은 기본에 프로세스가 강제 종료된 후 서비스가 재 시작될 때, onStart() 콜백이 호출되지 않았지만, START_STICKY 형태로 호출된 서비스는 null Intent가 담긴 onStartCommand() 콜백함수가 호출된다. 이 모드를 사용하는 서비스는 null Intent로 onStartCommand() 콜백 함수가 호출되는 경우를 주의깊게 처리해야 한다. 
• START_NOT_STICKY 모드로 시작된 서비스는 안드로이드 플랫폼에 의해 프로세스가 강제로 종료되는 경우, 다시 시작되지 않고 종료된 상태로 남게된다. 이러한 방식은 특정 Intent로 주어진 명령을 수행하는 동안에만 서비스가 실행되면 되는 경우에 적당하다. 예를 들어 15분마다 네트워크 상태를 체크하기 위해 실행되는 서비스를 생각해 보면, 만일 이 서비스가 작업도중 강제로 종료될 경우 이 서비스를 재시작하기보다는 정지된 상태로 남겨두고, 15분 후에 새롭게 시작되도록 하는 것이 최선이다. 
• START_REDELIVER_INTENT는  START_NOT_STICKY와 유사하다. 단, 프로세스가 강제로 종료되는 경우 Intent가 다시 전달되어 서비스가 재시작한다.(단, 여러차례 시도한 후에도 작업이 종료되지 않으면 서비스는 재시작되지 않는다) 이 모드는 전달받은 명령을 방드시 수행해야 하는 서비스에 유용하다. 

* onDestroy - 액티비티가 종료될 때 호출되는 콜백 API