[Android] 안드로이드란?

조원희·2023년 5월 23일
0

Android

목록 보기
1/1

안드로이드란?

  • 안드로이드(Android)는 리눅스 커널을 기반으로 구글에서 만든 모바일 운영체제(OS)입니다.
  • 2008년 안드로이드 1.0을 첫 출시한 이후, 현 시점 모바일 OS에서 IOS와 경쟁하고 있는 OS입니다.

안드로이드의 특징

  • 공개 운영체제인 리눅스를 기반으로 합니다.
  • 또한, 안드로이드의 운영채제의 주요부분과 라이브러리 구글이 만든 앱 등의 코드는 대부분 공개되어 있습니다.
  • IOS와는 다르게 안드로이드 OS는 다양한 디바이스를 타겟으로 합니다. 따라서, 안드로이드 개발자는 다양한 안드로이드 디바이스에 대한 대응을 고려해야 합니다.
  • 안드로이드 플랫폼에서는 모든 응용 프로그램이 평등하다는 사상을 바탕으로, 모바일 디바이스에 설치된 앱과 개발자가 만든 앱은 동일한 API를 사용합니다.

안드로이드 운영체제의 구조

출처 : https://developer.android.com/guide/platform?hl=ko

안드로이드 운영체제는 위와 같은 아키텍처로 구성되어 있습니다. 이러한 구조 중에서 특별히 더 중요하게 알아두어야 할 부분은 다음의 세 가지입니다.

① 리눅스 커널
② 하드웨어 추상화 레이어(HAL, Hardware Abstract Layer)
③ 안드로이드 런타임(ART, Android Runtime)

안드로이드 소스코드의 컴파일 과정

  • 안드로이드는 컴파일 과정을 거쳐 최종적으로 DEX파일로 컴파일 됩니다.
  • 안드로이드 소스코드는 자바 또는 코틀린으로 작성되는데, 작성된 소스코드는 각 언어별 컴파일로를 통해 바이트 코드인 .class 파일로 컴파일됩니다.
  • 그후 .class파일은 .dex 확장자를 가지는 DEX 파일로 다시 한번 컴파일 됩니다.

그래서 dex는 무엇일까?

  • dex는 구글에서 모바일 디바이스에서 사용하기 위해 만들었습니다.
  • dex는, Dalvik Executable의 약자이고, Dan Bornstein이 작성한 오픈 소스 소프트웨어입니다.
  • Dalvik이라는 이름은 아이슬란드의 작은 어촌마을인 Dalvík 에서 기원하였다고 합니다.

JVM vs DVM

안드로이드에 .dex가 사용되는 이유를 이해하려면, JVM과 DVM에대한 이해가 필요합니다.

먼저, JVM은 클래스가 필요할 때마다 동적으로 .class 파일을 읽습니다. 이 때 JVM은 컴퓨터의 메모리를 사용하게 되고 스택 기반으로 opcode(작업코드) 를 읽어서 사용합니다.
반면, DVM은 .dex라는 파일에 모든 클래스 파일들을 변환하여 저장합니다. 즉 하나의 파일에 모든 소스가 있는 셈입니다. 그리고 이러한 dex파일로부터 DVM은 opcode(작업코드) 를 읽어서 사용합니다.

정리하자면, JVM은 필요할 때마다 클래스 파일 중에서 골라 쓰는 셈이고, dex는 하나의 파일에서 관리한다는 것입니다.

그런데, 스택 기반의 가상머신은 컴퓨터의 메모리에서 스택으로 프로그램을 관리하는 반면, 레지스터 기반의 가상머신은 컴퓨터 CPU에 직접 접근하기 때문에 속도 측면에서 더 빠르나, CPU의 한정된 메모리를 사용하기 때문에 메모리 용량이 작다 는 단점이 있습니다.

메모리 용량 측면에서는 스택기반의 가상머신인 JVM이 유리하지만, 속도 측면에서는 레지스터 기반의 DVM이 유리한 것입니다.

왜 구글은 DVM을 채택했을까?

지금의 모바일 및 컴퓨터 하드웨어 기술 수준을 생각하면,
굳이 레지스터말고 자바 기반의 JVM을 사용해도 좋았을 것 같은데, 이 이유에 대해서 아직 안드로이드 스튜디오나 구글의 공식 입장을 찾아보진 못했습니다.

그러나, 제 스스로 그 이유를 추론해보자면 안드로이드 OS가 탄생했던 당시의 시대적 배경을 생각하면, 오히려 JVM 보다 DVM을 선택하는 것이 더 합리적이었다고 생각됩니다.

왜냐하면, 초기 모바일 디바이스는 메모리 용량이 그렇게 크지도 않았고, 지금도 안드로이드 앱은 수많은 앱들이 하나의 디바이스에서 빠르게 상호작용하고 동작해야하는 점을 고려해보면, 클래스 로더로 .class 파일을 읽어 들여서 동작하는 JVM보다 컴파일 과정을 한번 더 거치더라도 DVM을 채택하면 빠른 속도도 취하고 안드로이드 앱의 라이프 사이클에 따른 빠른 자원의 관리도 유리한 것으로 보여 JVM보다 DVM이 더 합리적이었을 것 같다는 생각이 들었습니다.

물론, 구글은 아마 이보다 더 많은 이유를 포함하여 OS를 설계하고 개발했겠지만, 제 스스로 찾아 보면서 생각해봤을 때는 이러한 이유로 구글이 JVM이 아닌 DVM을 선택했던 것이 더 합리적이라고 판단했을 것 같습니다.

dex를 사용함으로 인해서 발생한 문제점

이러한 안드로이드의 아키텍처에 따라서 모든 클래스 파일들은 최종적으로 .dex 로 컴파일이 됩니다.
그래서, 안드로이드 개발에서 자주 사용하는 jar 파일들은 어떻게 DVM에서 동작하게 되는지 의문이 생길 수 있습니다. 이는 jar 파일도 dx(Dexer) 를 통해 .dex파일로 컴파일되기 때문에 가능합니다. 그렇기에 dx(Dexer)는 안드로이드의 SDK(Software Develop Kit) 의 표준 구성 요소가 되었습니다.

하지만, dex는 앞서 설명한 구조적 한계 때문에 다음과 같은 이슈가 있습니다.

  1. ANR(애플리케이션 응답 없음)의 발생, 즉 너무 큰 .dex 파일을 읽어들임으로 인해 애플리케이션이 일시적으로 중단되는 것입니다.

  2. multidex 기반 애플리케이션은 Android 4.0(API 레벨 14) 미만의 시스템에서는 정상적으로 작동하지 않을 수 있습니다.

참고하면 좋을 사이트 : https://www.boldare.com/blog/differences-between-class-and-dex-files-in-java-android/

안드로이드 개발 도구

  • 대부분의 안드로이드 앱은 Java로 만든 API를 통해서 개발을 하게 됩니다.
  • 그러나, 안드로이드 앱은 C나 C++로 개발된 네이티브 라이브러리도 사용할 수 있는데, 이를 안드로이드 NDK(Native Development Kit) 라고 합니다.
  • 자바로 만든 라이브러리들은 자바 API 프레임워크 라고 부릅니다.

안드로이드 API LEVELs

API 수준버전명출시연도
1Android 1.02008
2Android 1.12009
3Android 1.5 (컵케이크)2009
4Android 1.6 (도넛)2009
5Android 2.0 (에클레어)2009
6Android 2.0.12009
7Android 2.1 (에클레어)2010
8Android 2.2 (프로요)2010
9Android 2.3 (진저브레드)2010
10Android 2.3.32011
11Android 3.0 (허니콤)2011
12Android 3.12011
13Android 3.22011
14Android 4.0 (아이스크림 샌드위치)2011
15Android 4.0.32011
16Android 4.1 (젤리빈)2012
17Android 4.22012
18Android 4.32013
19Android 4.4 (킷캣)2013
20Android 4.4W2014
21Android 5.0 (롤리팝)2014
22Android 5.12015
23Android 6.0 (마시멜로)2015
24Android 7.0 (누가)2016
25Android 7.12016
26Android 8.0 (오레오)2017
27Android 8.12017
28Android 9.0 (파이)2018
29Android 10.0 (Q)2019
30Android 11.02020
31Android 12.02021
32Android 12.12022
33Android 132022
34Android 14 DEVTBD

안드로이드와 컴포넌트

안드로이드 앱 개발의 핵심은 컴포넌트입니다. 안드로이드에서 동작하는 프로그램을 보통 APP 또는 어플리케이션이라고 칭합니다.
이러한 안드로이드 앱은 컴포넌트로 구성되어 있는데, 안드로이드 앱은 다음의 4가지 컴포넌트로 구성되어 있습니다.

1. 액티비티

  • 안드로이드의 화면 표시(뷰 바인딩 등)를 전적으로 담당하는 컴포넌트입니다.
  • 앱 화면을 리소스 파일과 바인딩하여 사용자에게 상호작용 가능한 인터페이스를 구성하는 역할을 합니다. 액티비티 컴포넌트는 안드로이드 시스템에서 자동으로 생명주기를 관리해 줍니다.
  • 따라서 개발자는 별도로 생명주기를 관리하지 않아도 안드로이드 시스템에서 기본적으로 생명주기를 관리해줍니다.

2. 서비스

  • 화면이 없는 것이 가장 큰 특징인 안드로이드 컴포넌트입니다.
  • 안드로이드에서 앱이 구동중이 아니더라도 백그라운드에서 특정 작업을 수행하고자 할 때 사용할 수 있습니다.
  • 서비스는 서비스의 라이프 사이클을 가지며 액티비티처럼 서비스만의 라이프 사이클을 가집니다.
  • 네트워크 통신과 같이 시간이 오래 소요되는 작업은 서비스 컴포넌트에서 관리하는 것이 바람직합니다.
  • 서비스 컴포넌트의 생명주기는 대부분의 경우 안드로이드 시스템에서 생성(Create)과 파괴(Destroy)를 관리해줍니다.

3. 브로드캐스트 리시버

  • 안드로이드 OS를 탑재한 모바일 디바이스에서 일어나는 여러가지 하드웨어 이벤트들을 감지할 수 있는 컴포넌트입니다.
  • 브로드캐스트 리시버에서 감지하는 이벤트들은 안드로이드 앱 내의 액티비티에서 사용자와 상호작용을 통해 발생하는 이벤트와는 구분되는 개념이며, 주로 전원꺼짐 화면 켜짐과 같이 모바일 디바이스의 하드웨어에서 감지하는 이벤트에 대해서 감지하고 대응할 수 있도록 해줍니다.

4. 콘텐츠 프로바이더

  • 안드로이드 OS의 파일 시스템 관리자 격의 역할을 수행하는 컴포넌트 입니다.
  • 데이터베이스, 파일 또는 네트워크 등의 다양한 데이터를 관리하고 다른 앱과 데이터 공유를 가능하게 합니다.
  • 데이터의 CRUD(Create, Read, Update, Delete) 작업을 제공하고, 안드로이드 시스템 및 다른 앱에서 데이터에 접근할 수 있도록 합니다.

안드로이드에서는 모든 자바 클래스가 컴포넌트인 것은 아닙니다. 안드로이드에서 말하는 컴포넌트들은 위에 설명한 네 가지 컴포넌트 클래스를 상속받는 자바 클래스를 가르키는 말입니다. 또한, 안드로이드 앱은 컴포넌트 뿐만 아니라 일반 클래스도 사용되며 앱마다 필요한 기능을 구현하고 서비스하기 위해 개발자가 직접 만들거나 도입하여 사용하기도 합니다.

안드로이드와 리소스(Resource) 관리

안드로이드 앱 내에서 사용되는 정적 자원들은 리소스를 기반으로 개발합니다. 여기서 리소스란 앱의 레이아웃, 색상 값 등 앱 실행중에 변하지 않는 값들을 의미합니다. 안드이드에서는 이러한 값들을 .xml 파일로 관리합니다.

안드로이드 앱에서 정적인 값들을 담은 xml은 앱 내에서 런타임 시 파싱하여 사용하게 됩니다. 그런데, 이러한 자원들은 .java나 .kt와 같은 자바나 코틀린 클래스로도 관리할 수도 있습니다. 그러나 보통 안드로이드 개발을 하는 데에는 보통 XML로 값을 관리하는 편이며, 안드로이드 스튜디오에서도 이러한 방식을 권장합니다.

만약 리소스를 클래스 파일로 관리하게 되면, 컴파일 시간에 값이 결정되므로, 실행 시간에 추가적인 리소스를 사용하지 않습니다. 반면에, XML 파일은 런타임에 파싱되어야 하므로, 실행 시간에 약간의 오버헤드가 발생 할 수 있습니다.

하지만, 이러한 성능 차이는 무시할 정도로 작아서 실제로는 거의 영향을 미치지 않습니다. 따라서, 안드로이드에서 색상 값과 같은 리소스를 관리하는 것은 개발자의 개발 스타일과 개발 환경에 따라 선택할 수 있는 부분이긴 합니다.

그럼에도 일반적으로는 회사에서는 UX/UI 디자이너와 같이 개발자가 아닌 동료와도 협업하고 소통하기 위해서라도 클래스 파일로 작성하는 것보다 xml 파일로 작성해서 관리하는 것이 더 효율적인 편입니다.

그리고 개발하다 보면 고객의 요청에 따라 수정사항이 발생해도 파일 한 두개의 값만 바꾸어주면 다른 앱들을 수정하지 않아도 관리할 수 있다는 장점이 있어서 안드로이드에서 리소스의 관리는 XML 파일로 별도로 관리하는 것이 권장됩니다.

profile
안드로이드 개발자 wonny 입니다 :)

0개의 댓글