포럼 회원으로 등록하신분만 다운로드가 가능합니다. 최대 업로드 가능한 용량은 20MB 입니다.
글 수 84
고도리입니다.
밑에 올린 글에 이어서 다시 설명하겠습니다.
책에서도 설명된 글이긴 하지만, 여기서는 책 내용과 상관없이 개념위주로 설명드리겠습니다.
=========================================================================
0. Binder == IPC???
바인더는 "안드로이드 IPC 메카니즘"으로 불립니다.
IPC라는 것은 대부분 아시다시피 "Inter-Process Communication"의 약자입니다.
즉, 프로세스간 통신이란 개념입니다.
그럼 왜 이런 일을 해야하는가??
일단 다음의 그림을 참고하면 대략의 이해는 하실 수 있을겁니다.
user space에서의 process는 완전히 독립적입니다. 즉, 1G 영역(커널)은 공유를 하고, 3G 영역은 특정시간에서는 고정적으로 하나의 process에서 사용할 수 있도록 커널은 스케쥴링을 하고 있습니다.
커널의 입장은 자기는 가만히 있고, 3G영역의 process들만 교체해서 동작시키는 것으로 볼 수 있고process의 입장은 자기는 항상 4G(3G+1G)를 전체 쓴다고만 생각을 합니다.
그런데 문제는 사용자 측면입니다. 하나의 process에서 모든 일을 처리하기는 너무 힘들다는 것입니다.
그래서 생겨난 개념이 여러개의 프로세스를 이용해서 하나의 일을 처리하기 위한 방법으로 커널은 항상 공유되니 커널을 이용하자.....해서 탄생된 IPC 메카니즘입니다.
IPC는 유닉스 히스토리상 2가지가 있습니다.
- BSD에서 탄생된 Unix Domain Socket: 안드로이드에서도 많이 쓰입니다...^^- System V IPC: message Q, semaphore, shared memory
위의 두 메카니즘은 한가지 문제가 있는데, 시스템 전체 레벨에서 관리감독 하는게 아니라 그냥 프로세스간만의 약속입니다.
안드로이드 binder는 이런 부분을 시스템 레벨에서 관리하거나 다루기 위하여 약간의 확장개념을 도입한 것이라고 볼 수 있습니다. 개념은 System V IPC와 동일하다라고 생각이 됩니다.==> 물론 많은 부분에서의 확장이 이루어졌고, 재 정립되었다고 보는 편이 맞을 듯 합니다.
1. Binder의 IPC 개념
안드로이드 바인더에서의 IPC의 개념도는 다음과 같습니다.
그림에도 설명이 있지만, client에서 어떤 함수를 호출한 후, message 'T'란 값을 서버쪽으로 보내서 서버에서 적절한 동작을 할 수 있도록 하는 것입니다.
별거 없죠???? ^^
2. Binder의 RPC 개념
RPC란 것은 Remote Procedure Call의 약자입니다. 간단하게 원격 호출 개념이라고 보시면 되는데,
설명은 여기를 참고하시면 됩니다.
http://terms.co.kr/RPC.htm
이 부분은 원격(네트워크 상에서)에 있는 함수등을 직접 호출한다는 개념이 강합니다.
Binder는 이런 부분을 process간 통신방법에 적용을 했습니다. 해서 안드로이드 binder RPC 개념은"다른 프로세스에 있는 함수를 직접 호출하기"가 되는 것입니다.
일단 그림을 보시면 알 수 있을겁니다.
위 그림에서 볼 수 있듯이 client쪽 프로세스에서 AA란 함수(함수의 선언된 형태를 잘 보시고요)를 호출하면 IPC 통신을 이용해서 서버에 있는 AA란 함수를 호출하도록 해 놓았습니다.
client 입장에서만 본다면 서버에 있는 함수를 호출한게 아니라, 자기 자신한테 있는 AA란 함수의 호출과 동일하다라고 볼 수 있습니다.
이런 개념을 그림으로 그려보면 다음과 같습니다.
3. RPC의 구현
binder를 이해하는데의 문제는 RPC 구현이 여간 까다롭지 않게 되어 있다는 데 있습니다.
일단 클래스 구조가 너무 복잡하게 얽혀있고, 봐야하는 파일의 갯수가 기본적으로 6개 이상입니다.해서 나름 많이 복잡한데, 일단 AudioTrack이라는 클래스를 이용해서 AudioFlinger라는 Binder 서버에접속하기 위한 클래스 구조도를 그리면 다음과 같습니다.
여기서 관심있게 봐야할 부분은 클래스 상속도 입니다.
1> 함수 template함수 template이 필요한 이유는 RPC이기 때문에 client와 server에 동일한 함수의 형태가 존재해야 하기 때문입니다.
2> Binder client의 기능당연히 IPC를 이용하기 때문에 메세지를 전달할 수 있는 기능이 있어야 하며
3> Binder server의 기능메시지를 전달받아서 실제 기능을 하기 위한 기능도 있어야 합니다.
Bp 라는 prefix가 붙은 클래스는 "Binder proxy"의 약자로 볼 수 있으며 Binder client의 역할을 합니다.Bn 이라는 prefix는 "Binder native"의 약자로 볼 수 있으며 Binder server의 역할을 하는 클래스입니다.
※ 이 부분에 대한 자세한 설명은 책을 가지고 있으신 부분은 해당 부분을 같이 보시면 될겁니다.
일단 소스를 설명해야 하니, 이 부분은 좀 뒤로 미루도록 하겠습니다. 저도 책의 소스를 좀 봐야해서요....^^
4. Android 분석을 위해서 반드시 Binder를 알아야 하는 경우
Binder를 몰라도 SDK를 가지고 안드로이드를 이용하는데에는 큰 문제가 없습니다.어쩌면 porting에서도 큰 상관이 없을 수도 있습니다(잘 맞춰서 작성만 한다면)
하지만, 개발을 하다보면 여러가지 일들이 많이 생기는데, 제일 갑갑한 부분은 하라는 대로 했는데제대로 동작하지 않거나 프로세스가 죽어버리는 경우일겁니다.
Binder의 동작을 반드시 알아야 하는데는 이유가 있는데(제가 많이 겪었거든요.......ㅠ.ㅠ)
다음의 그림을 보면서 간단히 설명하겠습니다.
개인적으로 바인더를 공부해야 하는 이유는 위와 같은 그림에 있다라고 생각을 합니다.
위의 그림은 MP3 media player를 가지고 바인더를 이용해서 하드웨어까지 개발을 하는 그림입니다.보통 SDK engineer 분들께는 Applications framework의 MediaPlayer class 정도까지 보일겁니다.
물론, 디버깅도 Eclipse를 이용한 JAVA layer까지 진행이 될테고요.
함수가 호출이 되면 실제 디바이스에서는 (3) ~ (8)번까지의 함수 경로를 통해야만 소리가 나오거나 사운드 관련 제어가 이루어집니다.
그런데, 모든 부분을 다 제대로 포팅했다고 생각했는데 갑자기 오동작을 하거나 소리가 안나는 경우가 발생할 수 있습니다. 그러면, 어디를 먼저 봐야할까요????
저는 주로, (3), (8)을 먼저 봅니다. 여기서 잡을 수 있으면 행운입니다.
안잡히면 어디를 봐야할까요???????
그 때는 어쩔 수 없이 (6), (7)번 부분을 봐야합니다. 하지만, (6)번 부분을 보기 위해서는 반드시 동작을 시키면서 봐야합니다. 즉, binder가 동작되는 구조를 파악하지 않으면 (6) 부분을 자세하게 보기가 힘듭니다.
안드로이드가 디버깅이 힘든 이유는 여기에 있습니다.
내가 생각지 않는데서 문제가 터졌을 때 이 부분을 보기 위해서는 반드시 Binder의 구조를 알고 봐야합니다.(전적으로 개인적인 개x철학에서 나온 말입니다....^^)
그럼.....오늘은 이만 정리하도록 하겠습니다.
ps> ※ 이 글과 그림은 그냥 베끼셔서 아무데나 활용하셔도 됩니다.
user space에서의 process는 완전히 독립적입니다. 즉, 1G 영역(커널)은 공유를 하고, 3G 영역은 특정시간에서는 고정적으로 하나의 process에서 사용할 수 있도록 커널은 스케쥴링을 하고 있습니다.
커널의 입장은 자기는 가만히 있고, 3G영역의 process들만 교체해서 동작시키는 것으로 볼 수 있고process의 입장은 자기는 항상 4G(3G+1G)를 전체 쓴다고만 생각을 합니다.
그런데 문제는 사용자 측면입니다. 하나의 process에서 모든 일을 처리하기는 너무 힘들다는 것입니다.
그래서 생겨난 개념이 여러개의 프로세스를 이용해서 하나의 일을 처리하기 위한 방법으로 커널은 항상 공유되니 커널을 이용하자.....해서 탄생된 IPC 메카니즘입니다.
IPC는 유닉스 히스토리상 2가지가 있습니다.
- BSD에서 탄생된 Unix Domain Socket: 안드로이드에서도 많이 쓰입니다...^^- System V IPC: message Q, semaphore, shared memory
위의 두 메카니즘은 한가지 문제가 있는데, 시스템 전체 레벨에서 관리감독 하는게 아니라 그냥 프로세스간만의 약속입니다.
안드로이드 binder는 이런 부분을 시스템 레벨에서 관리하거나 다루기 위하여 약간의 확장개념을 도입한 것이라고 볼 수 있습니다. 개념은 System V IPC와 동일하다라고 생각이 됩니다.==> 물론 많은 부분에서의 확장이 이루어졌고, 재 정립되었다고 보는 편이 맞을 듯 합니다.
1. Binder의 IPC 개념
안드로이드 바인더에서의 IPC의 개념도는 다음과 같습니다.
그림에도 설명이 있지만, client에서 어떤 함수를 호출한 후, message 'T'란 값을 서버쪽으로 보내서 서버에서 적절한 동작을 할 수 있도록 하는 것입니다.
별거 없죠???? ^^
2. Binder의 RPC 개념
RPC란 것은 Remote Procedure Call의 약자입니다. 간단하게 원격 호출 개념이라고 보시면 되는데,
설명은 여기를 참고하시면 됩니다.
http://terms.co.kr/RPC.htm
이 부분은 원격(네트워크 상에서)에 있는 함수등을 직접 호출한다는 개념이 강합니다.
Binder는 이런 부분을 process간 통신방법에 적용을 했습니다. 해서 안드로이드 binder RPC 개념은"다른 프로세스에 있는 함수를 직접 호출하기"가 되는 것입니다.
일단 그림을 보시면 알 수 있을겁니다.
위 그림에서 볼 수 있듯이 client쪽 프로세스에서 AA란 함수(함수의 선언된 형태를 잘 보시고요)를 호출하면 IPC 통신을 이용해서 서버에 있는 AA란 함수를 호출하도록 해 놓았습니다.
client 입장에서만 본다면 서버에 있는 함수를 호출한게 아니라, 자기 자신한테 있는 AA란 함수의 호출과 동일하다라고 볼 수 있습니다.
이런 개념을 그림으로 그려보면 다음과 같습니다.
3. RPC의 구현
binder를 이해하는데의 문제는 RPC 구현이 여간 까다롭지 않게 되어 있다는 데 있습니다.
일단 클래스 구조가 너무 복잡하게 얽혀있고, 봐야하는 파일의 갯수가 기본적으로 6개 이상입니다.해서 나름 많이 복잡한데, 일단 AudioTrack이라는 클래스를 이용해서 AudioFlinger라는 Binder 서버에접속하기 위한 클래스 구조도를 그리면 다음과 같습니다.
여기서 관심있게 봐야할 부분은 클래스 상속도 입니다.
1> 함수 template함수 template이 필요한 이유는 RPC이기 때문에 client와 server에 동일한 함수의 형태가 존재해야 하기 때문입니다.
2> Binder client의 기능당연히 IPC를 이용하기 때문에 메세지를 전달할 수 있는 기능이 있어야 하며
3> Binder server의 기능메시지를 전달받아서 실제 기능을 하기 위한 기능도 있어야 합니다.
Bp 라는 prefix가 붙은 클래스는 "Binder proxy"의 약자로 볼 수 있으며 Binder client의 역할을 합니다.Bn 이라는 prefix는 "Binder native"의 약자로 볼 수 있으며 Binder server의 역할을 하는 클래스입니다.
※ 이 부분에 대한 자세한 설명은 책을 가지고 있으신 부분은 해당 부분을 같이 보시면 될겁니다.
일단 소스를 설명해야 하니, 이 부분은 좀 뒤로 미루도록 하겠습니다. 저도 책의 소스를 좀 봐야해서요....^^
4. Android 분석을 위해서 반드시 Binder를 알아야 하는 경우
Binder를 몰라도 SDK를 가지고 안드로이드를 이용하는데에는 큰 문제가 없습니다.어쩌면 porting에서도 큰 상관이 없을 수도 있습니다(잘 맞춰서 작성만 한다면)
하지만, 개발을 하다보면 여러가지 일들이 많이 생기는데, 제일 갑갑한 부분은 하라는 대로 했는데제대로 동작하지 않거나 프로세스가 죽어버리는 경우일겁니다.
Binder의 동작을 반드시 알아야 하는데는 이유가 있는데(제가 많이 겪었거든요.......ㅠ.ㅠ)
다음의 그림을 보면서 간단히 설명하겠습니다.
개인적으로 바인더를 공부해야 하는 이유는 위와 같은 그림에 있다라고 생각을 합니다.
위의 그림은 MP3 media player를 가지고 바인더를 이용해서 하드웨어까지 개발을 하는 그림입니다.보통 SDK engineer 분들께는 Applications framework의 MediaPlayer class 정도까지 보일겁니다.
물론, 디버깅도 Eclipse를 이용한 JAVA layer까지 진행이 될테고요.
함수가 호출이 되면 실제 디바이스에서는 (3) ~ (8)번까지의 함수 경로를 통해야만 소리가 나오거나 사운드 관련 제어가 이루어집니다.
그런데, 모든 부분을 다 제대로 포팅했다고 생각했는데 갑자기 오동작을 하거나 소리가 안나는 경우가 발생할 수 있습니다. 그러면, 어디를 먼저 봐야할까요????
저는 주로, (3), (8)을 먼저 봅니다. 여기서 잡을 수 있으면 행운입니다.
안잡히면 어디를 봐야할까요???????
그 때는 어쩔 수 없이 (6), (7)번 부분을 봐야합니다. 하지만, (6)번 부분을 보기 위해서는 반드시 동작을 시키면서 봐야합니다. 즉, binder가 동작되는 구조를 파악하지 않으면 (6) 부분을 자세하게 보기가 힘듭니다.
안드로이드가 디버깅이 힘든 이유는 여기에 있습니다.
내가 생각지 않는데서 문제가 터졌을 때 이 부분을 보기 위해서는 반드시 Binder의 구조를 알고 봐야합니다.(전적으로 개인적인 개x철학에서 나온 말입니다....^^)
그럼.....오늘은 이만 정리하도록 하겠습니다.
ps> ※ 이 글과 그림은 그냥 베끼셔서 아무데나 활용하셔도 됩니다.
"사람은 자기가 보고 싶은 현실만 볼 뿐이다." - Gaius Julius Caesar
