Android Multimedia Programming 강의를 듣고

요즘 너무 정신이 없는 때여서, 정리까지는 못하였다. ㅡ.ㅡ

(core)App -> xxxManager -> (Binder) -> XXXManager service

(h/w) app -> xxManager -> (Binder) -> xxxService(JAVA) -> (JNI) --> XXXService(C++) --> HAL -->(System call) Device

android rpc는 binder driver를 사용한다. RPC Layer에서 remote()->transact()로 BindProxy를 사용하고 onTransact로 BindNative를 사용한다.

이러한 rpc원리를 기반으로 프로세스 1, 2가 통신할때 IServiceManger를 사용하는데 이 서비스를 사용하는 때 또한 rpc 즉, BP, BN이 사용된다.

즉, IServiceManager에서 서비스 등록(서버측), 검색(클라이언트측)을 할때 BP, BN을 사용하게 되고, 이후 프로세스 1, 2가 통신할 때 역시 RPC레이어에서 BP, BN을 사용한다.

MM의 원리는 read(), write()와 ashmem을 사용

read(), write()는 bind기반의 client/server방식

(bind 는 ahmem기반으로 process간 통신)

audio의 경우 audioFlinger사용. audioFlinger는 tracker와 ahsmem사용

API는 system call의 조합.

MM은 카메라, AUDIO, VIDEO로 구분

카메라는 시작, 프리뷰, TAKE A PICTURE 단계로 구분

오디오는 재생, 녹음

여러가지 ENCODING포멧이 있으나 최종 HAL단에서는 PCM으로 사용

AudioFlinger사용

ALSA사용

재생은 TRACK, SOUNDPOOL, 일반재생(?)

MediaPlayer -> StageFright -> AweSome Player -> a/v 분리 -> OMX -> 디코딩

-> AudioTrack-> ashmem사용(client,server방식으로 read/write)

소프트웨어공학: 복잡한것을 어떻게 다룰지에 대한 연구(이건 잠깐 갑자기 생각이 나서...)

video, camera는 UI와 다른 LAYER사용. ui는 ashmem사용하고 후자는 PM(Physical memory)사용

z-order

mm은 기존 open source에서 google에 직접 만드는 모양새로 감(license이슈등이 있고 무게도 가볍게 하기 위해서.)

glibc에서 bionic libc로(구매)에서 넣었다. 

(hal layer라고 할 수 있다. device에 접근하기 위해서는 이 hal layer를 사용)

bionic libc에는 system call 이 있다.

system call에는 

open()  

fd = open("/dev/graphics/fb0") -> framework buffer drv.에 접근

read()

User -> Kernel (data)

write()

User(data) -> Kernel

ioctl()

control <- ->

mmap()

memory map. (audio, graphic)

close()

device close

dalvic은 자주 쓰는 logic을 binary로 미리 컴파일 해놓음. JIT방식으로 함.

JAVA는 stack based이지만 DVM은 register based architecture.

(arm architecture 를 그래도 가져옴?)

kernel은 device관리, process간 통신, management(memory)

device는 char, block, network 으로 나누어진다. frame buffer는 char이다.(문자 string단위로), net은 BSD socket사용

block은 속도가 느린다. 때문에 buffer cache가 들어간다.

VFS, Select 모든 것은 file로 관리하고 select로 넘긴다.

## 참조 (OpenGL, MAX...)

http://www.khronos.org