시작 지연 시간 개선
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
시작 지연 시간은 일일 활성 사용자를 유지하고 첫 번째 상호작용부터 매끄러운 사용자 경험을 보장하는 데 중요한 측정항목입니다. 성능 절충이 고려될 수 있는 RAM이 부족한 환경에서는 특히 더 그렇습니다.
하지만 앱 시작 개선에 착수하기 전에 먼저 시작 자체에 기여하는 근본적인 요인들을 이해하는 것이 중요합니다.
권장사항
기준 프로필과 함께 배송
기준 프로필을 사용하면 포함된 코드 경로의 해석과 JIT(just-in-time) 컴파일 단계를 피하여 최초 실행 후 코드 실행 속도가 약 30% 향상됩니다. 앱에 기준 프로필을 제공하면 Android 런타임(ART)이 AOT(Ahead-Of-Time) 컴파일을 통해 포함된 코드 경로를 최적화하여 모든 신규 사용자와 앱 업데이트에 향상된 성능을 제공합니다.
이른 초기화 피하기
앱의 시작 시퀀스에서 필요하지 않은 이른 작업을 피합니다.
앱이 프로세스를 시작하는 가장 일반적인 시나리오는 앱의 실행을 통하는 것이지만, WorkManager, JobScheduler, BroadcastReceiver, 바인드된 서비스, AndroidX 시작 라이브러리도 백그라운드에서 앱 프로세스를 시작할 수 있습니다. 가능한 경우 불필요하게 Application 클래스의 항목을 이르게 초기화하지 마세요. 많은 라이브러리가 주문형 초기화를 제공하므로 필요할 때만 호출할 수 있습니다.
UI 스레드에서 백그라운드 스레드로 태스크 이동
시간이 오래 걸리며 기본 스레드를 차단하는 태스크가 있으면 백그라운드 스레드로 이동하거나 WorkManager를 사용하여 효율을 높입니다.
오랜 시간을 차지하거나 예상보다 많은 시간을 소비하는 작업을 식별합니다. 이러한 태스크를 최적화하면 시작 지연 시간을 크게 개선할 수 있습니다.
심각한 디스크 읽기 경합 분석 및 수정
StrictMode는 UI 작업이 수신되고 애니메이션이 실행되는 앱의 기본 스레드에서 우발적인 디스크 또는 네트워크 액세스의 사용을 감지하는 데 도움이 되는 개발자 도구입니다. StrictMode가 개선 가능 영역을 감지하면 개발자는 앱을 자동으로 종료하거나 추가 조사를 위해 위반을 로깅할 수 있습니다.
동기 IPC 피하기
Android의 프로세스 간 통신(IPC) 메커니즘인 바인더 호출로 인해 앱 실행이 오랫동안 일시중지되는 경우가 있습니다. 최신 버전의 Android에서는 이것이 UI 스레드의 실행이 중지되는 가장 일반적인 이유 중 하나입니다. 일반적으로 해결 방법은 바인더 호출을 실행하는 함수를 호출하지 않는 것입니다. 불가피하게 호출해야 하는 경우 값을 캐시하거나 작업을 백그라운드 스레드로 이동해야 합니다. 자세한 내용은 스레드 예약 지연을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Improve startup latency\n\nStartup latency is an important metric to retain daily active users and ensure\na seamless user experience from the first interaction. This is especially true\nin low-RAM environments where performance tradeoffs might be considered.\nHowever, before beginning to improve app startup, it's important to understand\nthe underlying aspects that contribute to startup itself.\n\nBest practices\n--------------\n\n### Ship with a Baseline Profile\n\nBaseline Profiles improve code execution speed by around 30% from the first\nlaunch by avoiding interpretation and\n[just-in-time (JIT)](/about/versions/nougat/android-7.0#jit_aot) compilation\nsteps for included code paths. By shipping a Baseline Profile in an app,\n[Android Runtime (ART)](https://source.android.com/docs/core/runtime)\ncan optimize included code paths through Ahead of Time (AOT) compilation,\nproviding performance enhancements for every new user and on every app update.\n\n### Avoid eager initialization\n\nAvoid doing eager work that may not be necessary in your app's startup sequence.\nThe most likely scenario for your app starting a process is through the\nlaunching of the app. However,\n[WorkManager](/reference/androidx/work/WorkManager),\n[JobScheduler](/reference/android/app/job/JobScheduler),\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver), bound\nservices, and the [AndroidX startup library](/topic/libraries/app-startup)\ncan also start app processes in the background. If possible, avoid unnecessarily\ninitializing anything eagerly in your `Application` class. A lot of libraries\noffer on-demand initialization, which lets you invoke them only when necessary.\n\n### Move tasks from UI thread to background thread\n\nIf there are tasks that are taking longer and blocking the main thread, move\nthem to a background thread or use WorkManager to ensure efficiency.\nIdentify operations that occupy large time frames or consume more time\nthan expected. Optimizing these tasks can help drastically improve startup\nlatency.\n\n### Analyze and fix severe disk read contention\n\n[StrictMode](/reference/android/os/StrictMode) is a developer tool that can\nhelp detect the use of accidental disk or network access on the app's main\nthread, where UI operations are received and animations take place. Once the\ntool detects a possible area of improvement, you can automatically terminate\nthe app or log the violation for further inspection at a later time.\n\n### Avoid synchronous IPCs\n\nOften long pauses in your app's execution are caused by binder calls,\nthe inter-process communication (IPC) mechanism on Android. On recent versions\nof Android, it's one of the most common reasons for the UI Thread to stop\nrunning. Generally, the fix is to avoid calling functions that make binder\ncalls; if it's unavoidable, you should cache the value, or move work to\nbackground threads. For more information, see\n[Thread scheduling delays](/topic/performance/vitals/render#thread_scheduling_delays)."]]
