[Android] WorkManager 2.5.0 스테이블 릴리즈 변경 사항
이 글은 구글 미디엄에 작성된 내용을 번역 및 인용한 글입니다.
최근 WorkManager 2.5.0 버전이 사용 가능함에 따라 멀티 프로세스 환경과 몇가지 안정성 향상을 제공합니다.
더 이상 초기화 에러를 발생시키지 않고 멀티 프로세스 백그라운드 작업을 관리할 수 있습니다.
Work-Multiprocess
build.gradle(app)에 추가해줍니다.
Implementation "androidx.work:work-multiprocess:2.5.0"
이제 WorkManager가 WorkRequests 대기열에 추가하는데 사용하는 지정된 프로세스를 선택하고 프로세스 내 스케줄을 실행할 수 있습니다.
Configuration.Provider
를 다음과 같이 설정할 수 있습니다.
class MyApplication() : Application(), Configuration.Provider { override fun getWorkManagerConfiguration() =
Configuration.Builder()
.setProcessName(“com.example:remote”)
.build()
}
Note: setProcessName의 매개 변수를 사용하려면 앱의 패키지 이름, 콜론, 호스트의 프로세스 이름으로 구성된 정규화 된 프로세스 이름을 전달해야합니다
Work-Multiprocess를 사용할 시 WorkManager 대신 RemoteWorkManager를 사용할 수 있습니다. RemoteWorkManager는 항상 작업을 대기열에 추가하기 위해 지정된 프로세스에 연락합니다. 이렇게하면 호출 프로세스에서 실수로 새 WorkManager를 초기화하지 않습니다. In-process 스케줄러는 동일한 지정된 프로세스에서도 실행됩니다.
이점
RemoteWorkManager를 사용하여 작업하면 다중 프로세스 앱에서 작업을 더 빠르고 안정적으로 관리 가능합니다.
SQLITE 경합 같은 케이스를 줄일 수 있고, 특정 앱에 지정한 프로세스에서 실행되는 단일 WorkManger 인스턴스만 가지기 때문에 프로세스간의 작업 조정이 더 이상 필요하지 않습니다.
행동 변경
작업 조정
이전에는 ActivityManager가 작업을 시작하기 위해 JobService를 인스턴스화 할 수없는 경우 플랫폼의 버그로 인해 해당 작업이 자동으로 삭제되었습니다. WorkManager는 이제 WorkRequest 개체를 작업과 조정하여 Application 인스턴스가 생성 될 때 모든 단일 WorkRequest에 대한 백업 스케줄러 작업이 있는지 확인합니다.
내부 데이터베이스 증가 제한
앱 충돌의 원인 중 하나는 장치의 저장 공간이 부족하다는 것입니다.
앱이 많은 작업을 예약 할 때 WorkManager는 저장공간이 부족한 장치를 위해 부분적인 책임만 가지고 있습니다
완료된 작업은 기본적으로 7 일 동안 내부 WorkManager 데이터베이스에 기록되었습니다. 이 시간은 1 일로 단축되어 데이터베이스 크기가 크게 줄어 듭니다.
해당 내용은 WorkManagerSample 깃허브 사이트에서 참고 할 수 있습니다.