안드로이드 프레임워크

Lee Jun Hyeong·2022년 12월 22일

android 프레임워크

Android 톺아보기 😇

목록 보기

3/17

📌 애플리케이션

안드로이드에서 제공하는 선탑재 기본 앱(홈, 카메라, 전화, 브라우저 등)과 다운로드해서 설치하는 일반 앱은 애플리케이션 스택에 있다. 애플리케이션은 애플리케이션 프레임워크 스택 위에서 동작한다.
선탑재된 기본 앱은 시스템 권한을 사용할 수 있고, 프로세스 우선순위를 높일 수 있는 차이가 있다.

메모리가 부족하더라도 전화 앱이 중지되면 안되기 때문에 전화 앱은 우선순위가 높다.

📌 애플리케이션 프레임워크

앱에서 액티비티를 시작할 때 생성자로 직접 액티비티 인스턴스를 생성하고 생명주기 메서드를 호출하진 않는다. 또 환경 설정에서 언어가 변경될 때 앱에서 해당 언어의 리소스를 직접 찾아서 가져오지 않는다.
이렇게 필요한 여러 동작을 직접하지 않아도 되는 것은 애플리케이션 프레임워크에서 알아서 하기 때문이다.
아키텍처 다이아그램을 보면 여러 Managers가 있는 걸을 확인할 수 있다. 이 Managers가 애플리케이션 프레임워크의 역할을 한다.

Activity Manager는 액티비티를 생성해서 생명주기 메서드를 호출하는 역할을 하고, Resource Manager는 리소스를 찾아주는 역할을 한다.

📌 네이티브 C/C++ 코드 사용

여러 Manager는 대부분 자바로 작성되어 있다.
그 중 하드웨어 제어나 빠른 속도가 필요한 것들은 내부적으로 JNI를 연결해서 네이티브 C/C++ 코드를 사용하기도 한다.

JNI(Java Native Interface)

자바 가상머신(JVM)위에서 실행되고 있는 자바코드가 네이티브 응용 프로그램(하드웨어와 운영 체제 플랫폼에 종속된 프로그램들) 그리고 C, C++ 그리고 어셈블리 같은 다른 언어들로 작성된 라이브러리들을 호출하거나 반대로 호출되는 것을 가능하게 하는 프로그래밍 프레임워크 이다.

사용 이유

일부 하드웨어를 처리해야 하는 필요성
매우 까다로운 프로세스의 성능 향상
Java로 다시 작성하는 대신 재사용하려는 기존 라이브러리

Telephon 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의 getSystemServic(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에 속한 것이다.

참고
- https://velog.io/@woga1999/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC
- https://velog.io/@vrooming13/JNI-JAVA-Native-Interface