[Kotlin 깃북] Ch1 코틀린 안드로이드 이해하기
1. 안드로이드와 코틀린
운영체제와 플랫폼
-
안드로이드 플랫폼
- 리눅스 운영체제 안에서 리눅스와 상호작용하며 작동
- 전체 아키텍쳐 위 쪽, 런타임 영역에서 안드로이드 실행됨
플랫폼 버전과 API 레벨
- 안드로이드는 사용하는 플랫폼 버전과 별개로 API 레벨이 있음
- API : 개발자에세 안드로이드 플랫폼의 기능을 사용할 수 있게 제공하는 도구
- API 레벨의 변경 사항이 있을 때는 기존 코드를 확인해야
- API 레벨에 따라 새로운 기능 추가될 수 있음
- API 레벨에 따라 코드 전체를 변경해야할 수 있음
- https://developer.android.com/guide/topics/manifest/uses-sdk-element?hl=ko#ApiLevels
- 현재 플랫폼 최신 버전: 안드로이드 13(베타)
(실제 사용자가 사용하는 버전은 훨씬 다양) - 현재 API레벨 21(롤리팝) 버전 이상을 사용하는 디바이스 = 전체의98.8%
-> 특별한 경우가 아니라면 그 이전 버전 고려 X
- 안드로이드는 일년에 한번 정도 새로운 버전의 안드로이드 출시됨(= 메이저 버전 업데이트)
- 새로운 버전으로 사용자가 옮겨가는 데에는 몇 년의 시간 소요
-> 항상 최신 버전에 맞춰 개발할 필요 X
Kotlin
- 안드로이드 플랫폼의 구조 = 리눅스 커널 + 자바 API 프레임워크
- 과거엔 JVM(정확히는 Dalvik VM) 위에서 앱이 동작했지만, 현재는 📌안드로이드 런타임(ART) 사용
-> JVM이 없지만, 여전히 자바의 동작 구조 차용(∵여전히 가상 머신 위에서 동작)
- 기존에는 앱 개발 언어로 주로 자바 사용
-> 2017년 5월 Google I/O에서 Kotlin을 공식 언어로 채택
-> 2019년 Google I/O에서 Kotlin 퍼스트 선언
함수형 프로그래밍 언어 코틀린
- 객체지향 프로그래밍: 클래스 내부에 있는 함수에서만 로직 작성
- 함수형 프로그래밍: 이런 제약 없이 어디서나 로직 작성 가능
안드로이드 개발에 있어서 자바와 코틀린의 차이
- Kotlin으로 작성하는 경우, Java로 작성했을 때보다 코드 양 적다
참고자료
📌JVM, DVM, ART
JVM(Java Virtual Machine)
- JVM: 자바 바이트 코드를 실행할 수 있는 주체
- 자바 바이트 코드: 플랫폼에 독자적, JVM에 의존적
- 플랫폼에 독자적 = 플랫폼에 맞춰 소스코드를 필드할 필요 X
= 한번의 빌드로 여러 플랫폼에서 실행할 수 있다
= WORA(Write Once, Run Anywhere)
- 예) A.java 소스파일 -> java 컴파일러로 바이트 코드로 변환 -> A.class 파일
플랫폼(윈도우즈, 맥, 리눅스)과 상관없이 JVM이 동작하는 환경이라면 새로 컴파일할 필요 없이 실행 가능
- JVM의 특성
- 📌스택 기반의 가상 머신
- 단일 상속 형태의 객체 지향 프로그래밍을 가상 머신 수준에서 구현
- 포인터 지원 (단, C와 같이 주소 값을 임의로 조작 가능한 포인터 연산 불가능)
- 가비지 컬렉션 사용
- 모든 기본 타입의 정의 명확히 함 (-> 플랫폼 독립성 보장)
- 데이터 흐름 분석에 기반한 자바 바이트 코드 검증기
(-> 스택 오버플로우, 명령어 피연산자 타입 규칙 위반, 지역 변수 초기화 전 사용, 필드 접근 규칙 위반 등 문제를 실행 전에 검증)
DVM(Dalvik Virtual Machine)
- DVM: 안드로이드 어플리케이션을 실행할 수 있는 가상 머신
= 모바일 기기 환경에 최적화된 가상 머신
- DVM의 특성
- 📌레지스터 기반의 가상 머신
- 다중 인스턴스로 실행되도록 설계 -> 애플리케이션에 자체적인 VM 인스턴스 제공
(반면, JVM은 단일 인스턴스로 여러 어플리케이션에서 공유되어 사용됨)
ART(Android Runtime)
- Android Runtime: 안드로이드 애플리케이션 런타임 환경
- 새로운 디버깅 기능 제공
- 고수준의 애플리케이션 프로파일링 기능 제공
📌DVM 컴파일러(JIT), ART 컴파일러(AOT)
- 출처:
- APK가 만들어지는 과정
(1) .java 파일 -> java 컴파일러로 자바 바이트 코드로 변환 -> .class
(2) .class -> Dex 컴파일러로 dex 파일(DVM에서 실행 가능)로 변환 -> .dex
(3) dex 파일 & 리소스를 포함한 기타 라이브러리 압축 -> APK(Android application Package)
DVM 컴파일러(JIT)
- JIT(Just In Time): DVM 내부 컴파일러
(Android 2.2(Froyo)부터 적용)- 애플리케이션 바이트 코드를 VM에서 기계어로 변환한 결과를 캐쉬에 저장
- .dex파일 ->dexopt 툴을 이용해 .odex파일로 변형 -> DVM JIT 컴파일러로 기계어로 번역
- 장점: 퍼포먼스 개선
- 단점: 캐쉬 사용으로 일반적인 📌interperter 방식보다 많은 메모리 필요
ART 컴파일러(AOT)
- AOT(Ahead Of Time): ART 내부 컴파일러
- 애플리케이션이 설치되는 시점에 애플리케이션 전체 바이트 코드를 기계어로 변환
- .dex파일 -> dex2oat 툴을 이용해 .dex->.odex->.oat 파일로 변환 -> ART AOT컴파일러로 기계어로 번역
- 장점: 런타임에서 바이트 코드를 해석하는 시간 제거
-> 퍼포먼스 개선, 배터리 수명 향상 - 단점: 설치 시간 오래 걸림
- Android 7(Nugat) 버전 이후에는 ART에 AOT와 더불어 JIT 컴파일러까지 탑재
DVM vs ART
📌Compiler 언어 vs Interpreter 언어
-
Compiler 언어와 Interpreter 언어의 차이: 컴파일을 수행하는 시점
- Compiler 언어: 런타임 전에 컴파일 수행
- 장점: 빠른 실행 속도(∵실행 전 컴파일 해둠)
- 단점: 플랫폼 종속성, 디스크 공간 활용 떨어짐
- Interperter 언어: 런타임에 컴파일 수행
- 장점: 코드 변경 시에도 즉시 실행 가능
- 단점: 느린 실행 속도(∵런타임 중 한줄한줄 컴파일해야)
- Compiler 언어: 런타임 전에 컴파일 수행
- 자바의 경우, java 컴파일러를 통해 컴파일하여 바이트 코드로 변환 -> 컴파일러 언어
VM에서 바이트 코드를 다시 기계어로 변환 -> Interpreter 언어의 특징
📌스택 기반 가상 머신, 레지스터 기반 가상 머신
- 가상 머신이라면 구현해야 할 컨셉
- 소스 코드를 VM이 실행가능한 바이트 코드로 변환할 수 있어야
- 명령어와 피연산자를 포함하는 데이터 구조
- 함수를 실행하기 위한 콜 스택
- 다음 실행할 명령어를 지정하는 포인터 = IP(Instruction Pointer)
- 가상 CPU: 명령어 fetch -> decoding -> execution
- 가상 머신을 구현하는 방법: Stack 기반/Register 기반
-> 피연산자를 저장하고 다시 가져오는 메카니즘의 차이
Stack 기반 가상 머신
- ex. Java VM (대다수의 가상 머신이 스택 기반)
- 피연산자와 연산 후 결과를 스택에 저장
-> 명령어가 피연산자의 레지스터 주소 기억해야
- 예. 아래와 같은 연산을 할 경우 4단계의 명령 필요
(1) POP 20
(2) POP 7
(3) ADD 20, 7, result
(4) PUSH result
- 장점: 다음 피연산자의 메모리 위치 기억할 필요 X
(SP(Stack Pointer)가 다음 피연산자의 위치를 나타냄)
Register 기반 가상 머신
- ex. Lua VM, Dalvik VM
- 피연산자 CPU의 레지스터에 저장
- 예. 아래와 같은 연산을 할 경우 하나의 명령 필요
(1) ADD R1, R2, R3
- 장점:
- 스택 기반 VM 보다 더 빠르다
- 명령어 최적화 가능
(ex. 어떤 연산 결과가 나중에 또 필요할 때, 레지스터에 저장하여 다시 계산하지 않고 연산 결과 활용 가능)
- 단점:
- 스택 기반보다 명령어의 길이가 길다 (∵피연산자 레지스터 주소 명시)
Be able to be vulnerable, in search of truth