이 페이지에서는 제대로 작동하는 백그라운드 작업을 설정하기 위한 몇 가지 권장사항을 제안합니다. 이러한 권장사항은 특히 배터리 소모를 줄이는 것을 목표로 하지만, 네트워크 사용 줄이기와 같은 다른 방식으로 기기 성능을 개선할 수도 있습니다.
최적의 제약 조건 선택 및 태스크 결합
작업이 기기에 미치는 부하를 최소화하려면 최적의 제약 조건을 지정하는 것이 중요합니다. (JobScheduler 작업의 경우 제약 조건 목록은 JobInfo.Builder를 참조하세요.) 한 가지 예를 들어 앱의 배터리가 소진되지 않도록 하려면 RequiresCharging 제약 조건을 지정하는 것이 좋습니다. 이 제약 조건은 배터리 잔량이 실제로 증가하고 있지 않는 한 작업을 실행하지 않도록 시스템에 지시합니다. 마찬가지로 Wi-Fi를 사용하려면 일반적으로 모바일 데이터보다 전력이 덜 필요합니다. 따라서 작업에 네트워크 연결이 필요하지만 무제한 네트워크를 사용할 수 있을 때까지 기다릴 수 있는 경우 NetworkType.UNMETERED 제약 조건을 설정하는 것이 좋습니다.
또한 동일한 제약 조건에 해당하는 유사한 작업이 여러 개 있다면 일반적으로 이러한 작업을 단일 작업으로 결합하여 기기의 절전 모드가 한 번만 해제되도록 하는 것이 좋습니다. 예를 들어 앱에 클라우드 스토리지와 동기화해야 하는 세 가지 데이터 세트가 있다고 가정해 보겠습니다. 각 데이터 세트당 하나씩, 세 가지 작업을 예약하는 대신 단일 '데이터 동기화' 작업을 예약하고 적절한 제약 조건을 정의한 다음 작업이 실행될 때 대기 중인 모든 데이터 동기화를 실행하도록 하는 것이 더 좋습니다.
그렇지만 관련 없는 작업을 단일 작업으로 결합하려고 해서는 안 됩니다. 대신 각 작업에 적절한 제약 조건을 부여해야 합니다. 예를 들어 작업의 우선순위가 낮은 경우 기기가 유휴 상태이고 충전 중일 때 실행되도록 지정해야 합니다. 이렇게 하면 기기의 절전 모드가 여러 번 해제되더라도 사용자 환경이 저하되거나 배터리 수명에 영향을 주지 않습니다.
시간에 민감한 경우에만 할 일을 신속 처리로 표시
특히 긴급한 작업인 경우 신속 처리로 표시할 수 있습니다. (JobScheduler 작업의 경우 JobInfo.Builder.setExpedited(true)를 호출하세요.) 이렇게 하면 여러 가지 방식으로 작업의 우선순위가 지정됩니다. 예를 들어 시스템은 가능한 경우 이러한 작업을 즉시 실행하고 전력 관리 제한이 신속 처리 작업에 영향을 미칠 가능성이 작습니다.
따라서 필요한 경우에만 작업을 신속 처리로만 표시해야 합니다. 신속 처리 작업은 일부 시스템 효율성보다 우선할 수 있으므로 신속 처리 작업은 이렇게 표시되지 않을 때보다 더 많은 전력을 소모할 수 있습니다.
시간에 민감한 경우에만 작업을 신속 처리로 표시해야 하며, 작업을 실행하는 데 시간이 더 오래 걸리면 사용자 경험이 저하됩니다. 예를 들어 앱에서 우선순위가 높은 FCM 메시지를 처리하는 작업을 실행한다면 이 작업을 신속 처리로 표시하는 것이 적절합니다. 그러나 시스템 최적화를 재정의하기 위해 작업을 신속 처리로 표시해서는 안 됩니다.
작업이 중지된 이유 확인하기
작업이 완료되기 전에 중지되면 WorkInfo.getStopReason()를 호출하여 중지된 이유를 확인할 수 있습니다. (JobScheduler 작업의 경우 JobParameters.getStopReason()를 호출합니다. 여기에는 몇 가지 이유가 있습니다. 무엇보다도 할 일을 완료하는 것이 좋습니다. 태스크가 중지된 이유를 알아내면 유사한 상황을 방지할 수 있습니다. 그러나 시스템 리소스를 과도하게 사용하는 동작으로 인해 시스템이 작업을 중지할 수도 있습니다. 앱이 배터리나 네트워크를 불필요하게 사용하여 악의적으로 사용하지 않도록 해야 합니다.
예를 들어 STOP_REASON_TIMEOUT 이유로 작업이 자주 중지되는 경우 극단적인 사례로 인해 작업이 예상보다 훨씬 오래 걸리는 경우가 있을 수 있습니다.
분석 엔진을 사용하여 앱의 태스크가 중지되었는지 여부와 그 이유를 추적하는 것이 좋습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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 battery use for task scheduling APIs\n\nThis page suggests a few best practices for setting up well-behaved background\ntasks. These best practices are specifically aimed at reducing battery\nconsumption, but they can also improve device performance in other ways, like\nreducing network use.\n| **Note:** This page focuses on how to optimize tasks created with [WorkManager](/develop/background-work/background-tasks/persistent), our preferred library for scheduling tasks. In many cases, these suggestions also apply to [`JobScheduler`](/reference/android/app/job/JobScheduler) jobs, though the APIs you use are slightly different. Where appropriate, we've called out some corresponding `JobScheduler` APIs.\n\nChoose optimal constraints and combine tasks\n--------------------------------------------\n\nTo minimize the load your tasks place on the device, it's important to [specify\noptimal constraints](/develop/background-work/background-tasks/persistent/getting-started/define-work#work-constraints). (For JobScheduler jobs, see [`JobInfo.Builder`](/reference/android/app/job/JobInfo.Builder#setExpedited(boolean)) for\nthe list of constraints.) To take one example, if you want to make sure your app\ndoesn't run down the battery, it's a good idea to specify the `RequiresCharging`\nconstraint. This constraint tells the system not to run the job unless the\nbattery level is actually increasing. Similarly, using Wi-Fi generally requires\nless power than mobile data, so if your task needs a network connection but can\nwait until an unmetered network is available, it's a good idea to set a\n[`NetworkType.UNMETERED`](/reference/androidx/work/NetworkType#UNMETERED) constraint.\n\nAlso, if you have several similar tasks that would fall under the same\nconstraints, it's usually a good idea to combine them into a single task, so the\ndevice only gets woken up once. For example, suppose your app has three\ndifferent data sets it needs to sync with cloud storage. Instead of scheduling\nthree different tasks--one for each data set--it's usually a better idea to just\nschedule a single \"synchronize the data\" task, define appropriate constraints,\nand let that task do all the pending data synchronization when it runs.\n\nThat said, you shouldn't try to combine *unrelated* tasks into a single\ndo-it-all task. Instead, just make sure to give each task appropriate\nconstraints. For example, if tasks are low priority, make sure to specify that\nthey should run when the device is idle and charging. That way, even if the\ndevice gets woken up several times, it won't hurt the user experience or impact\nbattery life.\n\nOnly mark tasks as expedited when they're time-sensitive\n--------------------------------------------------------\n\nIf a task is particularly urgent, you can [mark it as expedited](/develop/background-work/background-tasks/persistent/getting-started/define-work#expedited). (For\nJobScheduler jobs, call [`JobInfo.Builder.setExpedited(true)`](/reference/android/app/job/JobInfo.Builder#setExpedited(boolean)).) Doing so\nprioritizes the task in a number of ways. For example, the system runs those\ntasks immediately when it can, and power management restrictions are less likely\nto affect expedited tasks.\n\nFor these reasons, you should be careful to *only* mark a task as expedited when\nyou need to. Because expedited tasks can override some system efficiencies,\nexpedited tasks can drain more power than they would if they weren't marked that\nway.\n\nYou should only mark a task as expedited if it's time-sensitive, and the user\nexperience would be impaired if the task took longer to execute. For example, if\nyour app runs a task to handle a high-priority FCM message, that's an\nappropriate reason to mark the task as expedited. But you shouldn't mark a task\nas expedited just to override system optimizations.\n\nCheck why your tasks were stopped\n---------------------------------\n\nIf your tasks stop before they finish, you can check why they were stopped by\ncalling [`WorkInfo.getStopReason()`](/reference/androidx/work/WorkInfo#getStopReason()). (For JobScheduler jobs, call\n[`JobParameters.getStopReason()`](/reference/android/app/job/JobParameters#getStopReason()) It's important to do this for a couple of\nreasons. First of all, of course, you want your tasks to finish. Finding out why\nyour tasks stopped helps you avoid similar situations. But also, the system is\nlikely to stop tasks because of behavior that overuses system resources. You\ndon't want your app to be a bad citizen, using the battery or network\nunnecessarily.\n\nFor example, if your tasks frequently get stopped with the reason\n[`STOP_REASON_TIMEOUT`](/reference/androidx/work/WorkInfo#STOP_REASON_TIMEOUT()), there might be an edge case that sometimes causes\nyour tasks to take much longer than you're expecting.\n\nWe recommend that you use your analytics engine to track whether your app's\ntasks are stopped, and for what reasons.\n| **Important:** On Android 14 or higher, if an app's tasks time out too often, the system can [put the app in the restricted standby bucket](/about/versions/14/behavior-changes-all#triggers-to-restricted-bucket)."]]