Native Android Physics & Mechanics

1. Overview

네이티브 안드로이드 물리(Native Android Physics, NAP)는 전 세계 수만 개의 서로 다른 하드웨어(단말기) 위에서 동작해야 하는 구글(Google)의 개방형 생태계가, 어떻게 파편화를 극복하고 메모리와 프로세스를 수리적으로 통제하는지를 다루는 '가상 머신 기반 모바일 공학'입니다.

학습자는 Java/Kotlin으로 작성된 코드가 기계어로 번역되어 실행되는 **ART(Android Runtime)**의 AOT/JIT 혼합 컴파일 역학과, 한정된 메모리를 쥐어짜는 **가비지 컬렉터(GC)**의 수리적 회수 알고리즘을 배웁니다. 또한 앱이 화면에서 사라졌을 때 OS가 메모리를 확보하기 위해 가차 없이 프로세스를 죽여버리는 **생명 주기(Lifecycle)**의 살벌한 관리 체계와, 상태(State)의 변화를 화면에 효율적으로 투영하는 최신 Jetpack Compose 선언형 렌더링의 물리를 해부하며 고성능 안드로이드 아키텍처를 마스터합니다.

2. Scope & Boundaries

In-Scope

• ART 런타임 역학 (ART Runtime): DEX 바이트코드 컴파일, AOT(Ahead-of-Time) vs JIT(Just-in-Time) 컴파일 물리, Zygote 프로세스 부팅.
• 메모리 및 GC 거버넌스 (Memory & GC): 가비지 컬렉션(Generational GC), 힙(Heap) 구조, 메모리 릭(Context Leak), OOM(Out of Memory) 방어.
• 안드로이드 코어 프레임워크 (Framework): Activity 생명 주기, 백그라운드 프로세스 우선순위(OOM Killer/LMK), 바인더(Binder) IPC 물리 통신.
• 선언적 렌더링 물리학 (Compose Physics): Jetpack Compose의 상태(State) 구독 체계, 트리 비교(Diffing), 재구성(Recomposition) 제어.

Out-of-Scope

• 크로스 플랫폼 앱 개발: Flutter나 React Native 엔진으로 안드로이드 앱을 찍어내는 방식 → 13-03. Cross-Platform & Hybrid Physics 영역.
• 순수 커널 수정 및 커스텀 롬 제작: 리눅스 커널(Linux Kernel) 자체를 수정하거나 하드웨어 드라이버를 포팅하는 작업 → 03. SSM 영역.

Boundaries

• NAP vs. NIP (13-01): NIP(iOS)가 "모든 기기 사양을 통제할 수 있으니 GC를 없애고 컴파일 타임에 수동으로(ARC) 조이자"는 철학이라면, NAP는 "기기 스펙이 너무 다양하니 강력한 가상 머신(ART)과 지능적인 청소부(GC)를 띄워 런타임에 문제를 해결하자"는 범용성의 철학을 다룹니다.

3. Counterexample

• 생명 주기 망각 (Context Leak Fallacy): 앱이 화면에 떠 있을 때만 돌아가는 Activity의 생명(Lifecycle)과 앱이 살아있는 동안 영원히 도는 Application의 생명을 혼동하는 기초적 재앙. 스레드를 돌리면서 파라미터로 Activity의 Context를 무심코 넘기면, 사용자가 뒤로 가기를 눌러 화면을 닫았음에도 불구하고 스레드가 뷰(View)를 붙잡고 놔주지 않아 100MB짜리 거대한 메모리 누수(Memory Leak)가 발생하며 앱이 뻥 터집니다(OOM).
• 영원한 백그라운드의 착각 (Immortal Process Fallacy): "서버처럼 앱의 변수값은 한 번 저장해 두면 내가 끄기 전까지 영원히 남아있겠지"라고 믿는 오만. 안드로이드 운영체제(OS)는 배터리와 메모리를 확보하기 위해 백그라운드로 내려간 앱을 언제든 자비 없이 죽여버립니다(Low Memory Killer). 앱이 죽었다가 다시 켜질 때 화면과 데이터를 완벽히 복원하는 SavedState 수리적 스냅샷 구조를 구축하지 않으면, 사용자가 앱을 켰을 때 초기 화면으로 튕겨 나가는 끔찍한 UX를 초래합니다.

4. Prerequisites

• 객체 지향 프로그래밍 (Basic): Java나 Kotlin의 클래스, 상속, 인터페이스 구조를 완벽히 다뤄야 안드로이드 프레임워크를 이해할 수 있습니다. (05. PLC)
• 운영체제와 가상 머신 (Recommended): 프로세스 분리와 스레딩, 가상 머신(VM)의 기본 동작 원리를 알면 ART의 물리를 이해하기 쉽습니다. (03. OS)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: ART 런타임과 컴파일 역학 (ART Execution)

• Why to Learn: 내가 짠 앱이 사용자의 폰에 설치될 때 용량을 줄이고 실행 속도를 극한으로 끌어올리기 위한 엔진의 원리를 파악하기 위해서입니다.
• What to Learn:
  • Concepts: JVM vs DVM vs ART(Android Runtime).
  • Skills: DEX(Dalvik Executable) 바이트코드, JIT(Just-In-Time) 컴파일, AOT(Ahead-Of-Time) 컴파일, 프로필 기반 최적화(PGO).
  • Tools: Android Studio Profiler, dexdump.
  • Trade-offs: 앱을 설치할 때 모든 코드를 기계어로 완전히 번역(AOT)해 두어 실행 속도를 빛처럼 빠르게 만들지만 설치 시간이 5분씩 걸리던 구형 ART 방식 vs 평소에는 놔두다가 자주 쓰는 코드만 런타임에 얍삽하게 컴파일(JIT/Profile-Guided)하여 설치 속도와 실행 속도를 모두 잡은 현대 하이브리드 ART의 절충.
• How to Learn:
  • 1단계: Zygote라는 안드로이드의 '어머니 프로세스'가 미리 공통 라이브러리(부품)를 메모리에 잔뜩 올려둔 채로 대기하다가, 새 앱을 켤 때마다 자기를 복제(Fork)하여 0.1초 만에 앱을 부팅시키는 물리적 꼼수를 분해합니다.
  • 2단계: 코틀린 코드가 .class 파일로 컴파일된 후, 안드로이드 전용 압축 포맷인 classes.dex로 한 번 더 변환되며 모바일 기기의 배터리와 저장 공간을 아끼는 수리적 메커니즘을 뜯어봅니다.
• Implement: 특정 수학 연산(예: 행렬 곱셈) 코드를 여러 번 실행하면서, 최초 실행 시점의 지연 시간(JIT 컴파일 대기)과 100번째 실행 시점의 최적화된 기계어 실행 시간을 수치적으로 측정하여 비교하는 벤치마크 리포트.

Recommended

Core Topic 02: 가비지 컬렉션과 메모리 누수 방어 (GC & Leaks)

• Why to Learn: 화면이 1초에 60번씩 부드럽게 그려지는 도중에, 쓰레기차가 지나가며(GC) 도로를 막아버리는 'Stop-the-world' 렉(Jank) 현상을 막기 위함입니다.
• What to Learn:
  • Concepts: 가비지 컬렉션(GC) 루트(Roots), 세대별 메모리 모델(Young/Old Generation).
  • Skills: GC Thrashing, 메모리 누수(Context Leak/Inner Class Leak), OOM(Out of Memory) 회피.
  • Tools: LeakCanary, Android Studio Memory Profiler.
  • Trade-offs: 객체를 쓸 때마다 매번 new로 새로 만들어서 GC가 치울 쓰레기 산을 만들어버리는 편안한 코딩 vs 객체를 수영장(Pool)에 띄워놓고 재활용(Flyweight/Object Pool)하여 GC가 아예 발동조차 하지 않게 틀어막는 극한의 메모리 통제력.
• How to Learn:
  • 1단계: 갓 태어난 변수들(Young Gen)은 빠르게 쓰고 버려지므로 짧은 시간에 한 번에 쓸어 담고, 오래 살아남은 무거운 놈들(Old Gen)은 드물게 청소하는 세대별 GC의 물리적 효율성을 수학적으로 추적합니다.
  • 2단계: 싱글톤(Singleton) 객체 안에 화면(Activity)의 Context를 저장해버리면, 화면을 닫고 다른 화면으로 넘어갔는데도 싱글톤이 예전 화면을 계속 붙들고 놔주지 않아 메모리 공간이 터져버리는 끔찍한 연쇄 붕괴를 실습합니다.
• Implement: 백그라운드 스레드와 Activity 간의 잘못된 강한 참조(Strong Reference)로 인해 발생하는 고의적인 메모리 누수 코드를 작성하고, LeakCanary 툴을 붙여 어느 포인터에서 누수가 터졌는지 수리적으로 증명하고 해결하는 프로젝트.

Practical

Core Topic 03: 생명 주기 역학과 LMK 방어 (Lifecycle & OOM Killer)

• Why to Learn: 안드로이드는 램(RAM)이 부족해지면 뒤에 숨어있는 앱부터 총으로 쏴 죽이는데(LMK), 총에 맞고 부활했을 때 기억 상실에 걸리지 않게 데이터를 백업하기 위해서입니다.
• What to Learn:
  • Concepts: Activity Lifecycle (Create → Start → Resume → Pause → Stop → Destroy).
  • Skills: Low Memory Killer (LMK), 상태 복원(SavedInstanceState), 안드로이드 코어 아키텍처(ViewModel).
  • Tools: 개발자 옵션 ('활동 보존 안 함' Don't keep activities).
  • Trade-offs: 사용자가 입력하던 텍스트를 SQLite나 Room DB 등 물리적 하드디스크(I/O)에 실시간으로 매번 기록하는 극강의 안전성 vs 가벼운 메모리 묶음(Bundle)에만 담아 시스템 캐시에 휙 던져놓고 앱이 죽을 때만 챙겨가는 속도 중심의 상태 복원(SavedState).
• How to Learn:
  • 1단계: 화면 위에 투명한 팝업(Dialog)이 뜨면 원래 화면은 멈춘 것(Pause)이지 죽은 것(Stop)이 아님을 깨닫고, 배터리를 갉아먹는 무거운 애니메이션을 정확히 onPause에서 정지시키는 타이밍 공학을 배웁니다.
  • 2단계: 폰을 '가로 모드'로 돌리는 순간 화면 해상도가 바뀌기 때문에 OS는 과감하게 화면 전체를 죽여버리고(Destroy) 다시 만드는데(Create), 이때 데이터가 날아가지 않도록 안전 금고(ViewModel)에 데이터를 피난시키는 구조를 분해합니다.
• Implement: 복잡한 회원가입 폼을 작성하는 도중 다른 무거운 게임을 켜서 내 앱이 백그라운드에서 강제로 암살(LMK)당한 뒤 다시 돌아왔을 때, 모든 입력 데이터와 스크롤 위치가 0.1초 만에 물리적으로 복원되는 ViewModel + SavedState 아키텍처 구현.

Advanced

Core Topic 04: Jetpack Compose 렌더링 물리와 재구성 (Compose Dynamics)

• Why to Learn: "텍스트 글자 하나 바뀌었을 뿐인데 100개짜리 리스트 화면 전체를 다시 그려버리는" 바보 같은 UI 렌더링 성능 낭비를 픽셀 단위로 막아내기 위해서입니다.
• What to Learn:
  • Concepts: 선언적(Declarative) UI, 부수 효과(Side-Effects).
  • Skills: 상태(State) 구독 체계, 재구성(Recomposition), 건너뛰기(Skipping), 안정성(Stability) 추론.
  • Tools: Compose Compiler Metrics, Layout Inspector.
  • Trade-offs: "버튼을 누르면 글자가 바뀐다"는 상태 제어 코드를 위젯 안에 다 때려 넣어 코드를 읽기 쉽게 만드는 것 vs 데이터(상태)를 가장 꼭대기로 끌어올리고(State Hoisting) 아래로는 순수 함수처럼 변수만 쏴주어 컴포넌트 재사용성을 극한으로 올리는 구조주의적 설계.
• How to Learn:
  • 1단계: 기존의 XML(명령형)은 "A 뷰를 찾아서 글자를 바꿔라"라고 뷰의 주소를 찾아다녔지만, Compose(선언형)는 뷰가 상태(State) 변수만을 바라보고 있다가 변수값이 바뀌면 그 변수를 구독하던 뷰 노드만 스스로 '폭파 후 재생성(Recomposition)'되는 트리(Tree) 물리를 분석합니다.
  • 2단계: 스크롤 위치 같은 매 프레임 변하는 수치를 뷰의 파라미터로 직접 꽂아버리면 1초에 60번 전체 트리가 다시 그려지는(Jank) 지옥이 열리며, 이를 방어하기 위해 파라미터 값이 '진짜로' 바뀌었을 때만 그리도록 건너뛰기(Skipping) 안정성을 부여하는 컴파일러 최적화를 해부합니다.
• Implement: 1,000개의 주식 가격 리스트가 실시간 소켓으로 업데이트될 때, Compose의 재구성 범위(Recomposition Scope)를 추적기(Layout Inspector)로 검증하여 가격이 바뀐 단 하나의 '텍스트 컴포넌트'만 정확히 물리적으로 갱신되는지 증명하는 코드.

7. Terminology

8. References

Primary References

• [P1] CS2023 - Systems Fundamentals - Mobile Systems Runtime — System integration.
• [P5] SFIA v9 - Systems Development - Programming / Device Software — Industry native skills.

Secondary References

• [Android Internals] Jonathan Levin — Deep exploration of OS and VM physical logic.
• [High Performance Android Apps] Doug Sillars — Practical optimization strategies.

Industry References

• [Android Developer - App Architecture Guide] — Official structural standards.
• [Google Developers - Performance Metrics for Android] — SOTA measurement standards.

9. Final Checklist

Primary Checklist

• ART의 AOT와 JIT 컴파일이 앱 설치 및 실행 속도에 미치는 물리적 트레이드오프를 설명 가능한가? (P1)
• 안드로이드 힙(Heap) 메모리 누수가 GC 동작 주기에 미치는 물리적 영향력과 수리적 상관관계를 기술 가능한가? (P1)

Secondary Checklist

• SavedInstanceState를 이용한 수치 복구와 DB 캐시를 이용한 복구의 영속성 물리 범위 차이를 이해하는가?
• ViewModel의 생명 주기가 Activity보다 긴 이유를 시스템 메모리 임계치 행동과 결부하여 논증 가능한가?

Industry Checklist

• 실무 엔지니어링 시 'Profileable' 빌드를 사용하여 런타임 성능 저하 없이 시스템 리소스 점유율을 정밀 산출 가능한가? (SFIA)
• Jetpack Compose 상에서 '안정적(Stable)'이지 않은 파라미터가 왜 과도한 재구성을 유발하는지 물리적 원인을 파악했는가?