반응형

 "Service" 는 UI 없이 백그라운드에서 특정 작업을 수행하는 프로세스를 말한다. Android Framework 에서는 어플리케이션 개발에 필요한 중요 API 들을 "시스템 서비스" 형태로 지원한다.



 안드로이드 서비스는 프레임워크에서 제공하는 

1)"시스템 서비스"

와 어플리케이션 개발자가 Service 클래스를 상속해서 구현한 

2) "어플리케이션 서비스"

로 구별할 수 있다.


1) 시스템 서비스는 

자바 영역에서 동작하는 "자바 시스템 서비스"와 

C/C++ 영역에서 동작하는 "네이티브 시스템 서비스"로 나뉘며, 

"자바 시스템 서비스"는 "코어 플랫폼 서비스" 와 "하드웨어 서비스"로 구별된다.


2) 어플리케이션 서비스는

Activity와 동일 프로세스(다시 말해 동일 패키지 내에서)에서 서비스가 실행되는 "로컬 서비스"와

Activity와 다른 프로세스에서 서비스가 실행되는 "원격 서비스"로 구별된다.

"로컬 서비스"는 자신을 생성한 액티비티가 종료되면 종료된다. "원격 서비스"는 독립적인 프로세스로 동작하기 떄문에 메인 어플리케이션이 종료되도 동작하지만, 시스템 자원을 계속 사용하기 때문에 주의해야 한다.


[어플리케이션 서비스]

  어플리케이션 서비스는 안드로이드 SDK의 Service 클래스를 확장한 것으로, UI 없이 주기적으로 특정한 일을 수행하는 백그라운드 프로세스를 가르킨다. 어플리케이션 서비스는 다음의 두가지를 제공한다.

 1) 서비스 시작, 종료

 2) 바인딩을 통한 서비스 메소드 호출


 어플리케이션에서 서비스를 생성할 때 단순히 백그라운드 잡을 실행 시키는 경우와 바인딩을 통해 메서드를 이용하는 경우에 따라서 startService(), bindService() API를 이용한다. 두 경우에 따라 라이브사이클이 달라진다. 다음은 서비스의 라이프 사이클이다.

 binding 되는 서비스의 경우 클라이언트의 바인딩 Action에 따라서 다음과 같은 라이프사이클을 가진다.



 앞서 설명한 것과 같이 서비스가 실행되는 프로세스 영역에 따라서 "로컬 서비스"와 '원격 서비스"로 나뉜다고 하였다. 로컬 서비스는 로컬 서비스의 레퍼런스만 얻으면 되지만 원격 서비스는 서비스를 이용하는 액티비티와는 다른 프로세스에서 동작하기 때문에 IPC 메커니즘을 이용해야 한다. (바인더IPC 이용)


 바인더IPC를 이용하기 위해서는 데이터를 Marshaling/Unmarshaling 하기 한 인터페이스를 AIDL(Android Interface Definition Language)로 정의한다. AIDL를 정의하면 Stub과 Proxy 에 대한 자바 소스를 생성해 준다. 다음 그림은 어플리케이션에서 로컬 서비스워 원격 서비스의 동작 방식의 차이에 대한 설명이다.


[시스템 서비스]

  어플리케이션 작성을 위한 시스템의 핵심 기능들을 제공하는 것으러, 안드로이드 프레임워크의 어플리케이션 프레임웍 및 라이브러리 레이어에 각각 존재한다. 


 자바 영역과 Native 영역을 구별해서 볼 경우에 다음의 프레임워크에서 Application Framework 에서 자바 시스템 서비스(코어 플랫폼 서비스 + 하드웨어 서비스)와 라이브러리 영역에서 네이티브 서비스를 제공해 준다고 생각하면 된다.


(네이티브 시스템 서비스)

C++로 작성되어 있으며 라이브러리 레이어에서 동작한다. 주요한 서비스로 Audio Flinger, Surface Flinger등이 있다.

 AudioFlinger는 여러 안드로이드 애플리케이션의 오디오 데이터를 믹싱해서 오디오 출력 장치로 내보내는 역활을 한다.


 마찮가지로 다양한 어플리케이션의 Surface를 조합해서 프레임버퍼 장치로 렌더링 해준다.

이 외에 Camera 입/출력을 담당하는 카메라 서비스가 있다.


(자바 시스템 서비스)

 자바 시스템 서비스는 부팅시 System Server에 의해서 일괄적으로 실행되며 코어 플랫폼 서비스와 하드웨어 서비스로 나뉜다.

1. 코어 플랫폼 서비스

Activity Manager Service : 액티비티에 대한 라이프 사이클 및 스택 관리

WIndow Manager Service : Surface Flinger 위에 위치,  화면에 그릴 내용을 Surface Flinger로 전달

Package Manager Service : apk 의 정보를 로딩하고, 어떤 패키지가 설치, 로딩되는지에 대한 정보 전달


2. 하드웨어 서비스

 Alarm Manager Service : 타이머 서비스 제공

 Connectivity Manager : 네트워크의 현재 상태에 대한 정보 제공

 Location Service : 단말의 현재 위치 정보 제공

 Power Service : 장치의 전원 관리 제어

 Sensor Service : 안드로이드에 설치된 각종 센서(마그네틱 센서, 가속도 센서 등) 제어

 Telephony Service : 전화기의 상태나 전화 서비스에 대한 정보 제공

 WiFi Service : AP 검색이나 연결 리스트 관리 등 무선랜 연결을 제어


 어플리케이션 서비스를 실행하기 위해서는 startService() 같은 SDK의 API를 이용했지만, 시스템 서비스는 직접 실행할 필요가 없으며 getSystemService() 함수를 이용해서 해당 인스턴스를 생성할 수 있다. 왜냐하면 시스템 서비스는 init 프로세스에 의해서 안드로이드 부팅시 미리 실행되기 때문이다.

 시스템 서비스는 Media Server와 System Server라는 두 시스템 프로세스에 의해 실행되며, 미디어 프로세스는 Surface Flinger를 제외한 Audio Flinger, Media Playser Service 와 같은 네이티브 서비스를 실행한다. MediaServer 소스는 /frameworks/av/media/mediaserver 에 있다.main_mediaserver.cpp 에 보면 미디어 서버에서 인스턴스를 생성하는 부분을 볼 수 있다.

        sp<ProcessState> proc(ProcessState::self());

        sp<IServiceManager> sm = defaultServiceManager();

        ALOGI("ServiceManager: %p", sm.get());

        AudioFlinger::instantiate();

        MediaPlayerService::instantiate();

        CameraService::instantiate();

        AudioPolicyService::instantiate();

        registerExtensions();

        ProcessState::self()->startThreadPool();

        IPCThreadState::self()->joinThreadPool();

 각각의 서비스가 instantiate 될때 해당 서비스에서 바인더IPC를 위해서 Context Manager(Service Manager)에 서비스를 등록한다.


 System Server는 자바 시스템 서비스를 실행한다. (참고로  surfaceflinger 는 init.rc에서 실행된다.)

 시스템 서버가 실행되고 서버쓰레드들을 만들면서 자비 시스템 서비스를 생성하고 등록하는 부분은  이전 포스팅 [Zygote 설명#2]에서 설명 하였다.


(시스템 서비스 동작 원리)

 시스템서비스는 바인더 드라이버를 통해서 호출된다. 


 서비스를 받는 프로세스(Process A, 서비스 클라이언트), 와 서비스를 제공하는 프로세스(ProcessB, 서비스 서버)는 AIDL 기반으로 정의된 Proxy와 Stub, Binder 클래스 등을 통해서 통신하며 이를 서비스 프레임워크라고 한다.

 다음 그림에서 초록색의 Framework 부분이 이에 해당한다. (Binder 라고도 한다.)



반응형
Posted by alias
,