이 포스트는 <안드로이드 프로그래밍 Next Step> 챕터 1을 보고 작성한 글입니다.
이 포스트에서는 안드로이드 아키텍처에 대한 것들을 속속히 알아볼 것이다.
애플리케이션
안드로이드에서 제공하는 선탑재 기본 앱(홈, 카메라, 전화, 브라우저 등)과 다운로드해서 설치하는 일반 앱은 애플리케이션 스택에 있다. 애플리케이션은 애플리케이션 프레임워크 스택 위에서 동작한다.
다만, 여기서 선탑재된 기본 앱은 시스템 권한을 사용할 수 있고, 프로세스 우선순위를 높일 수 있다는게 다르다.
예를 들어 메모리가 아무리 부족해도 전화 앱이 중지되면 안 된다. 그래서 전화 앱은 우선 순위가 높다.
애플리케이션 프레임워크
애플리케이션 프레임워크란 무엇일까? 우린 이에 대한 정의를 아무리 봐도 와닿지 않을 것이다.
예를 들어보면, 앱에서 액티비티를 시작할 때 생성자로 직접 액티비티 인스턴스를 생성하고 생명주기 메서드를 호출하진 않는다.
또 환경 설정에서 언어가 변경될 때 앱에서 해당 언어의 리소스를 직접 찾아서 가져오지 않는다.
이렇게 필요한 여러 동작을 직접하지 않아도 되는 것은 애플리케이션 프레임워크에서 알아서 하기 때문이다!
위의 아키텍처 다이아그램을 보면 이미 여러 Managers가 있다는 걸 확인할 수 있다. 이들 Manager가 애플리케이션 프레임워크의 역할을 하고 있다.
Activity Manager는 액티비티를 생성해서 생명주기 메서드를 호출하는 역할을 하고 Resource Manager는 리소스를 찾아주는 역할을 한다.
(액티비티 인스턴스 생성하고 생명주기 메서드 호출, 해당 언어의 리소스를 찾아서 가져오기)
네이티브 C/C++ 코드 사용
여러 Manager는 대부분 자바로 작성되어 있다. 이 가운데서 하드웨어 제어나 빠른 속도가 필요한 것들은 내부적으로 JNI를 연결해서 네이티브 C/C++ 코드를 사용하기도 한다.
Telephony Manager,Location Manager 등은 하드웨어를 제어하기 위해서, Resource Manager 등은 리소스 테이블을 유지하고 접근할 때 빠른 속도를 내기 위해 네이티브 C/C++을 사용한다.
씬 클라이언트와 서버
Activity Manager는 왜 클래스명인 ActivityManager나 ActivityManagerService로 쓰지 않을까?
Activity Manager는 클라이언트인 ActivityManager와 서버인 ActivityManagerService를 모두 포괄하는 개념이다. 그 외 각족 Manager들도 마찬가지다.
서버 기능은 별도 프로세스인 system_server에서 실행된다. 앱 프로세스는 씬 클라리언트(thin client)이다. 앱 프로세스는 컴포넌트 탐색, 액티비티 스택 관리, 서비스 목록 유지, ANR 처리 등을 직접하지 않는다. 서버인 system_server 프로세스에 모두 위임하고 컴포넌트 실행 등 최소한의 역할만을 한다. system_server는 여러 앱을 통합해서 관리하는 통합 문의 채널이다.
액티비티를 포함한 모든 안드로이드 컴포넌트는 system_server를 거쳐서 관리되고 system_server에서 앱 프로세스에 다시 메시지를 보내는 방식으로 동작한다.
시스템 서비스 접근
여러 Manager 서버는 시스템 서비스 형태로 존재한다. 그리고 앱에서 접근할 때는 Context의 getSystemServcie(String name) 메서드를 사용한다. system_server라는 별도 프로세스에서 실행되므로 앱에서는 시스템 서비스에 접근할 때 Binder IPC를 이용한 프로세스 간 통신이 필요하다.
안드로이드 런타임
달빅 가상 머신은 자바/C/C++로 작성되어 있다. (롤리팝부터 달빅을 대체한 ART 적용)
레지스터 기반의 가상 머신으로 자바 가상 머신보다 명령이 단순하고 속도가 빠르다.
코어 라이브러리
코어 라이브러리는 안드로이드 프레임워크 소스에서 위치가 /system/core이다. 커널을 래핑하거나 추가 기능을 제공하는 역할을 한다.
라이브러리
여기서 라이브러리는 주로 네이티브 라이브러리를 이야기한다. 네이트 라이브러리에는 3가지 범주가 있다.
- Bionic (커스텀 C 라이브러리 - libc)
- Webkit/SQLite/OpenGL (같은 기능 라이브러리)
- Surface Manager, Media Framework (각각 /system/bin/surfacefliger와 /system/bin/mediaserver 프로세스로 실행)
리눅스 커널
참고로 안드로이드 커널은 리눅스 커널을 기반으로 불필요한 것들을 제거하고 기능을 확장 패치한 것이다.
Binder IPC
확장 패치한 기능 가운데 Binder IPC는 프로세스 간 통신에 사용된다. 또한, 안드로이드 컴포넌트 가운데 서비스와 콘텐트 프로바이더는 바인더를 통해서 다른 프로세스에 접근할 수 있다.
Binder Thread
앱 프로세스에는 Binder Thread라는 네이티브 스레드 풀이 있고, 최대 16개까지 스레드가 생성된다. 다른 프로세스에서 Binder IPC 통신을 할 때 이 스레드 풀을 통해서 접근한다. DDMS에서 보면 Binder_1, Binder_2와 같은 이름의 스레드가 바로 Binder Thread에 속한 것이다.
