안드로이드 구조
안드로이드 구조
1. Linux Kernel
안드로이드는 리눅스 기반의 운영체제로 쉘에서 사용하는 명령어와 기본적인 구조가 리눅스와 거의 유사하다.
단, 데스크톱에서 사용된 리눅스 시스템의 형태 기반이 아니기 때문에, 리눅스 데스크톱용 배포판 운영체제에서
안드로이드 앱을 실행할 수 없고, 리눅스 프로그램들 또한 안드로이드에서 사용할 수 없다.
안드로이드에 적용된 리눅스 커널은 안드로이드에 맞춰진 경량화된 커널이라고 볼 수 있다.
kernel의 기능
kernel은 하드웨어와 응용 프로그램 사이에서 인터페이스를 제공하여 응용 프로그램이 하드웨어에서부터 오는 자원을 관리하고
사용할 수 있도록 한다. 즉, 하드웨어와 운영체제를 연결시켜주는 다리와 같은 존재로 운영체제의 핵심이라고 볼 수 있다.
kernel의 주된 기능은 다음과 같다.
1. 보안
- 컴퓨터 하드웨어와 프로세스의 보안을 책임진다.
2. 자원관리
- 한정된 시스템 자원을 효율적으로 관리하여 프로그램의 실행을 원활하게 한다.
3. 추상화
- 비슷한 종류의 하드웨어에 공통된 명령어를 제공한다.
- 운영체제의 복잡한 내부를 감추고 일관성있는 인터페이스를 하드웨어에 제공하는 역할
2. H.W Abstraction Layer
커널의 추상화 기능처럼 운영체제의 복잡한 내부를 감추고 일관성 있는 인터페이스를 하드웨어에 제공하는 계층으로
같은 종류의 하드웨어에 대한 공통 명령어 집합으로 바인딩하는데 이를 하드웨어 추상화라고 한다.
안드로이드에서는 Java API framework에 하드웨어 디바이스 기능을 사용할 수 있도록 하는 표준 인터페이스를 제공한다.
Framework API가 하드웨어 디바이스에 접근 후, 호출을 수행하면, 시스템에서 해당 하드웨어 구성요소에 대해
Library module을 불러올 수 있다.
즉, framework 요청에 따라 해당 하드웨어의 Library module을 제공하는 계층이라고 볼 수 있다.
3. Android runtime + Libraries
Android runtime
안드로이드 런타임은 흔히 "ART" 라고 이야기하며, ART의 기능은 실행 중인 APP code들을 OS가 이해하도록 compiling 한다.
또한, process가 동작하면서 Library를 호출할 때 사용하는 것이 Android runtime이다.
현재, Android runtime의 complie 방식은 크게 두 가지로 나눌 수 있는데 이를 알기 위해서는 JAVA compile 방식인
JVM과 DVM에 대해 알아야 한다.
- JVM (stack based complie 기법)
JAVA Byte code를 실행하기 위한 VM으로 stack based 기반의 VM이다.
JAVA Byte code는 플랫폼에 맞춰 소스코드를 빌드할 필요가 없어 한 번의 빌드로 여러 플랫폼에서 실행가능하다.
즉, JVM만 동작되는 환경이라면 새로 complie 할 필요 없이 class 파일을 실행할 수 있는 장점을 갖고 있다.
- DVM (Registry based compile 기법)
안드로이드 App을 실행하기 위한 VM, Mobile device에 최적화된 VM으로 낮은 memory에서 실행되도록 설계되었다.JVM과 달리 Dex compiler 과정이 추가되었는데, 이는 안드로이드 mobile OS에 최적화된 compile 작업을 위해 만들어진 것으로Dex compiler가 class file을 Dex file로 변경하여 DVM에서 실행 가능하도록 생성한다. 따라서, 여러 개의 class file이 하나의 Dex file로 변경되어 최종적으로 Dex 확장자를 가지고 리소스를 포함한 기타 라이브러리 등이 압축되면 안드로이드에서 실행 가능한 application인 APK 파일이 완성된다.
초기 안드로이드는 DVM complie 방식을 채택했지만, 현재는 ART 방식으로 변환된 상태다.
그 이유는 바로 DVM compile에서 사용한 JIT compile 방식 때문으로, ART의 AOT compile 방식과 큰 차이점이 존재한다.
- JIT (Just In Time) 방식
DVM에서 사용한 compile 방식으로 application을 최초 실행할 때 compile을 수행하는 기법이다.stack based 방식이기 때문에 설치 속도가 빠른 장점이 있고 용량이 비교적 적다는 장점도 있으나,하드웨어의 부하로 배터리 사용 시간 감소와 같은 부정적인 영향을 미친다.
특징: 실행속도 빠름, 배터리 사용량 증가, CPU 사용률 증가
- AOT (Ahead Of Time) 방식
2014년 Lollipop 이후에 적용된 compile 방식
Application 설치를 하게 되면, 그때 compile을 실행한다. (전력소비를 최소화하고 성능을 배가시키는 장점이 있다.)
특징: 실행속도는 JIT에 비해 느림, 배터리 사용량 감소, CPU 사용률 감소 (JIT와 비교)
2016년 7.0 version 이후로는 ART에서 JIT와 AOT 방식을 모두 채택하여 사용할 수 있는 상태다.
Libraries
ART와 HAL 등 많은 핵심 Android 시스템 구성요소와 서비스는 C/C++로 작성된 네이티브 라이브러리를 필요로 하는
네이티브 코드 기반으로 이뤄져 있다.
안드로이드는 JAVA framework API를 이용하고 일부 네이티브 라이브러리 기능을 application에 제공하고 있다.
주로 SO 확장자 형태로 저장하고 추후 Dex file과 SO file들을 모두 압축하게 되면 APK file이 생성된다.
4. Application Framework Layer
안드로이드 프레임워크는 JAVA API 프레임워크를 뜻한다. 안드로이드 OS의 전체 기능은 JAVA로 작성된
API를 통해서 접근이 가능하다.
API는 핵심 시스템 구성요소 모듈과 서비스 재사용을 단순화하여 안드로이드 application을 제작하는데 필요한
빌딩 블록을 구성하고, 다음과 같은 항목들을 가지고 있다.
5. Application Layer
apk file이 설치되는 위치로 안드로이드에서 기본적으로 제공하는 application과 앱스토어에서 다운로드하여
서비스를 사용하는 영역
Application layer에서 독립된 application 간의 상호작용이 발생할 수 없는데 바로 Android Rooting 때문이다.
이로 인해 Application layer에서 application 간의 관계는 sandbox 형식으로 서로 간의 접근이 불가능하게 되어있다.
Android Rooting이란?
안드로이드의 최고권한을 얻어 해당 기기의 생산자나 판매자 측에서 걸어놓은 제약을 해제하는 행위를 뜻한다.
처음 모바일 디바이스를 구매하면 사용자는 해당 디바이스의 주인이라고 생각할 수 있으나, 사용자에게 Root 권한은 없다.
따라서, 모바일 디바이스에 Root 권한을 갖게 되면, 어떠한 application 안으로 접근할 수 있는 권한을 얻게 된다.
Application layer의 구성요소는 다음과 같다.
- Activity
첫 화면 main page, 사용자와 상호작용하기 위한 진입점으로 사용자 interface를 뜻함
예를 들어, email application에서 "작성/목록/읽기"와 같은 버튼을 클릭하면 동작하는 것이 바로 activity다.
- Service
Background에서 application이 계속 실행되기 위한 다목적 진입점으로 사용자 interface를 제공하지 않음
- Broadcast receiver
모든 사용자들에게 전달하는 service로 system에서 발생한다.
예를 들어, 화면 꺼짐, 배터리 부족, 사진 캡처 감지 알림과 같이 system에서 발생한 이벤트들을 알릴 때 사용
- Contents Provider
파일 시스템 공유 역할을 담당한다.파일 시스템, SQLite DB, 접근가능한 저장소에 저장 가능한 application data의 공유형 집합을 관리한다.