작성하는 코드 자체가 메모리 사용의 한 형태입니다. 애플리케이션의 모든 클래스, 메서드, 문자열 상수는 실행될 때 RAM에 로드되어야 합니다. 애플리케이션의 코드베이스가 클수록 존재하기 위해 소비하는 메모리가 많아집니다.
파일 지원 메모리 및 요구 페이징
Android는 mmap를 사용하여 .apk (예: .oat 또는 .so 파일)에서 실행 코드를 로드합니다. 즉, 코드가 파일 지원됩니다.
중요한 점은 Android가 요구 페이징을 사용한다는 것입니다. 앱이 시작되면 커널은 전체 APK를 RAM에 즉시 로드하지 않습니다. 대신 파일이 프로세스의 가상 주소 공간에만 매핑됩니다. 앱이 실행되고 CPU가 새 함수로 이동하면 '페이지 오류'가 트리거됩니다. 커널은 스레드를 일시중지하고, 저장소에서 해당 특정 4KB 코드 페이지를 실제 RAM으로 읽고, 실행을 재개합니다.
즉, 패키징하지만 실행하지 않는 코드는 코드 페이지 자체에 실제 메모리를 사용하지 않습니다. 하지만 사용하지 않는 라이브러리는 전체 APK 크기를 늘리고 코드가 존재한다는 것을 알기 위해서도 읽어야 하는 시스템의 내부 메타데이터 (예: DEX 색인 및 클래스 설명자)에서 사용하는 메모리를 크게 늘릴 수 있습니다. 또한 많은 라이브러리에는 정적 이니셜라이저가 포함되어 있거나 앱 시작 중에 종속 항목 삽입 프레임워크에 의해 터치되므로 어쨌든 RAM으로 페이징됩니다.
페이지 삭제 및 속도 저하
파일 지원 메모리는 항상 저장소에서 다시 읽을 수 있으므로 커널은 이러한 페이지를 '클린'으로 간주합니다. 시스템에 메모리 압력이 발생하면 커널은 다른 항목을 위한 공간을 확보하기 위해 RAM에서 이러한 클린 코드 페이지를 삭제합니다.
나중에 앱에서 해당 코드를 다시 실행해야 하는 경우 CPU에 오류가 발생하고 커널은 저장소에서 페이지를 다시 읽어야 합니다. 앱에 코드가 많을수록 코드 삭제에 더 취약해집니다. 사용자가 다른 앱을 사용한 후 과도한 앱으로 돌아오면 CPU가 저장소에서 코드가 다시 페이징되기를 기다리면서 계속 멈추기 때문에 임의의 버벅거림과 속도 저하가 발생합니다.
페이지 오류 비용: 기기의 저장소 속도 (UFS와 eMMC)와 커널 상태에 따라 크게 다르지만, 주요 페이지 오류 (저장소에서 4KB 읽기)는 0.5ms에서 5ms 사이의 비용이 들 수 있습니다. 시작 경로가 최적화되지 않은 코드의 500개 페이지를 터치하면 앱 시작 시간에 순수한 I/O 지연 시간을 수백 밀리초 쉽게 도입할 수 있습니다.
컴파일러 탐색기로 코드 크기 살펴보기
Java 또는 Kotlin 코드가 네이티브 머신 코드 (따라서 메모리 바이트)로 변환되는 방식을 직관적으로 파악하려면 컴파일러 탐색기를 사용하면 됩니다.
Android 지원은 Godbolt에 직접 내장되어 있습니다. 이를 통해 Android 도구 모음 (D8, R8, dex2oat)의 여러 부분이 소스 코드를 어떻게 변환하는지 확인할 수 있습니다.
Android에서 Compiler Explorer를 사용하는 방법
- godbolt.org로 이동합니다.
- 언어 드롭다운(왼쪽 상단)에서 Android Java 또는 Android Kotlin을 선택합니다.
- 컴파일러 드롭다운 (코드 창 오른쪽 상단)에서 다음 도구 중 하나를 선택할 수 있습니다.
d8: Dalvik 바이트 코드 (.dex)를 표시합니다. 이는 원본 코드에 가장 가까운 표현이며 읽기 쉽습니다.r8: R8 옵티마이저가 바이트 코드를 축소하고 최적화하는 방법을 보여줍니다.dex2oat: 기기에서 실제로 실행되는 최종 ARM64 머신 코드를 표시합니다. 여기에서 실제 메모리 영향(명령어당 4바이트)을 확인할 수 있습니다.dex2oat는 다양한 ISA를 타겟팅할 수 있지만 ARM64가 휴대전화에서 가장 일반적입니다.
- 소스<>출력 강조 표시: 코드 줄 위로 마우스를 가져가면 해당 바이트 코드 또는 기계어 코드 명령어가 강조 표시되어 특정 문의 영향을 쉽게 추적할 수 있습니다.
- 최적화 파이프라인: 분해 뷰에서 새 항목 추가...를 클릭할 수 있습니다. -> Opt Pipeline 이를 통해 컴파일러가 수행하는 내부 단계를 확인할 수 있습니다. 최종 ARM64 머신 코드로 낮아지기 전에 각 단계 (예: '인라이너 (전)'와 '인라이너 (후)' 단계 사이)에서 내부 표현(IR)이 어떻게 변환되는지 검사할 수 있습니다.
메모리에 중요한 이유
ARM64 ISA를 타겟팅하는 dex2oat 출력에 표시되는 모든 명령어는 앱의 실행 파일 (.odex 또는 .oat)에서 4바이트를 차지합니다.
다양한 언어 기능을 활용하는 코드를 입력하고 컴파일러의 출력을 연구해 보세요.
- 배열 액세스 vs. 목록 반복자:
int[]에 대한 간단한 배열 루프는 약 10개의 명령어(약 40바이트)로 컴파일될 수 있습니다.List에 대한 foreach 루프는Iterator를 암시적으로 사용합니다. 이로 인해 추가 메서드 호출 (hasNext(),next())과 반복기 객체 자체의 할당으로 인해 30~40개의 명령어 (~160바이트)가 발생할 수 있습니다.- R8 최적화: 적절한 조건 (예:
List가ArrayList인 것으로 증명된 경우)에서 R8 옵티마이저는 foreach 루프를 간단한 색인 루프로 다시 변환하여 반복기 오버헤드를 없애고 코드 크기와 런타임 메모리 급변을 모두 줄일 수 있습니다.
- 가상 메서드 호출: 객체의 클래스를 로드하고
vtable에서 메서드를 찾은 다음 분기하는 작업이 포함됩니다. 일반적으로 4~5개의 명령어 (~20바이트)가 필요합니다. - 직접/정적 호출: 단일
bl(링크가 있는 분기) 명령어 (4바이트)로 변환되는 경우가 많습니다. - Kotlin 람다: 전체 익명 클래스와 추가 브리지 메서드를 생성하여 간단한 기능 블록에 수백 바이트의 코드와 메타데이터 오버헤드를 추가할 수 있습니다.
컴파일러 탐색기를 사용하면 정교한 언어 기능(예: Kotlin 람다, 스트림 API, 제네릭의 과도한 사용)이 애플리케이션의 최종 컴파일된 크기에 어떤 영향을 미치는지, R8과 같은 최적화 프로그램이 경우에 따라 언어 추상화 비용을 어떻게 상쇄할 수 있는지 확인할 수 있습니다. 이 도구를 사용하면 앱을 설계하고 구현할 때 정보에 입각한 절충안을 마련할 수 있습니다.
일반적으로 앱 코드의 복잡성이 높을수록 메모리 사용량이 많아집니다. 반대로 더 간단한 코드 또는 R8로 간소화된 코드는 CPU 명령어와 저장소 및 RAM의 바이트로 더 작게 표현됩니다.
meminfo 및 showmap를 사용한 코드 영향 측정
표준 Android 메모리 도구를 사용하여 앱의 코드가 소비하는 메모리 양을 확인할 수 있습니다.
dumpsys meminfo
adb shell dumpsys meminfo <package>를 실행하면 앱 요약 섹션의 코드 카테고리에 코드 관련 메모리가 개략적으로 표시됩니다.
App Summary
Pss(KB)
------
Java Heap: 3244
Native Heap: 5412
Code: 24512 # <--- Sum of .so, .dex, .oat, .art, etc.
showmap
더 상세한 보기를 보려면 showmap를 사용하세요. 메모리에 매핑되는 특정 파일의 영역을 표시합니다.
adb shell showmap $(pidof <package>) | grep -E "\.oat|\.odex|\.dex|\.apk"
애플리케이션의 컴파일된 코드 항목이 표시됩니다.
size RSS PSS clean dirty clean dirty swap swapPSS object
------- -------- -------- -------- -------- -------- -------- -------- -------- ----------------
12288 8192 8192 8192 0 0 0 0 0 /data/app/.../base.odex
데드 코드 및 R8
실행된 모든 메서드는 메모리를 차지하므로 불필요한 초기화나 사용하지 않는 라이브러리가 있는 '블로트' 앱은 시작 성능과 기준 메모리 사용량에 심각한 영향을 미칠 수 있습니다.
이러한 이유로 R8 (ProGuard)과 같은 도구가 중요합니다. R8은 애플리케이션의 바이트 코드를 분석하고 호출되지 않는 클래스나 메서드를 삭제합니다 ('데드 코드 삭제').
실습: 블로트의 비용
코드 크기의 영향을 보여주기 위해 생성된 클래스가 300개 (각각 메서드 500개 포함)인 애플리케이션의 두 빌드를 비교하는 실험을 고려해 보세요.
- CodeBloat (최적화되지 않음): 생성된 모든 클래스와 고유한 문자열을 포함하는 표준의 최적화되지 않은 빌드입니다.
- CodeBloatOptimized: 동일한 소스 코드이지만 R8 축소가 사용 설정된 상태로 컴파일됩니다.
1. AOT(Ahead-of-time) 컴파일
파일 지원 메모리 영향을 극대화하기 위해 cmd package compile 도구를 사용하여 앱을 사전 (AOT) 컴파일하여 .oat 파일로 만듭니다.
adb shell cmd package compile -m speed -f com.android.codebloat
adb shell cmd package compile -m speed -f com.android.codebloat.optimized
합성된 예시입니다. 일반적으로 앱은 speed-profile 컴파일 모드를 사용합니다 (아래 참고).
2. 실행 및 비교
시스템이 저장소에서 코드를 읽어야 하는 완전한 콜드 시작을 확인하기 위해 각 앱을 실행하기 전에 커널의 페이지 캐시를 삭제합니다. 이렇게 하려면 루트 액세스가 필요합니다.
최적화되지 않은 앱을 실행합니다.
adb shell am force-stop com.android.codebloat
# Drop page cache to ensure the start is truly cold
adb shell "echo 3 > /proc/sys/vm/drop_caches"
adb shell am start -W -n com.android.codebloat/.MainActivity
sleep 5 # Wait for the background thread to load classes
adb shell dumpsys meminfo -s com.android.codebloat
이제 최적화된 앱에 대해서도 동일한 작업을 실행합니다.
adb shell am force-stop com.android.codebloat.optimized
# Drop page cache to ensure the start is truly cold
adb shell "echo 3 > /proc/sys/vm/drop_caches"
adb shell am start -W -n com.android.codebloat.optimized/com.android.codebloat.MainActivity
sleep 5
adb shell dumpsys meminfo -s com.android.codebloat.optimized
결과
App Summary 섹션의 코드 행을 살펴보면 큰 차이가 있습니다.
- 최적화되지 않은
Code: ~30,000KB (30MB) - 최적화됨
Code: ~2,000KB (2MB)
R8은 이러한 클래스 내의 500개 메서드가 실제로 유용한 작업을 수행하지 않는다고 판단했기 때문에 (doSomething() 메서드는 method0()만 호출하고 결과는 무시됨) 최종 APK에서 인위적으로 생성된 코드를 거의 모두 삭제했습니다.
3. Perfetto에서 영향 확인
코드 블로트의 영향은 애플리케이션의 초기 로드 단계에서 명확하게 표시됩니다. 특히 메인 스레드에서 bindApplication 슬라이스와 madvising로 시작하는 중첩된 슬라이드를 찾아보세요. 이는 시스템이 APK와 컴파일된 코드 (.odex)에서 파일을 로드할 준비를 하고 있음을 나타냅니다.
대화형 콜드 스타트에서 시스템은 앱이 로드되고 실행되는 데 필요한 이러한 파일의 mmap() 및 madvise() 코드와 기타 데이터를 로드합니다. madvising 슬라이스의 'size=' 뒤에 나오는 값은 로드해야 하는 데이터의 양을 나타냅니다. 앱의 코드를 미리 가져오는 것은 앱 시작을 가속화하기 위해서입니다.
비교를 통해 스토리지에서 RAM으로 로드해야 하는 앱 코드의 양이 부풀려진 앱의 경우 훨씬 많았음을 알 수 있으며, 이로 인해 앱 시작이 느려지는 데 기여하는 기간이 길어졌습니다. 또한 과도한 앱의 시작 트레이스에는 과도한 앱이 하나의 DEX 파일에 맞지 않아 '유출'해야 했던 보조 DEX 파일(classes2.dex, classes3.dex) 로드 슬라이스가 표시됩니다.
비교 (Pixel 10a의 콜드 스타트)
| 측정항목 | 최적화되지 않음 (코드 블로트) | 최적화됨 (CodeBloatOptimized) |
|---|---|---|
base.odex madvise 크기 |
약 7.9MB (2.0ms) | ~16 KB (0.003 ms) |
base.apk madvise 크기 |
약 2.4MB (2.4ms) | ~4 KB (0.001 ms) |
classes2.dex madvise 크기 |
~7.3 MB (8.6 ms) | 해당 사항 없음 |
classes3.dex madvise 크기 |
~7.3 MB (8.0 ms) | 해당 사항 없음 |
총 madvising 기간 |
~21 ms | ~0.004 ms |
최적화되지 않은 앱 로드 성능
최적화된 앱 로드 성능
코드 블로트의 영향은 앱 크기, 사용자 기기의 특성, 시스템 부하에 따라 다릅니다.
분석 로드를 위한 PerfettoSQL
다음 쿼리를 사용하여 트레이스에서 이러한 측정항목을 추출할 수 있습니다.
1. 앱 시작 기간
앱의 활동이 실행된 시점부터 활동이 첫 번째 프레임을 그릴 때까지의 시간을 보여줍니다.
INCLUDE PERFETTO MODULE android.startup.startups;
SELECT package, dur, startup_type
FROM android_startups
WHERE package LIKE 'com.android.codebloat%';
다양한 앱 시작 상태 이해를 참고하세요.
앱의 시작 시간은 이 가이드에서 다루는 요인 외에도 여러 요인에 민감합니다.
2. madvising 크기 및 기간 추출
이 쿼리는 위에서 본 madvising 부분을 확대합니다.
INCLUDE PERFETTO MODULE slices.with_context;
SELECT
name,
dur/1e6 AS dur_ms
FROM thread_slice
WHERE process_name LIKE 'com.android.codebloat%'
AND name LIKE 'madvising %';
3. 기본 스레드 상태 분류 (상태별 총 기간)
이 쿼리는 앱의 기본 스레드가 다양한 상태에서 소비한 시간을 보여줍니다.
SELECT
p.name AS process_name,
state,
sum(dur)/1e6 AS total_dur_ms
FROM thread_state ts
JOIN thread t USING (utid)
JOIN process p USING (upid)
WHERE p.name LIKE 'com.android.codebloat%'
AND t.is_main_thread = 1
GROUP BY p.name, state;
앱의 시작 기간 동안 기본 스레드 상태만 확인하도록 쿼리를 구체화할 수 있습니다.
INCLUDE PERFETTO MODULE android.startup.startups;
SELECT
p.name AS process_name,
ts.state,
-- Calculate only the duration that falls within the startup window
SUM(
MAX(0,
MIN(ts.ts + ts.dur, s.ts + s.dur) - MAX(ts.ts, s.ts)
)
) / 1e6 AS startup_dur_ms
FROM thread_state ts
JOIN thread t USING (utid)
JOIN process p USING (upid)
-- Join on the package name to align thread states with the correct startup
JOIN android_startups s ON s.package = p.name
WHERE p.name LIKE 'com.android.codebloat%'
AND t.is_main_thread = 1
-- Only select thread states that overlap with the startup interval
AND ts.ts + ts.dur > s.ts
AND ts.ts < s.ts + s.dur
GROUP BY 1, 2
ORDER BY startup_dur_ms DESC;
이로 인해 다음과 같은 흥미로운 문제가 발생할 수 있습니다.
- 실행 가능 (R)하지만 실행되지 않는 데 소요된 시간이 많음: 이는 CPU 경합으로 인해 앱의 시작이 지연되었음을 나타냅니다. 즉, 다른 스레드 (다른 앱에서 발생했을 수 있음)가 CPU를 점유하고 있어 앱의 기본 스레드가 실행될 수 없습니다.
- 인터럽트 가능한 절전 모드에서 소요된 시간이 많음 (D): 이는 일반적으로 앱 시작을 지연시키는 느린 I/O 또는 메모리 압력을 나타냅니다.
- 절전 모드 (S)에 소요된 시간이 많음: 이는 기본 스레드가 다른 스레드가 작업을 수행하기를 기다리고 있음을 의미합니다. 이는 앱의 시작 경로에서 잠금 경합이 발생했음을 나타낼 수 있습니다. 즉, 앱의 다른 스레드가 점유한 독점 리소스에서 기본 스레드가 차단되었습니다.
4. 최대 파일 지원 메모리 (RSS 파일)
이 측정항목은 앱이 시작 시 로드하는 코드와 데이터의 양과 상관관계가 높습니다. '블로트'가 심한 앱은 여기에 더 높은 숫자가 표시되어 시스템에 메모리 압력을 가합니다. 이러한 압력으로 인해 시스템이 할당 요청을 충족하기 위해 애쓰거나 앱 시작에 집중하는 대신 시작 앱의 즉각적인 요구사항을 충족하기 위해 다른 프로세스에서 메모리를 회수하는 데 CPU 시간을 할당하므로 앱 시작이 지연될 수 있습니다.
SELECT
p.name AS process_name,
max(c.value)/1024.0/1024.0 AS max_rss_file_mb
FROM counter c
JOIN process_counter_track t ON c.track_id = t.id
JOIN process p USING (upid)
WHERE p.name LIKE 'com.android.codebloat%'
AND t.name = 'mem.rss.file'
GROUP BY p.name;
ART 컴파일 모드 및 메모리
Android 런타임 (ART)은 컴파일러 필터라고도 하는 여러 가지 모드 중 하나로 애플리케이션 코드를 컴파일할 수 있습니다. 선택한 컴파일러 필터는 앱의 메모리 사용 공간에 직접적인 영향을 미칩니다.
verify: ART는 바이트 코드 확인만 실행합니다. AOT 컴파일이 실행되지 않습니다. 코드는 인터프리터를 통해 실행되거나 런타임에 JIT 컴파일러에 의해 컴파일됩니다.- 메모리 영향: 디스크의 크기가 가장 작습니다. 네이티브 코드 메모리 사용량이
JIT Cache(익명 더티 메모리)로 푸시됩니다.
- 메모리 영향: 디스크의 크기가 가장 작습니다. 네이티브 코드 메모리 사용량이
speed: ART가 모든 메서드의 전체 AOT 컴파일을 실행합니다.- 메모리 영향: 가장 큰
.odex크기입니다. 파일 지원 (정리) 메모리 사용량을 최대화합니다.
- 메모리 영향: 가장 큰
speed-profile: ART는 JIT 프로필에서 '핫'으로 표시된 메서드만 컴파일합니다.- 메모리 영향: 균형 잡힌 접근 방식 가장 중요한 코드만 AOT 컴파일됩니다.
가장 일반적인 필터는 speed-profile이며, 이는 사용자 앱을 설치할 때 사용됩니다. 이는 시스템 속성 pm.dexopt.install 및 pm.dexopt.bg-dexopt에서 구성되며 일반적으로 build/make/target/product/runtime_libart.mk에서 설정됩니다.
일부 시스템 앱은 speed 컴파일을 사용하며 시스템 이미지 빌드 시간에도 컴파일됩니다. verify는 일반적으로 개발 사용 사례에서만 사용됩니다.
| 사용 사례 | 일반적인 컴파일러 필터 |
|---|---|
| 개발 | verify |
| 시스템 이미지 | speed |
| 사용자 앱 | speed-profile |
실습: 컴파일 모드 및 메모리
CodeBloat 앱을 사용하여 이러한 필터가 메모리에 미치는 영향을 확인할 수 있습니다. 이러한 측정을 재현하려면 다음을 수행하세요.
- 앱을 타겟 모드로 강제 재컴파일합니다.
- 앱을 강제 종료하고 콜드 스타트합니다.
- 백그라운드 스레드가 클래스 터치를 완료할 때까지 기다립니다 (logcat을 확인하거나 5초 동안 기다림).
adb shell dumpsys meminfo com.android.codebloat을 실행합니다.
모드: verify (AOT 없음)
adb shell cmd package compile -m verify -f com.android.codebloat
adb shell am force-stop com.android.codebloat
adb shell am start -W -n com.android.codebloat/.MainActivity
sleep 5
adb shell dumpsys meminfo com.android.codebloat
verify 모드에서 앱 요약에는 다음이 표시됩니다. * 코드 PSS: ~8,000KB * Dalvik 기타 (JIT): ~25,000KB
AOT로 컴파일된 코드가 없으므로 런타임은 자주 사용되는 메서드를 JIT 캐시로 JIT 컴파일해야 하며 이는 더티 익명 메모리 (Dalvik
Other)로 표시됩니다.
모드: speed (전체 AOT)
adb shell cmd package compile -m speed -f com.android.codebloat
adb shell am force-stop com.android.codebloat
adb shell am start -W -n com.android.codebloat/.MainActivity
sleep 5
adb shell dumpsys meminfo com.android.codebloat
speed 모드에서는 결과가 크게 달라집니다. * 코드 PSS: 약 24,000KB *
Dalvik 기타 (JIT): 약 5,000KB
이제 애플리케이션의 코드가 .odex 파일에서 클린 파일 지원 메모리로 매핑됩니다. 이렇게 하면 JIT 캐시에 대한 압력이 줄어들고 메모리가 더티 RAM으로 '고정'되지 않고 압력 하에서 제거될 수 있습니다.
모드: speed-profile (선택적 AOT)
최신 앱은 baseline.prof 기준 프로필을 번들로 묶을 수 있습니다. ART는 이를 사용하여 빠르고 메모리 효율적인 시작에 필요한 코드만 선택적으로 컴파일합니다.
이 연습에서는 앱의 시작 클래스를 나열하는 기준 프로필을 만듭니다. 하지만 실제로 컴파일러는 애플리케이션 스토어 ('클라우드 프로필')와 같은 외부 소스에서 프로필을 수신할 수도 있습니다. 이를 통해 개발자가 생성한 기준 프로필을 번들로 묶었는지와 관계없이 앱의 크라우드소싱 JIT 프로필을 제공할 수 있습니다.
온디바이스 프로필 생성 및 사용
speed-profile의 영향을 확인하려면 기기에서 자체 프로필을 생성하면 됩니다.
재설정 및 시작:
adb shell am force-stop com.android.codebloat상호작용: 앱을 시작하고 시작 시퀀스를 실행합니다.
덤프 프로필:
adb shell kill -s SIGUSR1 $(pidof com.android.codebloat)(이렇게 하면 앱이 현재 프로필을 디스크에 쓰게 됩니다.)
프로필 설치:
adb shell cp /data/misc/profiles/cur/0/com.android.codebloat/primary.prof \ /data/misc/profiles/ref/com.android.codebloat/primary.prof컴파일:
adb shell cmd package compile -m speed-profile -f com.android.codebloat
다시 실행하면 코드 PSS가 speed보다 낮게 표시됩니다 (예: ~16,000KB). '핫' 시작 메서드만 컴파일되었기 때문입니다. 나머지는 실제로 사용되는 경우에만 인터프리터나 JIT에서 처리합니다.
다음과 같이 표시됩니다.
컴파일된 코드 자세히 알아보기
ART에서 생성하는 명령어를 정확히 확인하려면 art/DISASSEMBLY_GUIDE.md를 참고하세요.
다음 사용에 관한 자세한 안내를 제공합니다.
oatdump: 기존.odex파일 내에서 ARM64 명령어를 확인합니다.dex2oat: 자세한 디버그 플래그를 사용하여 컴파일을 시뮬레이션합니다.
연습: 코드 인라이닝
컴파일된 코드가 예기치 않게 커지는 한 가지 이유는 메서드 인라이닝입니다. 컴파일러는 자주 호출되는 작은 메서드의 본문을 호출자에 직접 복사할 수 있습니다.
CodeBloat 앱에서 생성된 모든 클래스의 doSomething() 메서드는 method0()를 호출하기만 합니다. speed 모드로 컴파일하면 ART의 최적화 컴파일러가 method0()을 doSomething()에 인라인할 가능성이 높습니다.
실습: 기기에서 oatdump를 사용하여 다음을 확인하세요.
# 1. Find the path to the application's APK and compiled .odex file
adb shell pm path com.android.codebloat
# Output: package:/data/app/~~.../base.apk
adb shell "dumpsys package com.android.codebloat | grep 'location is' | head -n 1"
# Example output: [location is /data/app/~~.../oat/arm64/base.odex]
# 2. Run oatdump (substituting the correct path to base.odex)
adb shell oatdump --oat-file=/data/app/~~.../oat/arm64/base.odex \
--class-filter=com.android.codebloat.GeneratedClass0
출력에서 doSomething 메서드를 찾습니다. 인라인 처리된 경우 method0를 타겟팅하는 bl 명령어가 아닌 doSomething 내에서 긴 문자열 상수를 직접 로드하는 명령어가 표시됩니다.
최적화 시각화 (CFG)
컴파일러가 메서드를 인라인하기로 결정한 시점을 정확하게 확인하려면 제어 흐름 그래프 (CFG)를 생성하면 됩니다. 이는 최적화 파이프라인의 모든 단계에서 코드의 상태를 보여주며, 코드가 타겟 ISA (예: ARM64)로 낮아질 때까지 컴파일러의 중간 표현(IR)에 대한 모든 변환을 보여줍니다.
덤프 플래그로
dex2oat실행:--verbose-methods플래그를 사용하여 출력을 특정 메서드로 제한합니다. 그렇지 않으면 대형 앱의.cfg파일이 수 기가바이트로 커질 수 있습니다.# Substitution of actual paths required: adb shell dex2oat64 --dex-file=/data/app/~~.../base.apk \ --oat-file=/data/local/tmp/dump.odex \ --compiler-filter=speed \ --dump-cfg=/data/local/tmp/codebloat.cfg \ --verbose-methods=doSomething풀 및 보기:
.cfg파일을 워크스테이션으로 가져와 IR Hydra로 엽니다.인라이너 찾기: IR Hydra에서 컴파일 아티팩트를 로드하고
doSomething를 검색합니다. 인라이너 패스 전후의 표현을 비교합니다.method0의 명령어가 호출자에 병합되면 그래프가 확장됩니다.
또는 위의 섹션에 설명된 대로 컴파일러 탐색기에서 파이프라인 선택 도구를 사용하고 유사한 코드를 입력하여 인라이너 패스에서 유사한 변환이 실행되는지 확인합니다.
연습: volatile 필드 및 메모리 장벽
MemoryLab 앱에서 mGarbageSink 필드는 volatile로 표시됩니다. 이렇게 하면 컴파일러가 가비지 할당을 최적화하지 않습니다.
public volatile byte[] mGarbageSink;
ARM64 디스어셈블리에서 이 필드로의 모든 저장에는 메모리 장벽 (dmb ish)이 수반되거나 로드-획득/저장-해제 명령어 (ldar/stlr)가 사용됩니다. 이렇게 하면 스레드 가시성이 보장되지만 모든 액세스에 몇 가지 추가 명령어가 추가되어 일반 필드에 비해 코드 크기가 약간 증가합니다.
연습: 디스어셈블리에서 필드 액세스와 연결된 메모리 장벽을 찾습니다.
연습: 암시적 정지 확인
generateAllocationChurn의 루프와 같이 루프를 분해하면 루프 본문 끝에 이상한 명령어가 표시됩니다.
ldr x21, [x21]
이는 암시적 정지 확인입니다. ART는 이를 사용하여 가비지 수집기가 스레드를 안전하게 일시중지하도록 허용합니다. 등록 x21는 일반적으로 자체를 가리킵니다.
GC가 스레드를 정지해야 하는 경우 해당 메모리 위치를 '포이즌'합니다. 스레드가 다음에 ldr를 실행하면 오류가 트리거되고, 런타임이 이를 포착하여 스레드를 정지된 상태로 전환합니다.
이 패턴은 모든 루프와 모든 메서드의 시작 부분에서 반복되어 애플리케이션의 총 코드 크기에 영향을 미칩니다.
연습: 메서드 디스어셈블리에서 모든 암시적 중단 검사를 찾아 원래 소스 코드와 연관시켜 보세요.