프로바이더는 언제 생성되고 언제 폐기될까?
모든 유형의 프로바이더가 가질 수 있는 상태는 동일합니다.
- Uninitialized(초기화되지 않은 상태)
- Alive(활성화 상태)
- Paused(일시 중지 상태)
- Disposed(폐기 상태)
폐기됨/초기화되지 않음
초기화되지 않거나 폐기된 프로바이더는 상태가 초기화되지 않았기 때문에 메모리를 차지하지 않습니다. 기본적으로 필요할 때 프로바이더의 상태를 생성하는 방법에 대한 정의일 뿐입니다. 이 상태는 UI의 활성 프로바이더 또는 WidgetRef가 읽거나(reads), 구독(watches)하거나, 수신(listens)할 때까지 그대로 유지됩니다 .
Creating → Alive
초기화되지 않은 프로바이더를 사용할 때(read, listen, watch) 상태가 생성됩니다.
생성하는 동안 프로바이더의 빌드 함수가 실행됩니다. 콜백에 의해 노출된 ref
를 사용하여 상태를 읽거나 구독하는 모든 프로바이더는 필요에 따라 생성되고 해당 상태가 검색됩니다.
이 생성 프로세스 중에 순환 종속성이 있는 경우에 Riverpod는 오류가 발생시킵니다. 이 오류를 해결하는 가장 좋은 방법은 단방향 데이터 흐름을 갖도록 종속성을 다시 설계하는 것입니다.
프로바이더의 상태는 ProviderContainer 에 저장됩니다 . Flutter 앱에서 이 컨테이너는 ProviderScope 위젯에 있습니다.
따라서 상태(프로바이더)를 만드는 방법에 대한 정의는 전역적이지만 실제로 상태는 로컬이며 중첩된 ProviderScope 위젯 및 오버라이드를 사용하여 UI의 다른 부분에서 다르게 설정할 수 있습니다.
이는 Flutter 위젯이 작동하는 방식과 매우 유사합니다. 정의에 대한 비용은 한 번만 지불하지만 필요에 따라 트리의 다른 부분에서 상태를 재사용할 수 있습니다.
Alive
프로바이더가 Alive 상태일 때 해당 상태가 변경되면 종속 프로바이더 및/또는 종속 UI가 다시 빌드됩니다.
다른 관점에서 보면, 반응형 프레임워크로서 다른 프로바이더를 감시하여 종속성 중 하나가 변경될 때마다 프로바디어가 스스로 다시 생성되도록 할 수 있습니다.
다른 상태에 의존하는 수명이 긴 상태가 필요한 경우 Ref의 listen 메서드을 사용하여 프로바이더를 다시 빌드하지 않고 다른 프로바이더의 변경 사항을 구독할 수 있습니다.
부작용으로 다른 프로바이더의 상태를 사용해야 하는 경우 Ref의 [read] 메서드를 사용하여 다른 프로바이더로부터 현재 상태를 가져올 수 있습니다.
일반적으로 StateNotifier 또는 ChangeNotifier 클래스를 구성할 때 필요에 따라 Notifier가 종속성의 현재 값을 얻을 수 있도록 ref
를 전달해야 합니다 . Riverpod 2.0의 새로운 Notifier 및 AsyncNotifier 클래스를 사용하면 ref
를 클래스의 인스턴스 멤버로 이미 사용할 수 있습니다.
Alive -> Paused
활성 상태의 프로바이더가 다른 프로바이더나 UI에서 더 이상 수신되지 않으면 일시 중지 상태가 됩니다 . 즉, 수신 중인 프로바이더의 변경 사항에 더 이상 반응하지 않습니다. 이는 최적화한 것으로 프로바이더를 수신되지 않는 경우에는 해당 프로바이더를 활성 상태로 유지할 필요가 없기 때문입니다. 사용하지 않는 모든 프로바이더는 Paused 상태 로 돌아가서 앱의 계산 부담이 줄어듭니다.
부작용을 방지하기 위해 프로바이더를 활성 상태로 유지해야 하는 경우, UI의 적절한 위치에서 활성 상태로 유지해야하는 프로바이더를 수신해야 합니다.
프로바이더가 일시 중지되었을 때 특정 작업을 수행해야 하는 경우, ref
의 onCancel 메서드를 사용하여 콜백을 등록하세요.
프로바이더가 일시 중지 상태에서 다시 활성 상태로 재개될 때 어떤 작업을 수행해야 하는 경우, ref
의 onResume 메서드를 사용하여 콜백을 등록하세요.
상태를 폐기하여 리소스를 사용하지 않을 뿐만 아니라, 메모리에서도 폐기하려면 프로바이더에 autoDispose
수식어를 사용하세요. 이렇게 하면 해당 프로바이더가 더 이상 사용되지 않을 때 일시 중지 대신 Disposed 상태로 전환됩니다 .
Alive -> Disposing
프로바이더가 폐기되는 데는 몇 가지 이유가 있습니다.
autoDispose
수식어를 사용하여 정의되고, UI 또는 다른 프로바이더에 의해 더 이상 감시되지 않는 경우- 프로바이더를 수동으로 새로 고치거나 무효화하는 경우
- 감시 대상 중 하나의 종속성 변경으로 인해 프로바이더가 다시 생성되는 경우
새로 고침은 프로바이더가 즉시 생성 프로세스를 다시 거치는 반면, 무효화는 다음에 프로바이더를 읽거나 감시하면 프로바이더가 다시 빌드됩니다.
상태가 폐기되지 전에 작업 수행하기
프로바이더가 폐기될 때 어떤 작업을 수행해야 하는 경우, ref
의 onDispose 메서드를 사용하여 콜백을 등록하세요.
다음은 onDispose
를 사용하여 StreamController
를 닫는 예제입니다.
final example = StreamProvider.autoDispose((ref) {
final streamController = StreamController<int>();
ref.onDispose(() {
// 이 프로바이더의 상태가 소멸되면 StreamController를 닫습니다.
streamController.close();
});
return streamController.stream;
});
[!note] 메모
사용하는 프로바이더에 따라 이미 정리 프로세스를 처리할 수도 있습니다. 예를 들어 StateNotifierProvider는 반환된 StateNotifier의dispose
메서드를 호출합니다.
or
'개발 > 플러터(Flutter)' 카테고리의 다른 글
(Flutter) Riverpod의 Provider 종류 (0) | 2023.03.30 |
---|---|
(Flutter) Riverpod 상태 불변성(Immutability) (0) | 2023.03.30 |
(Flutter) Riverpod의 ProviderObserver (0) | 2023.03.29 |
(Flutter) Riverpod의 Modifiers (0) | 2023.03.28 |
(Flutter) Riverpod의 Provider 상태 결합하기 (0) | 2023.03.27 |