[ Android ] Android의 Fragment

🧩 Android의 Fragment

React Native로 개발하면서 Android 쪽에서는 Fragment, FragmentManager,
그리고 RNScreensFragmentFactory 같은 단어들이 계속 튀어나온다.
정작 나는 JS만 하고 싶은데… ㅂㄷㅂㄷ

Activity = 집, Fragment = 집 안의 방

Fragment를 이해하는 데 가장 쉽게 와닿았던 비유:

• Activity → 집 전체

• Fragment → 집 안의 방

이라는 구조다.

Activity는 화면의 큰 틀을 구성하는 존재이고,
Fragment는 그 안에서 자유롭게 붙였다 떼었다 할 수 있는 “화면 조각”이다.

내가 React Navigation의 스크린 전환을 Android에서 보면,
이게 결국 Fragment 단위로 쌓이고 사라진다

왜 Android는 굳이 Fragment라는 개념을 만들었나?

예전 안드로이드 시절에는 화면 하나 = Activity 하나였다.
하지만 이런 방식에는 여러 한계가 있었다.

• 화면의 일부만 바꾸고 싶을 때 전체 Activity를 갈아끼워야 하고

• 태블릿처럼 큰 화면에서는 여러 UI를 한 화면에 배치하기 어렵고

• 구성 변경(회전, 다크모드 전환 등)에서 재사용하기도 까다롭고

• UI를 조합하기도 어려움

그래서 Android는 결국:

“집 안에 작은 화면 덩어리(방)를 만들 수 있게 하자”

하고 내놓은 게 Fragment다.

Fragment는 어떤 요소들로 이루어진 존재인가?

Fragment는 단순한 뷰 덩어리가 아니다.
Fragment 자체가 하나의 “작은 화면 단위”다.

내가 이해한 Fragment 구성 요소는 이렇다:

1) 자기만의 레이아웃 (XML)

Fragment마다 자체 뷰를 가진다.

2) 자기만의 생명주기 (Lifecycle)

Activity와 비슷하지만 별도의 라이프사이클 단계를 가진다.

3) 자기 상태(arguments, saved state)

초기 props처럼 데이터를 전달받고,
화면이 다시 복원될 때 필요한 상태를 저장할 수도 있다.

4) 백스택 관리 대상

FragmentManager가 이력(stack)을 관리한다.
React Navigation의 이동도 실제로는 이 백스택을 네이티브에서 조작하는 방식.

Fragment를 화면 조각이라고 부르는 이유가 이 4가지로 딱 설명된다.

FragmentManager = 집주인

Fragment를 붙이고, 떼고, 덮고, 뒤로가기를 처리하는 존재가 FragmentManager다.
내가 JS로 화면 이동을 시켜도 Android에서는 이 FragmentManager가 그 요청을 네이티브 트랜잭션으로 바꿔 실행한다.

React Navigation에서 스택이 꼬이거나 이상한 화면이 나오는 문제의 원인 대부분 백스택과 Fragment 복원 문제일 것이다.

Android는 화면을 “복원”하려고 하기 때문에 복잡해진다

Android는 아래 같은 상황에서 Activity/Fragment를 죽였다가 다시 복원한다.

• 메모리 부족

• 화면 회전

• 다크모드 전환

• 앱이 백그라운드 갔다가 프로세스 kill된 경우

이때 Android는 Fragment를 다시 만들어야 하는데,
이 과정에서 “어떻게 생성해야 하는지”를 결정하는 것이 FragmentFactory이다.

즉,

Android는 Fragment를 자동으로 다시 만들 수 있기 때문에,
“올바르게 생성하는 규칙”이 필요하다.

이게 바로 react-native-screens에서 RNScreensFragmentFactory가 필요한 이유다.

RNScreensFragmentFactory가 필요한 이유 - Android

React Navigation + react-native-screens는
Android에서 ScreenFragment, ScreenStackFragment 같은 커스텀 Fragment를 사용한다.

이 Fragment들은 단순 new()로 만들면 내부 연결 정보나 네비 상태가 엉킨다.
그래서 “특별한 생성 규칙”이 정의된 Factory가 필요하다.

그 규칙이 구현된 곳이:

RNScreensFragmentFactory

이걸 MainActivity에 등록하는 이유는 단순하다:

override fun onCreate(savedInstanceState: Bundle?) {
  supportFragmentManager.fragmentFactory = RNScreensFragmentFactory()
  super.onCreate(savedInstanceState)
}

• Android가 Fragment를 자동 복원할 때

• React Native Screens에 맞는 방식으로

• “올바르게” 다시 만들 수 있도록 설정하는 한 줄

이게 없으면 간헐적으로 화면이 꼬이거나 백스택이 이상하게 작동한다.

iOS는 왜 이런 게 필요 없을까?

Android에는 Fragment가 있고,
iOS에는 Fragment라는 개념이 아예 없다.

iOS의 기본 화면 구조는 아주 단순하고 명확하다.

• UIViewController = 화면 하나

  • 그 자체가 화면의 모든 역할을 담당한다.

• UINavigationController

  • push/pop을 다루는 네이게이션 컨트롤러.

• UITabBarController

  • 하단 탭.

• 모달 표시 방식

  • iOS 고유의 다양한 모달 스타일.

React Navigation도 iOS에서는
각 <Screen>을 UIViewController로 매핑해서 동작할 뿐이다.

그리고 iOS는:

• 화면을 Android처럼 복잡하게 “자동 복원”하지도 않고

• Fragment 같은 중간 계층도 없어서

• Android에서처럼 Factory를 지정할 필요도 없다.

즉, iOS는 네비 구조 자체가 깔끔하고 단순하다.
복원이 복잡한 Android만 FragmentFactory를 요구하는 구조인 것.

결론

• Android는 Activity(집) + Fragment(방) 구조

• React Navigation의 Android 스크린은 결국 Fragment로 만들어진다

• Android는 Fragment를 자동으로 복원하기 때문에
  Screens 전용 Factory 설정이 필요하다

• iOS는 UIViewController 기반이라 이런 작업이 필요 없다