• 자바 서비스 프레임워크
  : 네이티브 서비스 프레임워크에서 제공하는 4가지 핵심 기능을 동일하게 제공하지만 시스템 내부에서 서비스가 동작하는 메커니즘이나 서비스 작성 방법에 있어서는 차이점이 있다.
  : 안드로이드 서비스 프레임워크가 자바 레이어와 C++ 레이어별로 존재하며 JNI를 통해 서로 연결돼 있음, JNI를 통해 네티이브 서비스 프레임워크를 재사용함으로써 자바 레이어의 서비스 사용자가 자바로 작성된 서비스뿐만 아니라 C++로 작성된 서비스도 이용할 수 있게 된다.
  
  
  : 자바 서비스 프레임워크는 네이티브 서비스 프레임워크와 다음과 같은 차이점이 있다.
   1. 서비스 생성: 자바 서비스 프레임워크에서 자바 서비스를 개발하는 방법은 두 가지다. 첫 번째 방법은 Binder 클래스를 상속받아 개발하는 것으로, 서비스를 정밀하게 제어해야 할 때 적절한 방식으로 자바 시스템 서비스를 작성할 때도 쓰이는 방법이다. 다행인 점은 안드로이드 개발자 도구에서 서비스 인터페이스와 서비스 생성코드를 자동으로 생성해 주는 AIDL 언어와 컴퍼일러를 제공하고 있어 네이티브 시스템 서비스를 제작하는 것보다 쉽게 자바 시스템 서비스를 작성할 수 있다.
  두 번째 방법은 Service 클래스를 상속받아 개발하는 것인데 일반적으로 특정 작업을 주기적으로 백그라운드에서 수행하는 프로세스를 구현하는 데 사용된다.
   2. 바인더 IPC 처리: 자바 서비스 프레임워크에서는 바인더 IPC를 지원하기 위해 JNI를 통해 연결된 네이티브 서비스 프레임워크의 구성요소를 재사용한다.
  
   ■ 자바 서비스 관리
   1. 자바 시스템 서비스는 네이티브 시스템 서비스와 마찬가지로 컨텍스트 매니저에 서비스를 등록한 후 서비스 매니저를 통해 서비스를 사용할 수 있다.
   2. 액티비티 매니저 서비스에서 관리.
  
  - 레이어
  
  
   : 각 레이어별로 네이티브 서비스 프레임워크와 차이점
  1. 서비스 사용자의 서비스 레이어에 매니저(Manager) 클래스가 위치
  2. RPC 레이어에 AIDL 도구로 자동 생성된 스텁(Stub)과 프록시 클래스(Proxy)가 위치
  3. IPC 레이어에 위치한 구성요소가 JNI를 통해 네이티브 서비스 프레임워크의 구성요소와 연결 
  
  
  -클래스별 상호작용
  

  
  
  - 구성요소 간의 상호작용
  

  
  (1) 서비스 등록 요청(서비스)
   : 네이티브 서비스 프레임워크에서 서비스를 시스템에 등록할 때는 네이티브 서비스 매니저인 BpServiceManager를 통해 서비스 등록 과정을 처리했지만 자바 서비스 프레임워크는 자바 서비스 매니저인 ServiceManager 클래스를 이용해서 이 과정을 처리한다. FooService 서비스는 자신을 시스템에 등록하기 위해 ServiceManager의 addService() 매서드를 호출한다. ServiceManager 내부에는 BinderProxy가 있으며, BinderProxy는 컨텍스트 매니저를 가리키는 BpBinder와 JNI를 통해 연결돼 있다.
  
  (2) 서비스 등록(서비스 매니저)
   : ServiceManagerProxy 서비스 프록시는 addService() 매서드의 호출 정보를 RPC 데이터로 변환한다. 이때 바인더 RPC 데이터는 Parcel 클래스에 저장되어 BinderProxy에 전달되고, JNI를 통해 BpBinder에 전달된다. 그러고 나서 바인더 IPC를 통해 컨텍스트 매니저에 전달되어 FooService 서비스가 시스템에 등록된다.
  
  (3) 서비스 검색 요청(서비스 사용자)
   : FooService 서비스를 사용하기 위해 네이티브 서비스 사용자는 BpServiceManager를 통해 서비스를 검색했지만 자바 서비스 사용자는 SDK에서 제공하는 getSystemService() 메서드를 호출해서 서비스를 검색한다.
  
  ■ Parcel
  

  

  
  
  

• 자바 서비스 매니저
  
  
  - ServiceManager.java
  
  
  
• 코어플랫폼 서비스
   : SystemServer 시스템 프로세스에서 일괄적으로 실행 
   : 애플리케이션이 직접 사용 하진 않지만, 프레임워크의 동작에 관여하는 서비스
   : Activity Manager Service, Window Manager Service, Package Manager Service 등
  
  - ActivityManagerService
   : 자바 시스템 서비스의 일종인 코어 플랫폼 서비스로서 안드로이드 애플리케이션 컴포넌트인 액티비티, 서비스, 브로드캐스트 리서버 등을 생성하고, 이들의 생명주기를 관리하는 역할
  
  
  
  

  
  

  
  

  
  

  
  

• 서비스 프레임워크 
  

  
  : 안드로이드 플랫폼에서 동작하는 서비스를 개발하기 위한 클래스의 집합
  : 서비스의 설계와 구현을 재사용 가능한 형태로 제공
  
  ■ 서비스 인터페이스 : 서비스 인터페이스는 서비스가 제공하는 기능을 함수 형태로 선언하여 이를 상속받은 서비스와 서비스 프록시가 모두 동일한 인터페이스로 서비스를 제공하고 사용할 수 있는 구조를 제공한다.
  ■ 서비스 생성 : 서비스 생성 기능은 서비스와 서비스 프록시의 생성을 지원한다. 서비스에서는 서비스 인터페이스에 정의된 함수를 구현(서비스 스텁 함수)하고 서비스 프록시에서는 서비스 스텁 함수를 원격 호출(서비스 프록시 함수)할 수 있게 구현해준다. 서비스 프레임워크에서는 서비스 프록시가 서비스를 요청할 수 있게 서비스의 위치 정보(서비스 핸들)를 제공하고, 서비스가 서비스 요청을 수신할 수 있는 방법을 제공한다.
  ■ 바인더 IPC 처리 : 서비스 프레임워크는 서비스와 서비스 사용자 사이에 바인더 IPC를 지원하기 위해 바인더 IPC 데이터를 생성하고 바인더 드라이버와 통신할 수 있는 기능을 제공한다.
  ■ 서비스 매니저 : 서비스 매니저는 시스템에 서비스를 등록하고 검색할 수 있는 기능을 제공한다.
   
  
  

• 네이티브 서비스 프레임워크
  : C++로 작성되어 있으며, library layer에서 동작
  
  
  

  - 레이어
   
  
   1. 서비스 사용자가 foo() 함수를 호출하면, BpFooService의 foo() 프록시 함수가 호출 된다.
   2. BpFooService의 foo() 프록시 함수는 TRANSACTION_FOO RPC 코드와 인자값을 RPC 데이터로 변환한 후, BpBinder 클래스의 transact() 함수를 호출해서 RPC 코드와 데이터를 전달한다.
   3. BpBinder의 transact() 함수는 전달받은 RPC 코드와 데이터에 FooService 서비스의 서비스 핸들 정보를 추가한 후 IPCThreadState 클래스의 transact() 함수에 인자로 전달한다.
   4. IPCThreadState 클래스의 transact() 함수는 전달받은 데이터에 BC_TRANSACTION 바인더 프로토콜을 추가하여 바인더 IPC 데이터를 생성하고 이것을 바인더 드라이버에 전달한다.
  
   4. 바인더 드라이버는 IPCThreadState에게 바인더 IPC 데이터 정보를 전달한다. 그러면 IPCThreadState의 executeCommand() 함수에서 데이터를 분석하여 BR_TRANSACTION 바인더 프로토콜인 경우에 BBinder 클래스의 transact() 함수를 호출한다. 이때 transact() 함수의 인자로 서비스 클라이언트로부터 수신된 RPC 코드와 데이터가 전달된다.
   3. BBinder는 RPC 코드를 분석하여 기본적으로 제공하는 서비스 함수가 아닌 경우에 onTransact() 함수를 호출한다. 그런데 BnFooService가 BBinder를 상속하여 onTransact() 함수를 재정의했으므로 BnFooService 서비스 스텁의 onTransact() 함수가 호출된다. BBinder로 부터 전달받은 데이터는 다시 onTransact()의 인자로 전달한다.
   2. BnFooService의 onTransact()에서는 전달받은 RPC 데이터를 분석하여 TRANSACTION_FOO RPC 코드가 의미하는 FooService의 foo() 스텁 함수를 호출한다. 일반적으로 스텁 함수 호출시 RPC 데이터에 대한 언마샬링이 수행되어 인자로 전달되지만, foo() 스텁 함수는 인자가 없으므로 언마샬링이 수행되지 않는다.
   1. FooService의 foo() 서비스 스텁 함수가 실행된다.

  
  - 프록시
  
  
  

  - 스텁
  
  
  - 바인더 연결
  
  
  

• 클래스 구조
  
  
  - IBinder, BBinder, BpBinder 
   : IBinder 클래스는 안드로이드 바인더를 추상화한 것이며 자식 클래스로 BBinder, BpBinder 클래스가 있다.
    BBinder 클래스는 RPC 코드와 데이터를 수신하는 역할과 바인더 드라이버 내부에 바인더 노드를 생성할 때 이용하는 바인더 객체로서의 역할을 담당.
    BpBinder 클래스는 목적지 서비스의 핸들 정보를 저장하고 바인더 드라이버가 서비스 서버의 바인더 노드를 찾을 때 이용하는 바인더 객체로서의 역할을 담당.  
  - IInterface, BnInterface, BpInterface
   : IInterface 클래스는 서비스나 서비스 프록시 클래스를 IBinder 타입으로 형변환하는 기능을 제공한다. 실제로 형변환은 BnInterface 클래스와 BpInterface 클래스에서 일어나며, BnInterface는 서비스 클래스를 BpInterface는 서비스 프록시 클래스를 IBinder 타입으로 형변환한다. 형변환이 필요한 이유는 바인더 객체를 바인더 드라이버를 통해 전송해야 하기 때문이다. 예를 들어, 서비스를 시스템에 등록하는 경우 서비스 클래스를 IBinder 타입으로 형변환해서 컨텍스트 매니저에 전달해야한다.
  - ProcessState, IPCThreadState
   : ProcessState  클래스는 바인더 드라이버를 관리하며 IPCThreadState 클래스는 서비스 클라이언트 및 서비스 서버와 바인더 드라이버 간의 바인더 IPC를 위한 통신을 지원한다.
  - Parcel
   : Parcel 클래스는 서비스와 서비스 프록시 사이에서 바인더 IPC가 진행되는 동안 바인더 IPC 데이터를 저장하는 역할을 담당한다. Parcel 클래스가 처리할 수 있는 데이터는 C언어의 기본 자료형 및 기본 자료형의 배열, 바인더 객체, 파일 디스크립터 등이 있다.
  - 서비스 레이어
   : IInterface, BnInterface, BpInterface, BpRefBase, 서비스 인터페이스, 서비스 클래스
  - RPC 레이어
   : 서비스 프록시 클래스, 서비스 스텁 클래스
  - IPC 레이어
   : BBinder, BpBinder, IPCThreadState, ProcessState, Parcel
  
  

• 네이티브 서비스 매니저
  : 안드로이드 플랫폼에는 오디오 디바이스를 관리하는 Audio Flinger, 화면으로 보이는 프레임 버퍼 디바이스를 관리하는 Surface Flinger, 카메라 디바이스를 관리하는 카메라 서비스 등 각종 서비스가 있고, 이러한 서비스의 정보와 목록을 컨텍스트 매니저가 관리, 서비스는 자신의 이름으로 컨텍스트 매니저에 서비스 등록을 요청하고, 서비스 사용자는 접근하고자 하는 서비스의 이름으로 컨텍스트 매니저로부터 서비스의 정보를 획득.
  : 서비스 프레임워크에서는 서비스 사용자가 Audio Flinger, Surface Flinger, 카메라 서비스와 같은 각 서비스에서 제공하는 기능을 사용할 수 있게 바인더 RPC를 처리해 주는 서비스 프록시(Service Proxy)를 제공, 서비스 사용자는 서비스 프록시를 통해 해당 서비스의 기능을 사용하며, 서비스 프록시와 서비스 간의 복잡한 바인더 RPC는 하위 수준의 서비스 프레임워크에서 이뤄지므로 상위 수준의 서비스 사용자는 마치 동일한 프로세스에서 서비스를 이용하는 것처럼 느끼게 된다. 즉 서비스 프록시를 서비스라 생각하게 되는 것
  : 서비스 매니저는 컨텍스트 매니저의 서비스 프록시에 해당
   

  
  : 네이티브 서비스 매니저는 (2)에 해당한다.
  : 자바 시스템 서비스는 (3)의 자바 레이어의 서비스 매니저를 통해 서비스를 등록하고,
  네이티브 시스템 서비스는 (2)의 C/C++ 레이어의 서비스 매니저를 통해 서비스를 등록한다.
  (3)의 자바 레이어의 서비스 매니저는 JNI를 통해 (2)의 C/C++ 레이어의 서비스 매니저와 연결되고, C/C++ 레이어의 서비스 매니저는 바인더 드라이버를 통해 (1)의 컨텍스트 매니저와 바인더 RPC를 수행한다.
  
  

  - 서비스 매니저의 클래스 계층 구조와 바인더 RPC 과정
  
  

  
  - 서비스 매니저의 동작
  1. 서비스 매니저 초기화
   
  
  

  2. 서비스 등록
   
  3. 서비스 획득
   
  
  - 바인더 RPC 데이터와 코드, 바인더 IPC 데이터의 처리 과정
  

  

  
  

• 바인더?
  : 원래 IPC(Inter Process Communication) 도구이지만 안드로이드에서는 다른 프로세스에 있는 함수를 마치 현재 프로세스에 존재하는 함수처럼 사용할 수 있게 해주는 RPC(Remote Procedure Call)를 지원하는 데 주로 이용
  - 안드로이드에서 바인더 드라이버를 추가해서 프로세스 간 통신을 수행하는 이유? 
   : 리눅스의 뛰어난 메모리 관리 기법을 그대로 채용함으로써 커널 공간을 통한 데이터 전달시 데이터의 신뢰성을 확보
   : 사용자 공간에서 접근할 수 없는 공간인 커널 공간을 이용해 데이터를 주고 받기 때문에 IPC 간의 보안 문제도 동시에 해결
  

    
  
  
  

• 리눅스 메모리 공간과 바인더 드라이버
  : 안드로이드의 프로세스는 리눅스와 마찬가지로 프로세스만의 고유한 가상 주소 공간에서 실행
  : 총 4GB에 달하는 가상 주소 공간은 3GB의 사용자 공간과 1GB의 커널 공간으로 나뉜다(커널 설정으로 변경 가능함)
  : 사용자 코드와 관련 라이브러리는 사용자 공간의 코드 영역, 데이터 영역, 스택 영역에서 동작하고, 커널 공간에서 동작해야 할 코드는 커널 공간의 각 영역에서 동작
  : 서로 다른 프로세스들은 커널 공간에서 실행하는 태스크와 데이터, 코드는 서로 공유
  : 바인더 드라이버에 존재하는 다양한 구조체는 대부분 레드 블랙 트리로 관리
  
  
  

• 안드로이드 바인더 모델
  : 핸들은 서비스를 구별하는 번호, 어떤 서비스에 바인더 IPC 데이터를 전달해야 하는지를 결정
  : RPC 코드와 RPC 데이터는 서비스에 호출할 함수와 함수의 인자
  : 바인더 프로토콜은 IPC 데이터의 처리 방법
  

  
  
  - 바인더 IPC 데이터의 전달
   : 바인더를 통해 RPC를 시도하는 응용 프로그램은 open() 시스템 콜을 통해 바인더 드라이버의 파일 디스크립터를 얻는다.
   : mmap() 시스템콜을 통해 커널 내에서 IPC 데이터를 수신하기 위한 공유 공간을 확보한다.
   : ioctl() 함수의 인자로 바인더 드라이브에 IPC 데이터를 전달한다.
  
  
  
  - 바인더 IPC 데이터의 흐름
   ■ 서비스 계층: 특정 기능을 수행하는 서비스의 함수가 존재하는 계층이다. 서비스 클라이언트는 이 계층에서 사용하고자 하는 서비스의 함수를 가상으로 호출하고, 서비스 서버는 서비스 클라이언트가 요청한 서비스의 함수를 실제로 호출한다.
   ■ RPC 계층: 서비스 클라이언트는 이 계층에서 서비스의 함수를 호출하기 위한 RPC 코드와 RPC 데이터를 생성한다. 서비스 서버는 전달받은 RPC 코드를 토대로 함수를 찾고 RPC 데이터를 전달한다.
   ■ IPC 계층: RPC 계층에서 만든 RPC 코드와 RPC 데이터를 바인더 드라이버에 전달하기위한 바인더 IPC 데이터로 캡슐화하는 역할을 한다. 실제로 서비스 클라이언트는 서비스 서버에 존재하는 서비스의 함수를 사용하기 위해 각 함수에 해당하는 식별자를 바인더 IPC 데이터에 담아 전달하는데, 이를 RPC 코드라 하며 함수의 인자 역시 IPC 데이터에 담아 전달하는데, 이것은 RPC 데이터라고 한다.
   ■ 바인더 드라이버 계층: IPC 계층으로부터 전달받은 바인더 IPC 데이터를 통해 서비스를 가진 서비스서버를 찾은 후 IPC 데이터를 전달한다.
  
  
  - 바인더 어드레싱
   : 바인더 드라이버는 IPC 데이터의 핸들을 가지고 서비스 서버를 찾는데, 이러한 과정을 바인더 어드레싱(Binder Addressing)이라고 정의
   : 다양한 서비스를 모두 목록화해서 관리하는 컨텍스트 매니저라는 특별한 프로세스가 서비스마다 핸들(바인더 IPC의 목적지 주소로 사용)라는 번호 값을 할당하고, 서비스 추가/검색 등의 관리 기능을 수행
  
   ■ 서비스 등록
    : 바인더 어드레싱을 위해 서비스 서버는 자신이 가진 서비스에 대한 접근 정보를 컨텍스트 매니저에 등록해야 한다.
    : 안드로이드 부팅 단계에서 끝나고, 등록이 끝나면 컨텍스트 매니저의 서비스 목록, 바인더 드라이버의 바인더 노드, 그리고 서비스 서버들의 서비스가 연결되어 다른 프로세스가 사용가능한 상태가 된다.
    : 서비스 서버와 컨텍스트 매니저 사이의 IPC
  
   
   ■ 서비스 검색
    : 서비스 클라이언트와 컨텍스트 매니저 사이의 IPC
  

  

  
   ■ 서비스 사용
    : 서비스 클라이언트와 서비스 서버 사이의 IPC
  
  
  ※ mmap
   
    : 일반적으로 커널 공간에서 사용자 공간으로 데이터를 전달하기 위해서는 copy_to_user() 함수를 이용해서 사용자 공간으로 데이터를 복사한다.
    : but, 대용량의 데이터를 응용 프로그램과 주고 받아야 하는 상황에서 read, write, ioctl 같은 시스템 콜 함수를 쓴다면 매우 비효율적이며, 커널 공간이 부족할수 있다. -> 문제점을 해결하기 위해 mmap을 사용, 응용 프로그램이 커널의 물리 메모리에 직접 접근 가능하도록 해 준다.
    : 바인더를 이용하는 프로세스는 바인더 드라이버의 mmap() 함수를 통해 사용자 공간과 매핑된 바인더 mmap 영역을 만든다. 그리고 바인더 드라이버는 커널 공간의 데이터 수신영역에 데이터를 저장만하고, 사용자 공간에 mmap 된 영역의 정보만 알려준다. 따라서 프로세스는 사용자 공간의 mmap 된 영역의 주소만 알고 있어도 커널 공간에 존재하는 데이터를 참조 할 수 있다.
    : 이 함수의 주요 목적은 사용자 프로세스가 전달한 크기만큼 커널 공간에 IPC 데이터 수신 버퍼를 확보하는 것이다.
  
  

• 정리
   : 바인더는 안드로이드의 서비스를 보유한 서비스 서버, 서비스를 사용하고자 하는 서비스 클라이언트, 서비스의 위치를 알려주는 컨텍스트 매니저, 그리고 이들 모두를 중재하는 바인더 드라이버로 구성된다.
  

  
  

• 서비스?
  : UI 없이 주기적으로 특정한 일을 수행하는 백그라운드 프로세스
  
  - 서비스 분류
  
  
  

• 안드로이드 애플리케이션 서비스
  : 안드로이드 SDK의 Service 클래스를 확장한 클래스의 인스턴스로 UI 없이 주기적으로 특정한 일을 수행하는 백그라운드 프로세스
  : 애플리케이션단에서 서비스 시작, 종료, 바인딩을 통한 서비스 원격 제어 가능
   
  
  - 애플리케이션 서비스 분류
  
  
  

• 안드로이드 시스템 서비스
  : init 프로세스에 의해 안드로이드의 부팅 과정에서 미리 실행
  : getSystemService()를 이용해서 바로 이용 가능
  : Media Server, System Server 두 시스템 프로세스에 의해 실행
  
  - 시스템 서비스 분류
  
  
   ■ 네이티브 서비스
    : C++로 작성
    : 여러 안드로이드 애플리케이션의 오디오 데이터를 믹싱해서 오디오 출력 장치로 내보내는 역할, 안드로이드 장치에서 모든 오디오 데이터는 Audio Flinger를 거쳐 출력.
    : Surface Flinger는 다양한 애플리케이션에서 사용중인 Surface를 조합해 프레임 버퍼 장치로 렌더링해주는 서비스 
  
   ■ 자바 시스템 서비스
    : 안드로이드 부팅 시 SystemServer라는 시스템 프로세스에 의해 일괄적으로 실행
    : 안드로이드 애플리케이션과 직접 상호작용은 하지 않지만 안드로이드 프레임워크가 동작하는 데 필수적인 코어 플랫폼 서비스
    : 저수준 하드웨어 제어를 위한 API를 제공하는 하드웨어 서비스
  
  - Layer Interaction
   : There are 3 main flavors of Android layer cake
   1. App -> Runtime Service -> lib
    
   2. App -> Runtime Service -> Native Service -> lib
    
   3. App -> Runtime Service -> Native Deamon -> lib
    
  
  - Media Server / System Server

    ■ Media Server
    
    ■ System Server
    
    ■ Context Manager
      : 서비스 관련 요청을 수행하기 위해서는 IPC 데이터를 수신 대기하는 상태에 들어 있어야 하기 때문에 다른 서비스 서버나 서비스 클리이언트 이전에 미리 실행돼야한다.
      : init.rc 내용을 살펴보면 서비스 서버인 미디어 서버 프로세스나 시스템 서버 프로세스가 실행되기 이전에 실행(servicemanager) 됨
  
  

    
  
  

• 안드로이드 시스템 전체 요약
  - 용어 정리
    ■ 서비스 서버 : 시스템 서비스를 실행하는 프로세스로서 앞에서 설명한 시스템 서버나 미디어 서버
    ■ 서비스 클라이언트 : 시스템 서비스를 사용하는 프로세스
    ■ 컨텍스트 매니저 : 시스템 서비스를 관리하는 안드로이드 시스템 프로세스로서 시스템에 설치돼 있는 각종 시스템 서비스의 위치 정보인 핸들을 관리. 이러한 핸들은 바인더 IPC의 목적지 주소를 지정하는 데 사용한다.
    ■ 서비스 프레임워크 : 앞에서 언급한 서비스 매니저를 포함해서 서비스 사용자와 시스템 서비스간의 RPC 동작에 필요한 공통적인 클래스가 정의
    ■ 서비스 인터페이스 : 서비스 사용자와 시스템 서비스 간에 미리 정해진 인터페이스로서 시스템 서비스는 해당 인터페이스에 맞게 스텁 함수를 구현해서 해당 서비스를 제공해야 하고, 반대로 서비스 사용자 역시 해당 인터페이스에 맞게 서비스를 호출해야 한다.
    ■ 서비스 사용자 : 서비스 클라이언트 프로세스 내에서 실제 서비스를 이용하는 모듈이다.
    ■ 서비스 : 서비스 인터페이스에 정의된 기능을 서비스 스텁 함수로 구현해서 실제 서비스의 기능을 제공하는 모듈을 의미한다.
    ■ 서비스 프록시 : RPC 수행 시 데이터 마샬링을 수행하는 객체이며 서비스 인터페이스별로 존재한다. 서비스 인터페이스에 정의된 함수별로 각각 데이터 마샬링을 수행하는 서비스 프록시 함수를 제공한다.
    ■ 서비스 스텁 : RPC 수행 시 데이터 언먀실링을 수행하는 객체이며, 이 객체 역시 서비스 인터페이스별로 존재한다. 수신된 데이터를 언마샬링해서 연관된 서비스 스텁 함수를 호출한다.
    ■ 바인더 드라이버 : 바인더는 안드로이드에서 IPC를 지원하는 데 사용되는 메커니즘으로 안드로이드 리눅스 커널의 디바이스 드라이버 형태로 포함돼 있다.
    ■ 바인더 IPC : 안드로이드에서 바인더 드라이버를 통한 프로세스간의 데이터 전달 방식을 말한다.
    ■ 바인더 IPC 데이터 : 서비스 프레임워크와 바인더 드라이버 사이에 사용되는 데이터 포맷
    ■ 바인더 RPC : 서비스 사용자가 서비스에서 제공하는 특정 서비스 인터페이스 기반의 함수를 마치 자신의 로컬 함수 호출하듯이 원격으로 처리하는 동작을 말한다. 바인더 RPC는 내부적으로는 바인더 IPC 메커니즘 기반으로 동작한다.
    ■ 바인더 RPC 데이터 : 서비스 사용자와 서비스 간의 바인더 RPC를 수행하는 데 사용되는 데이터
  
  - 서비스 동작 구조
  
  
  
   : 서비스 사용자는 foo() 프록시 함수를 호출해서 Foo 서비스를 이용하기 위한 인자로 구성된 바인더 RPC 데이터를 전달
   : 바인더 RPC 데이터는 마샬링을 거쳐 서비스 프레임워크를 통해 바인더 IPC 데이터로 생성된 다음, 바인더 드라이브를 통해 서비스 서버 측에 전송
   : 서비스 서버 측에서 수신된 바인더 IPC 데이터는 서비스 프레임워크를 거치면서 언마샬링된 다음, 서비스 스텁의 OnTransact() 함수에 전송
   : 서비스 스텁은 해당 바인더 IPC 데이터 안에 포함된 RPC 코드를 통해 Foo 서비스의 foo() 서비스 스텁 함수에 대한 바인더 RPC임을 판단
   : 수신된 바인더 IPC 데이터에 포함된 바인더 RPC 데이터를 인자로 해서 foo() 서비스 스텁 함수를 호출

  
  
  

• Zygote?
  - '분할 전의 세포나 수정란', 개체가 생성되기 이전의 불완전한 상태
  - 달빅(Dalvik) 초기화 수행
  - 애플리케이션 실행 속도 향상
  - System Server 를 실행
  
  
   안드로이드 애플리케이션은 자바로 작성돼 있어 리눅스 상에서 네이티브 프로세스로 실행될 수 없으며 달빅 가상 머신에서 동작한다. 각 안드로이드 애플리케이션은 독립적인 가상 머신 위에서 동작하는데, 실행될 때마다 자신이 동작할 가상 머신을 초기화하고 실행하는 과정에는 많은 시간이 소요되며 애플리케이션의 실행을 느리게 하는 요인이 된다. 때문에 안드로이드에서 Zygote 프로세스는 애플리케이션이 실행되기 전에 실행된 가상 머신의 코드 및 메모리 정보를 공유함으로써 애플리케이션이 실행되는 시간을 단축시킬 수 있다. 여기에 더해 안드로이드 프레임워크에서 동작하는 애플리케이션이 사용할 클래스와 자원을 미리 메모리에 로딩해 두고 이러한 자원에 대한 연결 정보를 구성한다. 새로 실행되는 안드로이드 애플리케이션은 필요한 자원들에 대한 연결정보를 매번 새롭게 구성하지 않고 그대로 사용하기 때문에 빠르게 실행된다.
  
  

• Zygote를 통한 프로세스의 생성
  
  
  
   : 부모 프로세스 A는 fork() 시스템 콜을 호출하여 새로운 자식 프로세스 A'를 생성 - 새로 생성된 프로세스 A'는 부모 프로세스인 프로세스 A의 메모리 구성 정보 및 공유 라이브러리에 대한 링크 정보를 공유한 상태
   : 자식 프로세스 A'는 exec('B') 시스템 콜을 호출해 새로운 프로세스 B의 코드를 메모리로 로딩한다. 이때 부모 프로세스 A의 메모리 정보는 지워지고 로딩된 B를 실행하는 데 필요한 메모리를 새롭게 구성한 후 프로세스 B가 사용할 공유 라이브러리에 대한 링크 정보를 새로 구성
   : 만약 새로운 프로세스 B가 사용할 공유 라이브러리가 메모리에 이미 로딩돼 있는 상태라면 이에 대한 링크 정보만 새롭게 구성하지만 그렇지 않은 경우에는 스토리지에서 해당 라이브러리를 메모리로 로딩하는 과정이 추가로 필요하다. 이러한 과정이 새로운 프로레스를 실행할 때 마다 일어난다.
   => COW(Copy On Write)를 통해 기존에 이미 메모리 상에서 동작중인 프로세스의 재사용성을 극대화하고 공유 라이브러리를 통해 메모리 사용량(foot print)을 최소화
  - COW(Copy On Write)?
   프로세스를 생성할 때 새로 생성된 프로세스는 부모 프로세스와 메모리 공간을 공유한다. 즉, 자식 프로세스는 부모 프로세스가 생성한 메모리 공간에 관한 정보를 모두 복사하여 그대로 사용하는데, COW는 이러한 메모리 공간을 복사하는 시점에 대한 것이다. 메모리 복사를 하는 것은 오버헤드가 매우 크기 때문에 생성된 자식 프로세스가 부모의 메모리 공간을 참조만 할 경우에는 이를 복사하지 않고 부모의 메모리 공간을 공유하게 된다. 공유하는 메모리 정보를 자식 프로세스가 수정하는 시점에서 부모 프로세스의 메모리 정보를 자신의 메모리 공간으로 복사하는 것이 바로 COW 기법이다.
   만약 fork()를 호출한 이후에 exec()가 바로 실행되면 새로 생성되는 프로세스의 메모리 공간은 부모 프로세스의 메모리 공간과 내용이 다르며, 이 때문에 부모 프로세스의 메모리 공간을 복사하는 것은 무의미하여, 오히려 새로운 프로세스를 실행하는 데 있어 큰 오버헤드를 초래할 뿐이다.
  
  

  
  : Zygote 프로세스는 fork() 시스템 콜을 호출해 자식 프로세스인 Zygote' 프로세스를 생성
  : 생성된 Zygote' 프로세스는 부모인 Zygote 프로세스의 코드 영역과 링크 정보를 공유
  : 새로운 안드로이드 애플리케이션 A는 fork()를 통해 생성된 프로세스의 코드 영역을 새롭게 로딩하는 것이 아니라, 복제된 달빅 가상 머신 위에 동적으로 로딩.
  : Zygote'프로세스는 애플리케이션 A 클래스의 메서드로 실행 흐름을 넘겨 안드로이드 애플리케이션이 동작, 새로 생성된 애플리케이션 A는 기존의 Zygote 프로세스가 구성해 놓은 라이브러리 및 리소스에 대한 링크 정보를 그대로 사용하기에 빠르게 실행
  

• app_process로부터 ZygoteInit class 실행
  - app_process의 역할? 
   : Zygote는 자바로 작성돼 있으므로 다른 네이티브 서비스나 데몬과 같이 init 프로세스에서 바로 실행할 수 없으므로 자바로 작성돼 있는 Zygote 클래스가 동작하려면 달빅 가상 머신이 생성돼야 하고, 생성된 가상 머신 위에서 ZygoteInit 클래스를 로딩하고 실행해야 한다.
  
  
  - AppRuntime 객체 생성 및 실행
  - 달빅 가상 머신의 생성
  - ZygoteInit 클래스의 실행
  
  

• ZygoteInit 클래스의 기능
  
  - dev/socket/zygote 소켓 바인딩
  - 애플리케이션 프레임워크에 속한 클래스와 플랫폼 자원의 로딩
  - SystemServer 실행
    : zygote에서 달빅 가상 머신 구동 -> 시스템 서버라는 자바 서비스를 실행하기 위해 새로운 달빅 가상 머신 인스턴스 생성
    : Audio Flinger, Surface Flinger 네이티브 서비스 실행, 필요한 서비스를 실행되고 나면 안드로이드 프레임워크의 서비스를 시작
  

  - 새로운 안드로이드 애플리케이션 실행
  

  
  

• JNI? Java Native Interface로 안드로이드 프레임워크에서 C/C++과 자바 레이어가 유기적으로 동작하게 만들려면 자바 레이어(상위)와 C/C++ 레이어(하위)를 상호 연결해 주는 매개체가 필요하다. 그림 4-1의 좌측과 같이 자바와 C/C++ 모듈 간의 인터페이스를 가능하게 해주는 것이 바로 JNI(Java Native Interface)이다.
  
  
  
  
  
  
  : JNI는 일반적으로 다음과 같은 경우에 주로 활용한다.
  : 안드로이드 SDK를 토대로 만든 안드로이드 애플리케이션은 달빅 가상 머신(Dalvik Virtual Machine) 위에서 동작하는 자바 기반의 프로그램이다. 때문에 C/C++로 생성한 애플리케이션에 비해 느린 실행 속도 등 자바가 지닌 여러 한계를 그대로 가지고 있다. 가령, 그래픽픽 처리나 시그널 프로세싱처럼 CPU의 처리 속도가 중요한 부분에서는 자바보다 C/C++ 같은 네이티브 코드로 작성한 모듈이 훨씬 더 나은 성능을 낼 것이다.
  : SDK(Software Development Kit), NDK(Native Development Kit)
  
  - 빠른 처리 속도를 요구하는 루틴 작성
   : 대개 자바는 네티이브 코드(C/C++등)에 비해 느리다. 따라서 빠른 처리 속도를 요하는 부분은 C/C++로 작성하고 이를 JNI를 통해 자바에서 호출하는 방법으로 속도 향상을 꾀할 수 있다.
  
  - 하드웨어 제어
   : 하드웨어 제어 코드를 C로 작성한 다음 JNI를 통해 자바 레이어와 연결하면 자바에서도 하드웨어 제어가 가능하다.
  
  - 기존 C/C++ 프로그램의 재사용
   : 이미 기존 코드가 대부분 C/C++로 작성돼 있다면 굳이 자바로 동일한 코드를 다시 작성하기보다는 JNI를 통해 기존 코드를 활용할 수 있다.
  
  

• 자바에서 C 라이브러리 함수 호출
  ① 자바 코드 작성
   : 자바 클래스에 네이티브 메서드 선언
   : System.loadLibrary() 메서드를 호출해서 C 라이브러리 로딩
   
  
  ② 자바 코드 컴파일
  ③ C 헤더 파일 생성
   : 자바 가상 머신에서 함수 매핑 테이블이 필요
   : javah라는 툴을 이용하여 자바 네이티브 메서드와 연결될 수 있는 C 함수의 원형 생성(JNI 네이티브 함수 원형이 포함된 헤더 파일을 생성)
   

    
  
  ④ C 코드 작성
   : JNI 네이티브 함수 구현
  ⑤ C 공유 라이브러리 생성
   : C 공유 라이브러리 빌드
  ⑥ 자바 프로그램 실행
   : JNI를 통한 네이티브 함수 호출
     
  
  
  

• C 프로그램에서 자바 클래스 실행하기
  : C/C++에서 Java의 클래스를 이용하기 위해서는 Reflection 기술을 이용해야 한다.
  ① 자바 가상 머신에 전달할 옵션값을 생성
  ② 자바 가상 머신 생성
  ③ 실행할 클래스 검색 후 로드
  ④ 해당 메서드 ID 획득
  ⑤ 클래스 메서드의 인자로 넘겨줄 객체 생성
  ⑥ 메서드 호출
  ⑦ 자바 가상 머신 소멸
  
  
  

• 안드로이드 NDK
  : Native Development Kit로 JNI를 활용한 작업을 쉽게 할 수 있도록 구글에서 제공하는 개발 도구
  

  : C/C++ 소스를 네이티브 라이브러리로 빌드하기 위한 도구(컴파일러, 링커 등)
  : 빌드된 네이티브 라이브러리를 안드로이드 패키지 파일(.apk)에 삽입
  : 네이티브 라이브러리 작성 시 안드로이드 플랫폼에서 지원 가능한 시스템 헤더 파일 및 라이브러리
  : NDK 개발 관련 문서, 예제, 튜토리얼
  : 안드로이드에서 동작하는 네이티브 라이브러리는 리눅스용 공유 라이브러리(*.so)로 만들어야 한다. 대다수의 개발자가 윈도 환경에서 안드로이드를 개발하고 있으므로 윈도 환경에서 리눅스 기반의 라이브러리를 빌드하기 위해 Cygwin 필요

- 리눅스와 마찬가지로 안드로이드에서는 커널 부팅이 완료되면 최초의 사용자 프로세스인 init 프로세스를 실행 한다.

 리눅스의 프로세스들은 서로 정보를 교환하기 위해 메시지를 주고 받는데, 이러한 메시지를 시그널이라고 한다. 그리고 각 프로세스는 다른 프로세스에서 발생하는 시그널을 처리하기 위한 루틴을 등록하는데 이를 시그널 핸들러라고 한다. 시그널에는 프로세스의 실행 상태가 변경되거나 종료됐을때 발생하는 시그널이 있으며, 모든 프로세스의 부모인 init 프로세스는 자신이 생성한 프로세스가 종료됐을 때 발생하는 SIGCHLD 시그널을 처리할 핸들러를 등록한다. 시그널에 대한 실제 처리는 init 프로세스 동작 과정의 마지막 단계인 이벤트 처리 루프에서 수행된다.

- 안드로이드 init 프로세스는 다음과 같이 크게 4가지 기능을 수행한다.

① init.rc 파일 분석 및 실행
 : init 프로세스가 해야 할 일을 기술한 init.rc 파일을 분석해서 해당 파일에 담긴 내용에 따른 기능을 수행 한다. 



Figure 1. Android root file system

 - 액션 리스트
  : 'on init' 섹션에서는 환경변수를 등록하고, 시스템 동작 시 필요한 파일 및 디렉터리 생성하고 퍼미션을 조작, 시스템 동작과 관련된 디렉터리 /system, /data를 마운트
  : 'on boot' 섹션에서는 애플리케이션 종료 조건 설정, 애플리케이션 구동에 필요한 디렉터리 및 파일 퍼미션 설정 등
 - 서비스 리스트
  : init.rc 파일에서 'service' 섹션은 init 프로세스가 실행시키는 프로세스를 기술
 - init.rc 파싱 코드 분석
 - 액션리스트 및 서비스 리스트의 실행

• 안드로이드 커널(참고 - http://elinux.org/Android_Kernel_Features#Resources,수원 멤버십 자료)
  - Linux kernel 2.6 기반, but not Linux
     : 표준 리눅스 유틸리티를 전부 포함(x) -> busybox
     : glibc 지원 (x) -> bionic lib
     : Native Windowing System (X-Window) (x)
     : EABI 사용 -> 컴파일 시 EABI를 지원하는 컴파일러 사용
     : OpenBinder -> No SysV IPC
  
  - ashmem(Android(Anonymous) shared memory)/pmem(Process memory allocator) - 프로세스간 메모리 공유
   : ashmem은 가상 메모리 사용, pmem은 인접한 물리 메모리 사용
   : ashmem은 두 개의 프로세스가 메모리를 참조하다가 사용이 끝나면 그 메모리를 참조하던 모든 fd들은 close하게 됨, pmem은 직접 메모리를 해제해 주어야 함
   : 에뮬레이터에서는 ashmem을 사용해야 함, pmem은 드라이버 지원 x
  
  - Binder - RPC(an Android-specific interprocess communication mechanism, and remote procedure call system similar to DBus)
  - Power Managerment
  - Low Memory Killer
  - Logger(system logging facility)
  
   
  
  

• 안드로이드 플랫폼 소스 구조
  
  Figure 1. Android stack
  
  
  bionic: 안드로이드 표준 라이브러리
  bootloader: 참고용 안드로이드 부트 로더
  build: 안드로이드 빌드 시스템
  cts: 안드로이드 호환성 테스트 프로그램
  dalvik: 달빅 가상 머신
  development: 개발 관련 지원 소스
  external: 공개용 라이브러리
  frameworks: 안드로이드 프레임워크
  hardware: 안드로이드 HAL(Hardware Abstraction Layer) 소스
  out: 빌드 후 모음
  packages: 안드로이드 기본 애플리케이션
  prebuilt: 컴파일러
  system: 안드로이드 코어 프로그램, init 프로세스

• 안드로이드 부팅 과정 (출처 - 인사이드 안드로이드)
  

  
  - 부팅 순서 참고: http://blog.secmem.org/88
  
  (1) 리눅스 커널
  안드로이드는 리눅스 기반의 플랫폼. 부팅 시 부트로더를 통해 리눅스 커널이 먼저 시작, 리눅스가 부팅되면 일반적인 리눅스 부팅과정 처럼 커널 초기화를 수행한 후 마지막 과정에서 init 프로세스를 호출한다.

  (2) init
  안드로이드 init 프로세스는 각종 디바이스를 초기화하는 작업을 비롯해서 안드로이드 프레임워크 동작에 필요한 각종 데몬, 컨텍스트 매니저 (Context Manager), 미디어 서버(Meia Server), Zygote등을 실행하는 역할을 한다.
   다음은 init 프로세스가 실행하는 데몬 프로세스다.
   - USB 데몬(usbd): USB 연결 관리
   - 안드로이드 디버그 브리지 데몬(adbd): 안드로이드 디버그 브리지(ADB) 연결 관리
   - 디버거 데몬(debuggerd): 디버그 시스템 시작
   - 무선 인터페이스 레이어 데몬(rild): 무선 통신 연결 관리

  
  (3) 컨텍스트 매니저
  컨텍스트 매니저(Context Manager)는 안드로이드의 시스템 서비스를 관리하는 중요한 프로세스다. 시스템 서비스는 안드로이드 프레임워크를 구성하는 중요한 컴포넌트로서 카메라, 오디오, 비디오 처리에서부터 각종 애플리케이션 제작에 필요한 중요 API를 제공하는 등의 역할을 수행한다.
  
   안드로이드 내에서 동작하는 각종 시스템 서비스에 대한 정보는 컨텍스트 매니저에게서 얻을 수 있다. 따라서 시스템 서비스를 이용하고자 하는 애플리케이션이나 프레임워크의 내부 모듈은 이를 서비스 매니저에게 요청해야 한다. 요청 후에는 바인더(Binder)라는 안드로이드의 자체적인 IPC(Inter-process communication) 메커니즘을 통해 시스템 서비스를 이용할 수 있다.
  
  이를 위해서는 안드로이드의 모든 시스템 서비스는 부팅시 자신의 핸들 정보를 컨텍스트 매니저에 등록해야 하며, 이러한 서비스 등록 과정에서도 프로세스 간 통신을 수행하기 위해 바인더 IPC가 이용된다.
  
  (4) 미디어 서버
  미디어 서버(Media Server) 프로세스는 안드로이드에서 Audio Flinger(오디오 출력을 담당)나 Camera 서비스와 같이 C/C++ 기반으로 작성돼 있는 네이티브 시스템 서비스를 실행하는 역할을 한다.
  
  (5) Zygote
  Zygote는 안드로이드 애플리케이션의 로딩 시간을 단축하기 위한 프로세스로서 모든 자바 기반 안드로이드 애플리케이션은 Zygote를 통해 포크(fork)된 프로세스 상에서 동작한다.
  
  (6) 시스템 서버
  시스템 서버(System Server)는 Zygote에서 최초로 포크되어 실행되는 안드로이드 애플리케이션 프로세스다. 시스템 서버는 애플리케이션 생명 주기를 제어하는 액티비티 매지저 서비스(Activity Manager Service)나 단말기의 위치 정보를 제공하는 로케이션 매니저 서비스(Location Manager Service)와 같은 자바 시스템 서비스를 실행하는 역할을 한다.
  
   이처럼 시스템 서버에서 실행하는 자바 시스템 서비스도 안드로이드 애플리케이션이나 프레임워크 내부 모듈에서 이용할 수 있게 하기 위해서는 컨택스트 매니저에 등록돼 있어야 한다.
  
   그런데 바인더 IPC를 통해 자바 시스템 서비스를 C언어 기반의 서비스 매니저에 등록하려면 자바와 C언어 간의 인터페이스 역할을 하는 JNI(Java Native Interface)를 추가로 이용해야 한다.
  
  

• Runtime Walkthrough
  

  
  
  
  
  

1. Widget: 직접적으로 보이며 사용자 인터페이스를 구성한다. 버튼, 텍스트 뷰, 에디트, 라이오 버튼 등이 위젯이며 흔히 컨트롤이라고 부른다.

View도 자바 클래스의 일종이므로 당연히 최상위 Object로 부터 파생된다. 
이들은 스스로 그릴 수 있는 능력을 가지고 있고, 굵은 상자의 것들이 빈번히 사용되어 지는 것들이다.

2. ViewGroup : 직접적으로 보이지는 않으며 다른 뷰를 담는 컨테이너 역할을 한다. 이름 그대로 여러 개의 뷰를 유기적으로 모아놓은 것이다. 이 부류의 클래스들을 레이아웃이라고 한다.

"안드로이드 화면은 오직 뷰만으로 구성되어 있다."

출처 - http://www.soen.kr/book/android/book/book2/3-1-1.htm, 이것이 안드로이드다

안드로이드 4대 컴포넌트(component) (출처 -http://ggodol.tistory.com/52)

안드로이드 애플리케이션은 컴포넌트(component)로 구성되어있다. 안드로이드의 4대 컴포넌트는 액티비티(activity), 서비스(service), 방송수신자(broadcast receiver), 콘텐트 제공자(content provider)이다. 각 컴포넌트들은 하나의 독립된 형태로 존재하며, 정해진 역할을 수행한다. 이때, 인텐트를 통하여 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있다.
AndroidManifest.xml의 application 요소 내에 여러개를 등록할 수 있다.

1. 액티비티(activity)

액티비티(activity)는 사용자 인터페이스 화면을 가지며 특정한 작업을 담당하는 컴포넌트이다.

• 일반적으로 UI를 갖는 하나의 스크린을 나타낸다
• 안드로이드 애플리케이션은 반드시 하나의 activity를 가지고 있어야한다
• 각 액티비티는 매니페스트 파일에 등록되어 있어야 한다
• 하나 이상의 View를 가질 수 있다

2. 서비스(service)

서비스(service)는 백그라운드에서 실행되는 컴포넌트로 오랫동안 실행되는 작업이나 원격 프로세스를 위한 작업을 할 때 사용된다.

• UI가 없다
• 한번 시작된 Service는 애플리케이션이 종료되고 다른 애플리케이션으로 이동해도 계속 백그라운드에서 실행된다
• 모든 서비스는 Service 클래스를 상속받아서 작성된다
• 네트워크를 통하여 데이터를 꺼내올 수도 있다

3. 방송수신자(broadcast receiver)

방송수신자(broadcast receiver)는 안드로이드 단말기에서 발생하는 다양한 이벤트/정보를 받고 반응하는 컴포넌트이다. 예를들면 시스템부팅, 배터리 부족, 전화/문자 수신, 네트워크 끊김을 알려주는 것이 방송이다.

• 단말기에서 발생하는 일 중에서 어플리케이션이 알아야 하는 상황이 발생하면 방송을 해준다
• 수신기(BroadcastReceiver)를 통해 상황을 감지하고 적절한 작업을 수행한다
• 일반적으로 UI가 없다

4. 콘텐트 제공자(content provider)

콘텐트 제공자(content provider)는 데이터를 관리하고 다른 애플리케이션 데이터를 제공하는 컴포넌트이다.

• 데이터는 파일 시스템이나 SQLite 데이터베이스, 웹상에 저장될 수 있다
• 콘텐트 제공자를 통해서 다른 애플리케이션의 데이터를 쿼리하거나 변경 가능하다

5. 인텐트(intent)

인텐트는 서로 독립적으로 동작하는 4가지 컴포넌트들 간의 상호 통신을 위한 장치이다. 간단하게 말하면, 컴포넌트 간의 통신수단이다. 인텐트를 통하여 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있다.

참고

• 그림으로 쉽게 설명하는 안드로이드 프로그래밍(생능출판, 천인국 지음)