배터리 수명을 위해 위치 사용 최적화
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
위치 서비스를 사용할 때 앱이 기기의 배터리 수명에 미치는 영향을 개선하려면 다음 작업을 실행하세요.
위치 업데이트 삭제
불필요한 배터리 소모가 발생하는 일반적인 원인은 필요하지 않은 시점에 위치 업데이트를 삭제하지 못하는 데 있습니다.
활동의 onStart() 또는 onResume() 수명 주기 메서드에 requestlocationUpdates() 호출이 포함되어 있지만, onPause() 또는 onStop() 수명 주기 메서드에 그에 상응하는 removeLocationUpdates() 호출이 포함되어 있지 않을 때 불필요한 배터리 소모가 발생할 수 있습니다.
수명 주기 인식 구성요소를 사용하여 앱 활동의 수명 주기를 더 효율적으로 관리할 수 있습니다. 자세한 내용은 수명 주기 인식 구성요소로 수명 주기 처리를 참고하세요.
시간 초과 설정
배터리 소모로부터 기기를 보호하려면 위치 업데이트를 중단해야 할 시점에 적절한 시간 초과를 설정합니다. 이렇게 시간 초과를 설정하면 업데이트가 무한히 계속되지 않도록 하고, (가령 코드의 버그로 인해) 업데이트를 요청했지만 삭제되지 않은 시나리오에서 앱을 보호합니다.
통합 위치 정보 제공자 요청의 경우 setDurationMillis()을 호출해서 시간 초과를 추가하여 이 메서드를 마지막으로 호출한 시점 이후부터의 시간을 밀리초 단위로 나타내는 매개변수를 수신합니다. 이 메서드를 사용하여 만료 시간을 기간으로 표현할 수도 있습니다.
지오펜싱 위치 요청에 시간 초과를 추가하려면 setExpirationDuration() 메서드를 호출합니다.
일괄 요청
포그라운드에서 실행되지 않는 모든 사용 사례는 여러 요청을 한 번에 일괄 처리합니다. setIntervalMillis() 메서드를 사용하여 위치를 계산하려는 간격을 지정합니다. 그런 다음 setMaxUpdateDelayMillis() 메서드를 사용하여 앱에 위치가 전달되는 간격을 설정합니다. setIntervalMillis() 메서드에 전달된 값의 배수인 값을 setMaxUpdateDelayMillis() 메서드에 전달합니다. 예를 들어 다음과 같은 위치 요청을 고려하세요.
Kotlin
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build()
자바
LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build();
이 경우 시스템은 약 10분마다 위치를 계산하고 약 1시간마다 약 6개의 위치 데이터 포인트를 일괄 전송합니다. 약 10분마다 위치 업데이트를 받지만 기기는 1시간 정도에 한 번씩만 활성화되므로 배터리를 아낄 수 있습니다.
수동적 위치 업데이트 사용
백그라운드 사용 사례에서는 위치 업데이트를 제한하는 것이 좋습니다. Android 8.0 (API 수준 26) 제한은 이러한 방법을 사용하지 못하게 제한하지만, 이전 기기에서 실행되는 앱은 최대한 백그라운드 위치 업데이트를 제한하려고 노력해야 합니다.
앱이 백그라운드에 있을 때는 다른 앱이 포그라운드에서 위치 업데이트를 수시로 요청할 가능성이 있습니다. 위치 서비스를 사용하면 앱에서 이러한 업데이트를 사용할 수 있습니다. 편의적으로 위치 데이터를 사용하는 다음과 같은 위치 요청을 고려해보세요.
Kotlin
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build()
자바
LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build();
이전 예에서는 앱의 위치가 약 15분마다 계산됩니다.
다른 앱이 위치를 요청하면 앱은 최대 2분 간격으로 데이터를 수신합니다.
수동적으로 위치 정보를 사용하는 데는 배터리가 소모되지 않지만 위치 데이터를 수신할 때 리소스가 많이 소모되는 CPU 또는 I/O 작업이 트리거되는 경우에는 주의해야 합니다. 배터리 비용을 최소화하려면 setMinUpdateIntervalMillis()에 지정된 간격이 너무 작아서는 안 됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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 location use for battery life\n\nTake the following actions to [improve your app's\nimpact on a device's battery life](/develop/sensors-and-location/location/battery) when using location services.\n\nRemove location updates\n-----------------------\n\nA common source of unnecessary battery drain is the failure to remove location\nupdates when they are no longer needed.\n\nThis can happen when an activity's [`onStart()`](/reference/android/app/Activity#onStart()) or [`onResume()`](/reference/android/app/Activity#onResume())\nlifecycle methods contain a call to [`requestlocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#requestLocationUpdates(com.google.android.gms.location.LocationRequest,%20android.app.PendingIntent)) without a\ncorresponding call to [`removeLocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient.html#removeLocationUpdates(com.google.android.gms.location.LocationCallback)) in the [`onPause()`](/reference/android/app/Activity#onPause()) or\n[`onStop()`](/reference/android/app/Activity#onStop()) lifecycle methods.\n\nYou can use lifecycle-aware components to better manage the lifecycle of the\nactivities in your app. For more information, see [Handling Lifecycles with\nLifecycle-Aware Components](/topic/libraries/architecture/lifecycle).\n\nSet timeouts\n------------\n\nTo guard against battery drain, set a reasonable timeout when location updates\nshould stop. The timeout ensures that updates don't continue indefinitely, and\nit protects the app in scenarios where updates are requested but not removed\n(for example, because of a bug in the code).\n\nFor a fused location provider request, add a timeout by calling\n[`setDurationMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setDurationMillis(long)), which receives a parameter that represents the\ntime in milliseconds since the method was last called. You can also use the\nmethod to express the expiration time in terms of duration.\n\nTo add a timeout to a geofence location request, call the\n[`setExpirationDuration()`](https://developers.google.com/android/reference/com/google/android/gms/location/Geofence.Builder.html#setExpirationDuration(long)) method.\n\nBatch requests\n--------------\n\nFor all non-foreground use cases, batch multiple requests together. Use the\n[`setIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setIntervalMillis(long)) method to specify the interval at which you would like\nlocation to be computed. Then, use the [`setMaxUpdateDelayMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setMaxUpdateDelayMillis(long)) method to set\nthe interval at which location is *delivered* to your app. Pass a value to the\n`setMaxUpdateDelayMillis()` method that is a multiple of the value passed to the\n`setIntervalMillis()` method. For example, consider the following location request: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build();\n\nIn this case, the system computes location roughly every ten minutes and\ndelivers approximately six location data points in a batch approximately every\nhour. While you still get location updates every ten minutes or so, you conserve\nbattery because your device wakes up only every hour or so.\n\nUse passive location updates\n----------------------------\n\nIn background use cases, it is a good idea to throttle location updates. Android\n8.0 (API level 26) limits enforce this practice, but apps running on lower\ndevices should strive to limit background location as much as possible.\n\nIt is likely that while your app is in the background, another app may be\nfrequently requesting location updates in the foreground. Location services\nmakes these updates available to your app. Consider the following location\nrequest, which opportunistically consumes location data: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build();\n\nIn the previous example, the app's location computes roughly every 15 minutes.\nIf other apps request location, the app receives the data at a maximum interval\nof two minutes.\n\nWhile consuming location passively incurs no battery drain, take extra care in\ncases where the receipt of location data triggers expensive CPU or I/O\noperations. To minimize battery costs, the interval specified in\n[`setMinUpdateIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#public-locationrequest.builder-setmaxupdateagemillis-long-maxupdateagemillis(long)) shouldn't be too small."]]
