인사이드 안드로이드 07 바인더 IPC (2)

7.3 안드로이드 바인더 드라이버 분석

바인더 드라이버를 통한 RPC 과정보다는 바인더 드라이버의 실제 역할인 IPC 과정에 초점.

서비스 클라이언트가 서비스 서버의 서비스를 사용하기까지의 IPC과정을 각각 '서비스 등록', '서비스 검색', '서비스 사용' 3단계로 나누고,이를 서비스 사용 과정이라고 하겠음

 

7.3.1 프로세스 관점에서의 서비스 사용

1. 서비스 등록(서비스 서버와 컨텍스트 매니저 사이의 아피씨)

2. 서비스 검색(서비스 클라이언트와 컨테스트 매니저 사이의 아피씨)

3. 서비스 사용(서비스 클라이언트와 서비스 서버 사이의 아피씨)

 

1. 바인더 드라이버 열기

2. IPC 데이터 수신 퍼버

3. 아피씨 데이터 수신을 위한 대기 상태 진입

4. 바인더 드라이버 열기

5. 아피씨 응답 데이터 수신 버퍼 확보

6. 아피씨 데이터 생성

7. 아피씨 데이터 전달 및 아피씨 응답 데이터 수신 대기 상태 진입

8. 아피씨 데이터 분석 후 서비스 등록 함수 호출, 서비스 등록단계는 addService() 함수

9. 서비스 목록에 서비스 등록

10. 등록 완료되었음을 알리기 위한 아피씨 응답 데이터 생성 및 전달

11. 아피씨 응답 데이터 처리

 

서비스 서버는 컨텍스트 매니저의 서비스 함수를 사용하는 서비스 클라이언트가 되고, 컨텍스트 매니저는 서비스 서버가 됨. 서비스 등록을 마친 서비스는 서비스 클라이언트가 사용할 수 있는 상태가 됨.

 

서비스 검색은 서비스 클라이언트가 서비스 서버의 서비스를 사용하기 위해 컨텍스트 매니저에게서 서비스의 번호를 요청하는 단계임. 서비스 검색 단계에서 두 프로세스가 하는 역할은 다음과 같음

 

서비스 사용은 서비스 클라이언트가 서비스 서버의 실제 서비스를 사용한다. 실제 코드 상에서 서비스 서버는 무엇이고 서비스 클라이언트는 무언인지.

 

7.3.2 바인더 드라이버 관점에서의 서비스 사용

서비스 서버의 서비스 등록 요청이나 서비스 클라이언트의 서비스 검색 요청을 처리하기 위한 대기 상태에 먼저 진입.

서비스 사용 : 서비스 검색 단계에서 바인더 드라이버는 서비스 등록 단계와 같은 형태로 동작하지만 IPC 데이터를 컨텍스트 매니저가 아닌 실제 서비스를 가진 서비스 서버에게 전달한다는 차이가 있음. 서비스 검색 단계를 거친 서비스 클라이언트는 서비스 서버가 가진 서비스의 바인더 노드 번호를 알고 있음. 따라서 서비스 클라이언트가 아피씨 데이터를 생성할 때 컨텍스트 매니저의 핸들에 해당하는 0 대신 실제 사용하고자 하는 서비스의 바인더 노드 번호를 핸들로 지정함

 

7.3.3 바인더 드라이버 함수 분석

현재 프로세스의 사용자 데이터 영역으로서 초기화된 변수가 저장돼 있는 공간이며 데이터의 읽기 쓰기가 가능한 영역임. binder_write_read 구조체의 write_buffer와 read_buffer에 담기는 IPC 데이터와 IPC응답 데이터는 어떠 형태를 지니고 있을까.

container_of() 함수 : 구조체 내의 멤버 변수 주소를 통해 소속된 구조체의 시작 주소를 찾아내는 함수.

 

7.5 정리

바인더는 안드로이드의 서비스를 보유한 서비스 서버, 서비스를 사용하고자 하는 서비스 클라이언트, 서비스 위치를 알려주는 컨텍스트 매니저, 그리고 이들 모두를 중재하는 바인더 드라이버로 구성됨. 각 기능들은 컴포넌트처럼 핵심 기능만을 갖춘 서비스로 세분화 됨. 그리고 이것들을 사용하는 프로세스들은 일관적인 신호 체계인 IPC 데이터를 통해 서비스들과 상호작용 함. 바인더는 안드로이드에 존재하는 수많은 서비스들을 이어주는 연결고리임. 그 중심에 바인더 드라이버가 존재함. 프레임워크나 앱 수준의 서비스 사용과정에서 바인더 드라이버의 복잡한 동작 방식은 감춰놓음. 다음 장에 살표보는 서비스 매니저와 서비스 프레임워크가 바인더 드라이버를 기반으로 서비스들을 연결해주는 추상 계층이 됨.