대학 시절을 포함하여 안드로이드 개발을 해온지 벌써 2년 정도가 되었다. 실무에서 안드로이드 개발을 한지는 어느덧 4개월이 되었는데, 그동안 시니어 개발자분들 밑에서 일을 배우면서 내가 그동안 정말 겉핥기 식으로만 안드로이드 공부를 했다는 것을 깨달았다. 온갖 신기술은 다 쓰려고 하면서, 안드로이드 OS가 어떤 구조로 이루어져 있는지, 어떤 방식으로 빌드가 되는건지 등등 기본 지식에는 관심을 가지지 않았다. 아직 주니어의 ‘주’ 라고만 할 수 있는 위치라지만 그래도 안드로이드 개발자로서 플랫폼 아키텍처 정도는 알아야 하지 않겠는가. 어쨌든 이번에 플랫폼 아키텍쳐를 공부하면서 그동안 궁금했던 안드로이드 역사나, 왜 구글이 안드로이드 공식 언어로 자바를 선택했는지, 뭐 이런 부가적인 정보들도 간단하게 알아보면서 알게된 것들을 간단하게 글로 남기기로 했다.
목차
- 안드로이드 OS
- 안드로이드 첫 공식 언어, Java
- 안드로이드 플랫폼 아키텍쳐
Android OS
안드로이드는 리눅스 커널 기반의 모바일 플랫폼 전용 운영체제이자 오픈소스 소프트웨어다.
안드로이드는 원래 디지털 카메라용 OS를 개발하려고 하던 신생 회사의 이름이었다. 휴대폰이 등장하고, 휴대폰에 카메라가 접목되어 나오면서 디지털 카메라 시장이 약간 주춤했고, 안드로이드 역시 트렌드에 맞춰가기 위해 휴대폰의 OS를 개발하기 시작하면서 지금의 안드로이드 OS가 개발되었다고 한다.
2005년 구글이 안드로이드를 인수했고, 안드로이드 OS에 맞는 애플리케이션 개발을 위해 젯브레인과 협업하여 인텔리제이 기반의 IDE인 안드로이드 스튜디오를 만들었다. 초기에 구글은 안드로이드 공식 언어로 자바를 선택했는데, 나는 종종 왜 구글이 자바를 선택했는지 이유가 궁금했다.
아래 글을 읽어보면, 일단 기술적인 이유, 즉 자바라는 언어가 가진 장점이 주된 이유 중 하나였던 것 같다. 일단 자바는 멀티 플랫폼 언어다.
C나 C++ 로 작성된 소스코드는 컴파일러에 의해 어셈블리 코드로 변환되고, 어셈블리 코드는 어셈블러에 의해 기계어, 즉 컴퓨터가 읽을 수 있는 코드로 변환된다. 만약 이 과정이 윈도우에서 이루어졌다면, 윈도우에서 생성된 머신코드는 윈도우에서만 실행할 수 있기 때문에 맥이나 우분투같은 타 OS에서 실행하려면 처음부터 다시 소스코드를 컴파일 해야한다. 즉 플랫폼에 종속적이다.
그러나 자바의 경우는 다르다. 자바로 작성된 소스코드는 javac라는 자바 컴파일러에 의해 바이트코드로 변환되고, 이 바이트 코드는 JVM이라는 가상머신의 컴파일러에 의해 각 OS에 맞게 실행될 수 있도록 변환된다. 그러니까 어느 OS든 JVM이 설치되어 있다면 다시 컴파일 할 필요 없이 자바 소스코드를 실행할 수 있다는 뜻이며, 이는 곧 플랫폼에 독립적임을 뜻한다.
또한 자바는 가비지 컬렉션이 자동으로 메모리 관리를 해주는 장점도 존재했다. 여튼 이러한 기술적인 이유들도 있었고, 또다른 이유로는 자바라는 언어가 가진 대중성이었다. 안드로이드가 개발되던 초기에 자바는 인기있고 대중적인 언어였고(지금도 역시 마찬가지지만), 따라서 개발자 시장엔 자바 개발자들이 넘쳐났다. 자바같은 대중적이고 접근하기 쉬운 언어를 사용해야 안드로이드 개발에 관심을 갖는 개발자들이 많아질테고, 그들이 안드로이드 개발에 빠르게 적응할 수 있다면 그것이 곧 안드로이드의 빠른 성장을 불러올 수 있기 때문이었다.
Why did Google choose Java as the programming language of Android and not Python or something else?
자바는 배우기 쉽고, 강력한 언어다. 하지만 자바의 문법 특성 상 코드가 길어질수록 장황해지고 복잡해진다. 이는 곧 생산성 측면에서 좋지 않고, 당시 자바를 두고 오라클과의 저작권 분쟁도 있었기에 구글 입장에서는 자바의 대안이 필요했다.
코틀린은 젯브레인에서 만든 JVM 기반의 언어다. 자바와 100% 호환되면서도, 간결한 문법과 null safety 등 기존 자바의 단점을 보완할 수 있었기에 자바의 대안으로서 충분했다. 따라서 2017년, 구글은 안드로이드 공식 언어로 코틀린을 추가하였다.
Android Platform Architecture
안드로이드는 오픈소스 소프트웨어 스택이다.
오픈소스
- 안드로이드는 구글이 주도하는 오픈소스 프로젝트로, 일부 칩셋 관련 부분을 제외하면 누구나 안드로이드를 구성하고 각 소프트웨어의 소스코드를 볼 수 있다.
소프트웨어 스택?
- 스택은 아래에서부터 위로 쌓여있는 모양인데 위 사진에서 보다시피 안드로이드는 소프트웨어가 스택 형태로 쌓여있기 때문에 소프트웨어 스택이라고 한다.
그럼 안드로이드 플랫폼 구조를 하나씩 살펴보자.
Linux Kernel
안드로이드는 리눅스 커널 기반이다. 안드로이드는 리눅스 커널을 사용하여 메모리 및 드라이버, 전원 관리 등의 작업을 한다.
Linux Kernel
- Linux OS의 메인 컴포넌트이자, 컴퓨터 하드웨어와 프로세스 사이를 잇는 핵심 인터페이스
- 컴퓨터의 물리적 자원(하드웨어)과 추상화 자원을 관리
- 추상화 : 물리적으로 하나 뿐인 하드웨어를 여러 사용자들이 번갈아 사용하게 중재함으로써, 마치 한 개의 하드웨어가 여러개인 것처럼 보여지도록 하는 기술
- 물리적 자원인 하드웨어에 접근하기 위한 방법은 매우 복잡하고 어려운데, 사용자가 이를 직접 접근하기에는 무리가 있음 → 이러한 물리적 자원을 추상화하여 사용자가 보다 쉽게 접근할 수 있도록 도와주는 것이 커널
- 주요 기능
- 메모리 관리, 프로세스 관리, 장치 드라이버, 시스템 호출 및 보안
안드로이드는 수많은 리눅스 배포판 중 하나인 셈이다.
HAL(하드웨어 추상화 계층)
자바 API 프레임워크의 요청에 따라 오디오, 블루투스, 카메라와 같은 하드웨어 모듈의 기능을 사용할 수 있도록 라이브러리 모듈을 제공한다.
Native C/C++ Libraries
안드로이드 런타임(ART), HAL 등 많은 핵심 안드로이드 구성요소와 서비스가 사용하는 C/C++로 작성된 라이브러리다. 안드로이드는 C/C++과 같은 네이티브 코드로 안드로이드 앱의 일부를 구현할 수 있도록 NDK(Native Development Kit)를 제공하고 있다.
- Webkit : 웹 브라우저를 만드는 데 기반을 제공하는 오픈 소스 응용 프로그램 프레임워크
- OpenGL ES : OpenGL은 3D 그래픽 처리 하드웨어에 대한 표준 소프트웨어 인터페이스를 지정하는 크로스플랫폼 그래픽 API이며, OpenGL ES는 안드로이드와 같은 임베디드 장치를 위한 가볍고 쉬운 API 제공
ART (Android Runtime)
ART는 안드로이드의 애플리케이션 및 일부 시스템 서비스에서 사용하는 관리형 런타임이다. ART가 뭔지, 왜 등장했는지 이해하기 위해선 먼저 JVM과 DVM(Dalvik Virtual Machine)에 대해 이해하고 넘어가야 한다. 위에서 이미 언급했지만 안드로이드는 초기에 공식 언어로 자바를 선택했고, 따라서 안드로이드 역시 JVM을 사용할 수 있었으나, 당시 데스크탑에 비해 CPU 및 배터리 측면에서 모바일 환경은 다소 열악했고, 또한 라이센스 문제도 있었기 때문에 안드로이드 환경에서의 JVM은 적합하지 않았다.
따라서 안드로이드에 최적화된 가상머신인 Dalvik virtual machine, 즉 DVM이 등장했다. 자바로 작성된 소스코드가 자바 컴파일러에 의해 바이트 코드로 컴파일되는 과정까지는 데스크탑이나 안드로이드나 동일하지만, 안드로이드에서는 ‘덱스 컴파일러’에 의해 바이트 코드가 DVM이 읽을 수 있는 덱스 파일로 변환된다.
덱스 파일과 다른 리소스 파일 및 key store가 합쳐져 하나의 APK 파일이 생성된다.
DVM은 JIT 컴파일 방식을 사용한다. 즉 런타임 시에 실시간으로 컴파일을 하기 때문에 설치 시 속도가 빨랐으며, 레지스터 기반이기 때문에 스택 기반의 JVM보다 빠른 성능을 낼 수 있었다.
하지만 런타임 시에 컴파일을 하기 때문에 실행 속도가 느렸고, 번역한 정보를 메모리에 올렸기 때문에 메모리 부하가 컸으며, 배터리 성능 면에서도 좋지 않았다. 이를 개선하기 위해 안드로이드 Froyo 버전 이후 Trace JIT 방식을 사용했지만, 이 역시 성능을 개선하기에는 한계가 존재했다.
Trace JIT
- 프로그램 실행 시 자주 사용되는 부분의 바이트 코드를 미리 기계어로 해석
- 번역 결과를 traslation cache에 저장하고, 실행 중에 translation cache를 확인해서 번역본이 존재하면 가져다 사용하고 없으면 바로 번역 후 translation cache에 저장하면서 컴파일
이러한 DVM의 단점을 개선하여 나온 것이 바로 ART다. ART 환경에서는 앱 설치 시 한번에 컴파일을 하기 때문에 설치 속도가 느리며, 앱 용량이 커진다는 단점이 존재했으나 런타임에 컴파일을 하지 않기 때문에 실행 속도가 많이 개선되었으며, CPU의 부하가 감소되어 배터리 성능을 향상시킬 수 있었다.
Java API Framework
안드로이드의 모든 기능은 자바로 작성된 API를 통해 사용할 수 있다.
- View System : UI를 구현할 수 있도록 리스트, 그리드, 텍스트, 버튼 등의 뷰 위젯 제공
- Resource Manager : 문자열, 레이아웃 파일 또는 이미지와 같은 리소스에 접근
- Notification Manager : 상태바에 커스텀한 알람 표시
- Activity Manager : 앱의 생명주기와 일관적인 내비게이션 백스택 제공
- Content Provider : 다른 앱의 데이터에 접근하거나 자체 데이터를 공유할 수 있도록 기능 제공
System Apps
안드로이드는 이메일, 달력, 카메라, 전화 등 기본 어플을 함께 제공한다. 이렇게 기본적으로 포함된 앱은 기본적인 기능을 제공할 뿐만 아니라, 개발자가 개발하고 있는 자체 앱에서도 접근하여 기본 앱의 기능을 사용할 수 있다. 예를 들어서 개발중인 앱에서 SMS 메시지를 전달하려는 경우 해당 기능을 직접 구현할 필요 없이 이미 설치된 메시지 앱을 호출하면 된다.
References
안드로이드(Android) 정리 시작 배경과 역사
JAVA의 컴파일과 실행
플랫폼 아키텍처 | Android 개발자 | Android Developers
[안드로이드]안드로이드란?/안드로이드 플랫폼/운영체제/시스템
안드로이드 프레임워크
Android Runtime Environment: DVM vs ART
JVM, DVM, ART 이해하기 | 찰스의 안드로이드
[Android] 컴파일 과정 (Dalvik vs ART)
