백그라운드 프로세스는 메모리와 배터리를 많이 사용할 수 있습니다. 예를 들어 암시적 브로드캐스트는 비록 해당 프로세스가 많은 작업을 수행하지 못하더라도 이를 수신 대기할 수 있습니다. 여기에는 기기 성능과 사용자 환경에 모두 상당한 영향을 미칠 수 있습니다.
시스템 제한을 피하려면 올바른 API를 할 수 있습니다. 이 백그라운드 작업 개요 문서를 통해 적합한 API를 찾을 수 있습니다
사용자 시작 제한사항
앱이 Android vitals에 설명된 잘못된 동작을 보이면 시스템에서 사용자에게 시스템 리소스에 대한 앱의 액세스를 제한하라는 메시지를 표시하는 경우
시스템에서 앱이 과도한 리소스를 소비하고 있음을 감지하면 사용자에게 앱의 작업을 제한하는 옵션을 제공합니다. 알림을 트리거할 수 있는 동작은 다음과 같습니다.
- 불필요한 wake lock: 화면이 켜져 있을 때 1시간 동안 유지되는 부분적인 wake lock 1회 사용 안 함
- 불필요한 백그라운드 서비스: 앱이 API 수준 26 미만을 타겟팅하는 경우 백그라운드 서비스가 너무 많습니다.
적용되는 정확한 제한사항은 기기 제조업체에서 확인합니다. 대상 예를 들어 AOSP 빌드에서는 제한된 앱이 작업을 실행하거나 알람을 트리거하거나 네트워크에만 적용됩니다.
네트워크 활동 브로드캐스트 수신에 관한 제한사항
앱이 CONNECTIVITY_ACTION
브로드캐스트를 수신하며 이 브로드캐스트에 의존하는 프로세스를
시작할 수 없습니다. 네트워크를 수신 대기하려는 앱에 문제가 발생할 수 있습니다.
장치가 네트워크에 연결될 때 대량 네트워크 활동을 변경하거나
사용할 수 있습니다 이 제한을 해결하기 위한 몇 가지 솔루션은 이미 있습니다.
존재하지만 올바른 것을 선택하는 것은
정의할 수 있습니다.
무제한 연결에서 작업 예약
WorkRequest
를 빌드할 때 NetworkType.UNMETERED
Constraint
를 추가합니다.
fun scheduleWork(context: Context) {
val workManager = WorkManager.getInstance(context)
val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
.setConstraints(
Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.build()
)
.build()
workManager.enqueue(workRequest)
}
작업의 조건이 충족되면 앱은 작업을 실행하기 위한 콜백을 수신합니다.
지정된 Worker
클래스의 doWork()
메서드
앱이 실행되는 동안 네트워크 연결 모니터링
실행 중인 앱은 CONNECTIVITY_CHANGE
BroadcastReceiver
에 등록되었습니다. 하지만 ConnectivityManager
API는
지정된 네트워크가 있을 때만 콜백을 요청하는 더 강력한 메서드 제공
확인할 수 있습니다
NetworkRequest
객체는 네트워크 콜백의 매개변수를
NetworkCapabilities
약관 NetworkRequest
객체 만들기
NetworkRequest.Builder
클래스를 사용합니다. registerNetworkCallback
드림
그런 다음 NetworkRequest
객체를 시스템에 전달합니다. 네트워크에서
조건이 충족되면 앱은
onAvailable()
메서드가
ConnectivityManager.NetworkCallback
클래스).
앱은 앱이 종료되거나 앱이 호출될 때까지 콜백을 계속 수신합니다. unregisterNetworkCallback()으로 전달됩니다.
이미지 및 동영상 브로드캐스트 수신에 관한 제한사항
앱이 ACTION_NEW_PICTURE를 보내거나 받을 수 없거나, ACTION_NEW_VIDEO 브로드캐스트를 전송할 수 있습니다. 이러한 제한사항은 여러 앱이 순서대로 절전 모드에서 해제되어야 할 때 성능 및 사용자 경험이 영향을 받음 새로운 이미지나 동영상을 처리할 수 있습니다
어떤 콘텐츠 권한이 작업을 트리거했는지 확인
WorkerParameters
를 사용하면 앱이
콘텐츠 권한과 URI가 작업을 트리거했습니다.
List<Uri> getTriggeredContentUris()
작업을 트리거한 URI 목록을 반환합니다. 다음과 같은 경우 비어 있습니다. 작업을 트리거한 URI가 없거나 (예: 또는 변경된 URI 수가 50.
List<String> getTriggeredContentAuthorities()
작업을 트리거한 콘텐츠 권한의 문자열 목록을 반환합니다. 만약
반환된 목록이 비어 있지 않습니다. getTriggeredContentUris()
를 사용하여
변경된 URI의 세부정보입니다.
다음 샘플 코드는 CoroutineWorker.doWork()
메서드를 재정의합니다.
작업을 트리거한 콘텐츠 권한과 URI를 기록합니다.
class MyWorker(
appContext: Context,
params: WorkerParameters
): CoroutineWorker(appContext, params)
override suspend fun doWork(): Result {
StringBuilder().apply {
append("Media content has changed:\n")
params.triggeredContentAuthorities
.takeIf { it.isNotEmpty() }
?.let { authorities ->
append("Authorities: ${authorities.joinToString(", ")}\n")
append(params.triggeredContentUris.joinToString("\n"))
} ?: append("(No content)")
Log.i(TAG, toString())
}
return Result.success()
}
}
시스템 제한이 적용된 앱 테스트
메모리가 부족한 기기나 조건에서 실행되도록 앱을 최적화하려면 실적과 사용자 환경을 개선할 수 있습니다 백그라운드의 종속 항목 삭제 서비스와 매니페스트 등록 암시적 broadcast receiver를 사용하면 앱에 도움이 될 수 있습니다. 이러한 기기에서 더 잘 실행됩니다. 앱이 실행될 수 있도록 최적화하는 것이 좋습니다. 백그라운드 프로세스를 완전히 사용하지 않고서도 말이죠.
몇 가지 추가적인 Android 디버그 브리지 (ADB) 명령어를 사용해 앱을 테스트할 수 있습니다. 다음과 같이 동작합니다.
암시적 브로드캐스트 및 백그라운드 서비스가 실행되는 조건을 시뮬레이션하기 위해 사용할 수 없는 경우 다음 명령어를 입력합니다.
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore
암시적 브로드캐스트 및 백그라운드 서비스를 다시 사용 설정하려면 다음을 입력합니다. 명령어:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow
앱의 추가 최적화
백그라운드 작업을 최적화하는 다른 좋은 방법 보려면 작업 예약 API를 위한 배터리 사용 최적화 문서를 참조하세요.