popBackStackImmediate VS. popBackStack

1. popBackStackImmediate

• 콜하는 즉시 pop 된다.
• 정확한 타이밍에 pop 되어야 하는 경우에 사용.
• 바로 pop 을 처리하기 때문에 상대적으로 느리고 성능 문제를 야기할 수 있기 때문에 위와 같은 상황이 아니면 popBackStack 사용을 권장한다.

2. popBackStack

• 다음 이벤트 루프에서 pop 된다.
• 따라서 콜한 즉시 백스택에서 FragmentTransaction 이 제거되지 않는다.
• 대부분의 경우 FragmentTransaction 이 바로 지워져야 하지 않기 때문이다.
• 비동기적으로 다른 작업들이 끝난 이후에 작동한다.
• 그런데 매우 빠르게 다음 이벤트 루프에 도달하기 때문에 사용자들이 동작의 차이를 알아차리기 어렵다.

commit VS. commitAllowingStateLoss

아래 글 부터는
Bryan Herbst 의 The many flavors of commit 의 일부를 번역한 것입니다.

commit 과 commitAllowingStateLoss 는 구현에 있어서 거의 비슷하다고 볼 수 있습니다. 유일한 차이는 commit이 FragmentManager 가 자신의 state 를 저장했는지 확인한다는 것입니다. 만약 이미 state 를 저장했다면 IllegalStateException 를 던집니다.

그렇다면 commitAllowingStateLoss 는 어떤 state 를 잃는(loss) 다는 것일까요? 정답은 FragmentManager 의 state 그리고 onSaveInstanceState 이후에 더해지거나 제거된 Fragment들의 state 를 잃을 수 있다는 것입니다.

여기서 onSaveInstanceState 과 fragment와 FragmentManager 의 state 는 무엇일까요??

예시를 들어보겠습니다.
1. 당신의 Activity 가 보여지고 있고 Fragment A 를 보이고 있습니다.
2. 당신의 Activity 가 백그라운드(onStop() 과 onSaveInstanceState()가 불렸습니다.) 에 보내졌습니다.
3. 어떤 이벤트에 의해서 당신이 Fragment A 를 Fragment B 로 바꾸었고 commitAllowingStateLoss 를 불렀습니다.

이러한 경우, 유저가 다시 당신의 앱으로 돌아왔을 때 아래의 두 가지 상황 중 하나가 발생할 수 있습니다.
1. 만약 시스템이 다른 앱을 위해 당신의 앱을 죽였다면, 당신의 앱은 2단계에서의 saved state 와 함께 다시 만들어질 것입니다. 따라서 Fragment B 는 보이지 않을 것입니다.
2. 만약 시스템이 당신의 앱을 죽이지 않았다면, (따라서 당신의 앱이 메모리 내에 있다면) 유저가 다시 앱으로 돌아왔을 때 앱은 포그라운드로 불려지고 Fragment B 가 보일 것입니다.

(언제 state 를 잃는지를 보여주는 간단한 플로우)

결론적으로 둘 중 어느 것을 선택해서 사용해야 될까요? 이것은 당신이 무엇을 commit 하고, 해당 commit 으로 잃어도 괜찮은지에 달려 있겠지요.

출처

https://stackoverflow.com/questions/44655586/difference-between-popbackstackimmediate-vs-popbackstack/44656478,
https://danggai.github.io/android/popBackStack%EA%B3%BC-popBackStackImmediate%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90/