내가 참여한 대부분의 프로젝트에서 상당 수가 Single Activity - Multi Fragment 구조를 가지고 있다.
그렇다면 나는 왜 Activiy보다 Fragment를 많이 사용할까? 🧐
찰스님의 글에서 내가 사용하던 이유와 추가적인 견해를 얻게 되었다.
퍼포먼스
- 액티비티는 무겁다.
- 액티비티 초기화가 오래 길리지 않지만 프레그먼트와 비교시 상대적으로 무겁다.
그러나, Fragment가 단독으로 존재할 수 없기에 Activity의 존재는 필수적이다. - Activity 내에서 Fragment는 상대적으로 가볍게 추가/제거가 가능하다.
- Activity Stack에 Activity를 쌓아두기보다 Fragment Backstack에서 Fragment를 관리하는게 메모리 관리에서의 효율도 챙기고 화면 전환시에 Activity보다 더 순조롭다.
데이터 공유하기
- 액티비티 간 데이터를 공유하는 가장 일반적인 방법은 Intent를 사용하는 방법이다.
- Activity는 다른 Process에서 실행하는 것을 염두하고 설계 되었기에 메모리 영역을 공유하지 않는다.
- 그렇기에 Linux Kernal Level에서 프로세스간 통신 (IPC)를 해야 하는데 이는 직접 메모리에 접근하는 것보다 많은 제약사항이 존재하고 퍼포먼스가 떨어진다.
- 액티비티 간, 데이터를 전달하려면 직렬화/역직렬화 과정을 거쳐야 하고 이는 메모리 공유에 비해 절대 가벼운 작업은 아니다.
재사용성의 증가
- View or Business Logic을 Fragment 단위로 분리 가능하다.
- 아키텍쳐 원칙에서 가장 중요한 원칙인 관심사 분리를 통해 의존성을 분리하고 독립성을 키우게 된다.
유연한 UI/UX 구현
- Fragment는 기본적으로 큰 화면에서 역동적이고 유연한 UI 디자인을 지원하는 것이 목적이었다.
- NavigationDrawer, BottomSheetDialog, Navigation Component 등을 구현할 때도 사용된다.
이렇게만 글을 읽다 보면 어? 무조건 Fragment로만 구성해야하는 건가 싶다.
물~론 단점도 있다.
FragmentManager Transaction
비동기로 인해 예기치 않은 동작이 발생할 수 있다. (트랜잭션 내에서 문제가 발생한다면 디버그가 매우 어려운 illegalStateException을 발생시킨다)
Think About Lifecycle
Activity의 생명주기가 간단하지도 않은데 Fragment까지 더한다면 생명주기만 생각하더라도 매우 많은 고민거리다.
늘 그렇듯 개발에서의 정답은 없는 것 같다.
상황에 맞게 적절한 기술을 사용하고 그 상황에 왜 해당 기술을 택했는지 개발자가 스스로 이해해서 설명할 수 있다면 그게 정답일 것이다.
대신 이번 글을 정리하면서 Fragment의 독립성을 좀 더 높여서 개발해야겠다고 생각했다.
🖐 Fragment가 독립적으로 동작하는 것. 의존성을 분리하는 것.
developer