프레그먼트(Fragment)를 처음 도입한것은 2011년 2월 에 등장한 Android 3.0(Honey comb, API11) 부터다. 안드로이드 등장 초기부터 함께 했기 때문에 프레그먼트를 모르는 안드로이드 개발자는 없을 것으로 생각된다.
하지만, 어떤 UI/UX를 구현하기전에 의문이 들때가 있다.
“액티비티(Activity)와 프레그먼트 중 어느것으로 구현하는게 맞는거지?”
모든 시나리오를 만족하는 정답은 없다. 상황에 따라 액티비티 또는 프레그먼트가 더 나은 선택이 될 수 있다. 액티비티와 프레그먼트 사이에서 고민하는 사람을 위해 선택에 도움이 될만한 몇가지 사항들을 알아보자.
유연한 UI/UX 구현
프레그먼트는 기본적으로 태블릿과 같은 큰화면에서 역동적이고 유연한 UI디자인을 지원하는것이 목적이었다. 태블릿의 화면은 휴대폰 화면보다 훨씬 크기 때문에 UI 구성요소 조합과 표현할 공간이 더 많다.
프레그먼트를 사용하면 앞의 그림과 같이 Master-Detail 구조를 갖는 구현을 손쉽게 구현할 수 있다.
이 외에도 NavigationDrawer, BottomSheetDialog, Navigation Component 등을 구현할 때 프레그먼트가 사용된다.
재사용성 증가
View 또는 비즈니스로직을 프레그먼트 단위로 분리 할 수 있다. 아키텍처 원칙에서 가장 중요한 원칙인 관심사 분리를 통해 의존성을 분리하고 독립성을 키우게 되는 것이다. 이러한 부분을 잘 이용하면 프레그먼트로 구현한 내용을 다른 액티비티 또는 프레그먼트에서 재사용할 수 있다. 일례로 DialogFragment를 확장한 클래스는 FragmentManager만 제공하면 어느 곳에서나 다이얼로그를 노출 할 수 있게 된다. 하지만 프레그먼트가 특정 액티비티 또는 프레그먼트에 의존적이라면 재사용하기 힘들다.
퍼포먼스 관점
액티비티는 무겁다. 물론 액티비티를 초기화하는데 몇초씩 걸리는 것은 아니지만 프레그먼트와 비교할 때 상대적으로 무겁다라고 할 수 있다. 그렇다고 액티비티가 필요없는 것은 아니다. 프레그먼트는 단독으로 존재할 수 없으며, 반드시 액티비티 내에서 호스팅되어야 한다. 액티비티내에서 프레그먼트는 상대적으로 가볍게 추가/제거가 가능하다. 그렇기 때문에 액티비티 스택에 액티비티를 쌓아두는 것보다 프레그먼트 백스택에서 프레그먼트를 관리하는 것이 메모리 관리면에서도 효율적이며, 화면전환도 액티비티보다 더 순조롭게 할 수 있다.
데이터 공유하기
액티비티간 데이터를 공유하는 가장 일반적인 방법은 인텐트(Intent)를 사용하는 방법 밖에 없다.
(싱글톤 사용 및 애플리케이션 내 객체 공유 등의 특수한 경우는 고려하지 않는다.)
액티비티는 다른 프로세스에서 실행하는 것을 염두하고 설계 되었기 때문에 메모리 영역을 공유하지 않는다. 그렇기 때문에 리눅스 커널 레벨에서 프로세스 간 통신(IPC)을 하게 되는데, 이 부분에서 많은 제약사항이 생기며 메모리를 직접 공유하는 것보다 퍼포먼스가 많이 떨어지게 된다. 프레그먼트를 사용하는 경우 프레그먼트 간 데이터 공유는 액티비티내에서 자유롭게 이루어진다. 물론 코드베이스에서 데이터를 전달하는 과정이 복잡해 보일 수 있지만, ViewModel 또는 DI 프레임워크 사용으로 이 부분을 좀 더 매끄럽게 만들 수도 있다. 이 부분은 이전에 작성한 ‘프레그먼트간 통신’ 편을 참고하자.
생명주기
액티비티와 프레그먼트는 각각 고유의 생명주기를 갖는다. 둘의 생명주기는 비슷하지만 프레그먼트의 생명주기를 이해하기 위해서는 액티비티 생명주기 또한 숙지하고 고려해야한다. 이 부분에서 많은 개발자들이 혼란을 겪게 된다. 액티비티가 언제 파괴/재생성 될지도 모르는데 그 안에서 프레그먼트의 파괴/재생성까지 신경쓰려니 복잡해 질 수 밖에 없다. lifecycle 컴포넌트를 사용함으로써 많은 어려움을 해소할 수 있다.
결론
프레그먼트의 사용은 많은 장점을 가져오지만, 프레그먼트 매니저의 트랜잭션을 직접 다루는 경우 예기치 않은 동작이 발생하는 경우도 생긴다. 이러한 특징 때문에 프레그먼트의 사용을 반대하고 액티비티와 커스텀뷰만 쓰자는 반대파도 생겼었다.
구글에서 공식적으로 제공하는 라이브러리와 샘플 코드들은 프레그먼트 사용에 기반을 두고 있으며, 꾸준히 프레그먼트를 사용하기를 권장하고 있기 때문에 이에 반대하는 개발을 하는것은 또 다른 고통의 연속이 될 것이다.
모든 화면을 꼭 단일 액티비티에 다중 프레그먼트로 구성할 필요는 없지만, 적절한 프레그먼트 사용은 다방면에서 많은 혜택을 가져다 줄 것이다.
