콘텐츠로 바로가기
HY_TECH_BASE

Native Android Physics & Mechanics

Kotlin 및 Android SDK를 기반으로 ART 런타임, 가비지 컬렉션(GC), 뷰 렌더링 시스템 및 라이브사이클 상태 전이를 보장하는 엔지니어링 역학을 다룹니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

네이티브 안드로이드 물리(Native Android Physics, NAP)는 Google의 안드로이드 플랫폼이 앱을 실행하고 자원을 배분하는 내부 가상 머신(ART)과 프레임워크의 저수준 실행 환경 및 수리적 최적화 수순을 다룹니다.

안드로이드는 수천 종류의 파편화된 기기 하드웨어 위에서 안정적으로 동작해야 하는 물리적 숙명을 가집니다. 학습자는 JVM을 넘어선 **ART(Android Runtime)**의 최적화 방식(AOT/JIT), 시스템이 메모리를 회수하는 가비지 컬렉션(GC) 시점의 물리적 트리거, 그리고 화면의 유연성을 보장하는 Jetpack Compose의 재구성(Recomposition) 역학을 배웁니다. 이를 통해 단순히 기능을 구현하는 것을 넘어, 시스템의 물리적 한계를 이해하고 하드웨어 성능을 100% 이끌어내는 고성능 안드로이드 거버넌스 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

  • Execution Engine Physics: ART(Android Runtime)의 작동 물리, DEX 파일 구조 및 실행 시퀀스
  • Resource Management Mechanics: 가비지 컬렉션(GC) 알고리즘과 메모리 세그먼트 관리 수치
  • Component Lifecycle Physics: Activity/Service의 상태 전이 물리 및 프로세스 우선순위(OOM Killer)
  • Modern Rendering Dynamics: Jetpack Compose의 선언적 렌더링 및 상태(State) 구독 모델 역학
  • Android System Internals: 바인더(Binder) IPC의 물리적 통신 오버헤드 및 시스템 서비스 연동

Out-of-Scope

  • 일반적인 안드로이드 디자인 가이드(Material Design) 시각화 (12. VDS 영역으로 위임)
  • 안드로이드 커널(Kernel) 및 드라이버 레이어 제조 (03. SSM 영역으로 위임)

Boundaries

  • NAP vs. App Development: 기초 안드로이드 학습이 'API 사용법'에 치중한다면, NAP는 그 API가 호출되었을 때 내부 프로세스가 어떻게 분기되고 메모리 스냅샷이 어떻게 유지되는지의 '시스템적 메커니즘'에 집중합니다.

3. Counterexample

  • 단순히 "Android Studio 사용법"을 익히는 것은 NAP 학습이 아닙니다. 왜 가비지 컬렉션이 발생할 때 앱이 일시적으로 멈추는 'Stop-the-world' 현상이 나타나는지 그 메모리 회수 물리 구조를 입증할 수 있어야 하며, 왜 Activity가 백그라운드로 전환될 때 번들(Bundle)로 데이터를 저장하지 않으면 시스템에 의해 데이터가 물리적으로 소멸되는지 그 프로세스 관리 논리를 논증해야 합니다.

4. Prerequisites

  • Object-Oriented Programming (Basic): Java/Kotlin의 클래스 모델 및 인터페이스 수리 구조 이해가 필수입니다. (05. PLC)
  • Computer Architecture (Recommended): 프로세스 제어 블록(PCB) 및 메모리 가상화 기초 이해가 권합됩니다. (02. CAES)

5. Learning Map

  1. Execution Engine: DEX 파일이 ART 위에서 기계어로 변환되는 런타임 물리력을 이해합니다.
  2. Memory Stewardship: GC가 어떻게 파편화된 메모리를 정리하고 누수를 차단하는지 배웁니다.
  3. State & Life Dynamics: 운영체제가 앱의 상태에 따라 자원을 강제 회수하거나 복구하는 시퀀스를 익힙니다.
  4. Declarative Rendering: 최신 UI 프레임워크가 변경된 데이터만 정확히 다시 그리는 수리 연산을 탐구합니다.

Basic

Core: ART 런타임과 실행 시퀀스 (Android Execution)

  • Why to Learn: 앱의 실행 성능과 패키지 크기가 어떻게 결정되는지 물리적 원리를 파악하기 위함입니다.
  • What to Learn:
    • DEX(Dalvik Executable) Mechanics: 클래스 로딩 및 바이트코드 실행 물리
    • Hybrid Compilation Physics: AOT(Ahead-of-Time) vs JIT(Just-in-Time)의 수치적 조화
    • Zygote Process Dynamics: 앱 실행 속도를 높이기 위한 프로세스 복제 원리
  • How to Learn:
    • adb shell 명령어를 통해 실행 중인 프로세스의 VM 상태와 DEX 최적화 수준 확인 실습
    • 간단한 코드가 바이트코드로 변환된 후 기계어로 해석되는 과정을 프로파일러로 추적
  • Implement: 런타임 최적화 여부에 따른 앱 초기 구동 속도 수리 분석 리포트

Core: 가비지 컬렉션과 메모리 시스템 (GC & Memory)

  • Why to Learn: 메모리 부족(OOM)으로 인한 강제 종료를 막고 가용 자원을 극대화하기 위해서입니다.
  • What to Learn:
    • GC Roots Dynamics: 메모리 회수 대상에서 제외되는 참조의 물리적 기점
    • Heap Segment Analytics: Young, Old 영역의 자원 이동 논리 및 물리
    • Context Leak Physics: Activity 파괴 후에도 메모리에 남는 참조의 수리적 위험성
  • How to Learn:
    • LeakCanary를 연동하여 메모리 누수를 발생시키고 힙 덤프(Heap Dump)를 분석하는 훈련
    • 의도적으로 메모리를 점유하여 GC가 빈번하게 발생하는 'GC Thrashing' 현상 관찰
  • Implement: 메모리 누수가 물리적으로 제거된 견고한 싱글톤(Singleton) 연동 아키텍처

Practical

Core: 컴포넌트 생명 주기와 프로세스 복구 (Lifecycle Dynamics)

  • Why to Learn: 사용자가 앱을 나갔다 돌아왔을 때 데이터가 소실되지 않는 '연속적 경험'을 보장하기 위함입니다.
  • What to Learn:
    • Lifecycle States Physics: Resumed, Paused, Stopped의 물리적 상태 전이
    • Memory Priority Mechanics: LRU 캐시에 따른 시스템의 강압적 프로세스 종료 논리
    • SavedState Persistence: 시스템이 프로세스를 죽여도 수치를 보존하는 복구 물리
  • How to Learn:
    • 설정에서 '활동 보존 안 함'을 켜고 시스템에 의한 Activity 소멸 시 복구 로직 수리 검증
    • Foreground Service 전환 유무에 따른 CPU 할당량 변화를 물리적으로 트래킹
  • Implement: 프로세스 종료 상황에서도 입력 데이터가 100% 미러링되는 복구 가능한 앱 엔진

Advanced

Core: Jetpack Compose 재구성과 성능 (Compose Mechanics)

  • Why to Learn: 데이터를 변경했을 때 화면 전체가 아닌 필요한 부분만 물리적으로 다시 그리게 최적화하기 위해서입니다.
  • What to Learn:
    • UI Tree Diffing: 변경된 UI 노드만 추출하여 렌더링하는 수리적 시퀀스
    • Smart Recomposition: Skipping과 Remember의 메모리 보관 및 수치 비교 논리
    • Side-effect Isolation: 무거운 연산의 물리적 격리와 안정성(Stability) 주석 활용
  • How to Learn:
    • Compose Layout Inspector를 활용해 불필요한 재구성이 발생하는 수리적 지점 발견
    • 애니메이션 구동 시 프레임이 떨어지는 구간을 찾아 상태 구독 범위를 좁히는 최적화 실습
  • Implement: 수만 개의 리스트에서도 지연(Jank) 없이 부드러운 고성능 Compose UI

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core/misused/legacy)
ART 안드로이드 앱의 런타임 엔진으로, 바이트코드를 기계어로 컴파일하고 실행하는 물리적 주체입니다. 기본 실행 환경 VM / DEX Dalvik 단순 소프트웨어 아님 P1:CS2023 core
Garbage Collection 더 이상 참조되지 않는 객체를 식별하여 메모리를 물리적으로 회수하는 자동화 메커니즘입니다. 추천 자원 관리 Heap / Leaks MRC 수동으로만 되는 줄 오해 P1:CS2023 core
Recomposition 상태(State)가 변할 때 함수를 다시 실행하여 UI 트리를 물리적으로 갱신하는 연산 과정입니다. 실무 인터페이스 Diffing / Render Update 전체 화면 갱신 아님 Industry core
Context 시스템의 현재 앱 상태와 자원에 접근하기 위한 인터페이스이자 생명 주기의 물리적 핸들입니다. 기본 시스템 통로 Application / Activity Handle 단순히 데이터 아님 Industry core

8. References

Primary References

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)'이지 않은 파라미터가 왜 과도한 재구성을 유발하는지 물리적 원인을 파악했는가?

Concepts & Tags

#android-internals#art-runtime#gc-mechanics#jetpack-compose#rendering-pipeline