Android(Go 버전) 최적화
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android(Go 버전)의 사용자층이 빠르게 늘고 있습니다. 이에 따라 RAM이 부족한 기기에서 기존 애플리케이션이 제대로 작동하도록 최적화해야 할 필요성이 커지고 있습니다.
이러한 유형의 개발과 관련된 가장 일반적인 문제로 일부 앱 기능을 제한하고, 시작 시간을 개선하고, 앱의 메모리 제약을 처리하는 것입니다. 바로 이 지점에서 Android(Go 버전)에 앱을 최적화하는 것이 도움이 될 수 있습니다.
접근 방법
앱 최적화를 시작하기에 앞서 아래 단계를 따르세요. 이 가이드는 개선의 여지가 있는 영역을 식별하고 알아낸 내용을 해결할 방법을 파악하는 데 도움이 됩니다.
| 단계 |
설명 |
| 정의 |
최적화 작업을 시작하기 전에 앱의 개선 영역과 관련된 목표 핵심성과지표(KPI)를 정의하는 것이 중요합니다. 일반적인 개선 영역으로 앱 시작 지연 시간, 앱 비정상 종료 발생률, 애플리케이션 응답 없음(ANR)을 들 수 있습니다.
이러한 KPI를 정의했으면 사용자 경험과 기술 복잡성 사이의 균형을 고려하며 최소 사용자 환경 및 벤치마킹이라는 측면에서 목표 기준점을 정해야 합니다.
|
| 분석 |
개선 영역을 개별 신호 측정항목으로 나누는 것이 권장됩니다. 예를 들어 앱 비정상 종료 발생률은 처리되지 않은 오류, 높은 메모리 사용량, ANR 등 비정상 종료의 원인으로 세분화할 수 있습니다. |
| 벤치마크 |
다음으로, 목표 개선 영역을 벤치마킹하여 현재 성능을 식별합니다. 목표가 충족되지 않으면 개별 분석을 검토하여 병목 현상을 식별해 봅니다.
|
| 위 과정 반복 |
특정 병목 현상을 최적화한 후에 벤치마킹 프로세스를 반복하여 잠재적인 개선을 확인합니다. 앞에서 정의한 KPI 목표가 충족되지 않는 경우 프로세스를 또다시 반복합니다.
|
| 정기적인 회귀 테스트 추가 |
원하는 빈도로 정기적인 회귀 테스트를 실행하여 KPI를 기준으로 앱의 회귀를 확인할 수 있습니다. 회귀나 버그가 코드베이스에 적용되기 전에 식별하고 차단하는 것이 효율적입니다.
KPI 목표를 업데이트하기로 결정하지 않은 한 KPI 목표를 충족하지 않는 변경사항을 게시하지 마세요.
|
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Optimize for Android (Go edition)\n\nAndroid (Go edition) has a rapidly growing user base, and with that comes the\nneed to optimize existing applications to perform well on these low-RAM devices.\nSome of the most common challenges around this type of development requires\nlimiting some app features or capabilities, improving startup time, and handling\nmemory pressure within your app. That's where optimizing your app for Android\n(Go edition) can help.\n\nApproach\n--------\n\nFollow the steps below before beginning your app optimization approach. This\nguidance helps establish a baseline for identifying potential areas for\nimprovement and how to resolve your findings.\n\n| Phases | Description |\n|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Define | Before starting any optimization effort, it's important to define Key Performance Indicators (KPIs) around areas of improvement that you're targeting for your app. Some common improvement areas include app startup latency, app crash rate, or application not responding (ANRs). \u003cbr /\u003e Once these KPIs have been defined, you should establish target thresholds from a minimum user experience and benchmarking perspective, balancing user experience and technical complexity. |\n| Breakdown | It's recommended to break these improvement areas into individual signal metrics. For example, app crash rates can be categorized granularly into reasons for the crash --- such as unhandled errors, high memory usage, or ANRs. |\n| Benchmark | Next, you can benchmark the targeted improvement area to identify current performance. If your targets aren't met, try to identify the bottlenecks by looking at individual breakdowns. |\n| Repeat the process | After optimizing certain bottlenecks, repeat the benchmarking process to view potential improvements. If your pre-defined KPI targets aren't met, then you can repeat the process for a second iteration. |\n| Add regular regression tests | Regular regression tests can run at any frequency you desire for your app to identify regressions against your KPIs. It's more efficient to identify and cut off any regressions or bugs before they make their way into your codebase. Don't publish any changes that fail your KPI goals unless you make the decision to update your KPI targets. |"]]
