처음 배울 때는 Scroll View와 LinearLayout을 이용하여 Data List를 보여주었다.
나쁘지 않다 생각했으나 아무것도 모를 때이기에 그렇게 생각했다ㅋㅋ
여기서 한 단계 더 배워 Adapter View를 배워서 ListView와 GridView를 통해 아이템들을 보여주었다.
그래 이거지,, 동적으로 추가도 가능해지며 좀 더 그럴 듯 해보였다.
그 전에 스크롤 뷰에서 아이템의 위치 값을 이용하기 위해 intent로 쌩쇼를 한게 부끄러울 정도다.
하지만 이런 ListView와 GridView도 문제점을 가지고 있었다.
Data가 100개, 1000개, 10000개라면?? 혹은 Data가 동적으로 계속 변경된다면?
앱은 과부하되어 실행되지 않을 수 있겠다...
왜냐하면 기존의 ListView나 GridView는 밑으로 스크롤 할 때마다 위에 있던 아이템은 삭제되고, 맨 아래의 아이템은 생성 되길 반복하기 때문이다. 한 마디로 비효율적으로 일을 하는 형태이다.
이런 단점을 보완하기 위해 나온 이름하야 리사이클러 뷰!!
RecyclerView란?
리사이클러 뷰는 현재 현업에서 리스트 형태의 Data를 표시하는데 무조건 쓰이는 가장 최신의 위젯이다.
아래 그림과 같이 리스트를 스크롤 할 때, 위에 있던 아이템은 재활용 돼서 아래로 이동하여 재사용 한다.
많은 아이템을 효율적으로 관리하고 보여주는 역할을 한다.
Recycler View를 사용할 땐 3가지가 필요하다.
1. LayoutManager
LayoutManager는 RecyclerView 내부의 아이템들이 어떻게 배치될지를 결정한다.
기본 제공되는 **LayoutManager**로는 LinearLayoutManager, GridLayoutManager, StaggeredGridLayoutManager 등이 있다.
recyclerView.layoutManager = LinearLayoutManager(this) // 수직 리스트를 위한 LinearLayoutManager
// 또는
recyclerView.layoutManager = GridLayoutManager(this, 2) // 2열 그리드를 위한 GridLayoutManager
2. RecyclerView.Adapter
RecyclerView에 표시될 데이터와 해당 데이터를 보여줄 ViewHolder를 연결한다.
Adapter는 데이터셋의 변경 사항을 RecyclerView에 알리고, 데이터를 기반으로 뷰를 생성합니다.
class MyAdapter(private val dataList: MutableList<String>) : RecyclerView.Adapter<MyAdapter.MyViewHolder>() {
inner class MyViewHolder(view: View) : RecyclerView.ViewHolder(view) {
val textView: TextView = view.findViewById(R.id.textView)
val thumbnailView: ImageView = view.findViewById(R.id.thumbnail)
}
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
val itemView = LayoutInflater.from(parent.context).inflate(R.layout.item_view, parent, false)
return MyViewHolder(itemView)
}
override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
Log.d("RecycleView", "onBindViewHolder :$position")
holder.textView.text = dataList[position]
holder.thumbnailView.setImageUri(dataList[position].thubnailUrl)
}
override fun getItemCount() = dataList.size
// 데이터 추가
fun addItem(data: String) {
dataList.add(data)
notifyItemInserted(dataList.size - 1)
}
// 데이터 삭제
fun removeItem(position: Int) {
if (position < dataList.size) {
dataList.removeAt(position)
notifyItemRemoved(position)
}
}
}
3. ViewHolder
RecyclerView의 개별 아이템 뷰를 위한 객체이다.
아이템 뷰의 모든 서브 뷰를 담고 있어 재사용과 성능 최적화에 도움을 준다.
inner class MyViewHolder(view: View) : RecyclerView.ViewHolder(view) {
val thumbnailView: ImageView = view.findViewById(R.id.thumbnailView)
val titleView: TextView = view.findViewById(R.id.titleView)
// 여기에 필요한 다른 뷰를 추가할 수 있다.
}
안드로이드 앱의 사용자 인터페이스(UI) 일부를 나타내는 모듈화된 컴포넌트이다. 라고 하면 확 와닿지 않는다.
내 개인적인 이해를 가지고 예시를 들어 설명을 하자면, 퍼즐과 비슷한 것 같다.
액티비티가 한 폭의 그림이 담긴 큰 틀이라고 한다면, 프래그먼트는 그 그림을 이루는 퍼즐 조각같은거다.
우선 프래그먼트라는 개념이 나오게 된 배경을 알아보자.
예전에는 핸드폰이 나왔을 때 대부분 비슷비슷한 화면이었다. 근데 지금을 보자면 핸드폰 자체도 화면 크기가 굉장히 다양하다. 갤럭시 노트와 아이폰 미니만 비교해봐도 꽤나 큰 차이다. 그런데 폴드니,, 플립이니,, 뭐니 제각각 개성을 갖춘 녀석들이 등장하기도 하고 태블릿, 스마트TV, 스마트워치 등이 등장하면서 다양한 화면 크기에 대응해야하는 시기가 와버린 것이다.
다양한 화면 크기에 대응하기 위해서는 화면을 동적으로 조절하고 유연하게 대응해야 할 필요가 있다. 이와 더불어 개발 측면에서도 기능을 모듈화시키고 각각 따로 떼어내는 추세이기에 그에 따라 화면도 여러개로 나누어 조합하여서 다양한 레이아웃을 생성할 수 있도록 하는 모듈화와 재사용성을 높일 필요가 있었다. 이러한 요구사항에 부합하도록 도입된 것이 프래그먼트이다.
요새 앱 환경도 웹의 SPA(Single Page Application) 같이 메인 액티비티 1~2개에 여러 개의 프래그먼트를 사용해서 화면을 구현하는 편이라고 한다.
프래그먼트 특징
1. Jetpack Library Navigation / Viewpager 와 같은 아주 유용한 라이브러리들이 프래그먼트로 사용하도록 설계되어서 함께 사용하면 아주 편리하게 화면을 구성할 수 있다.
2. 액티비티 내에서 여러 프래그먼트가 동작할 때, 각 프래그먼트 간에는 직접적인 통신이 가능하다. 이를 통해 모듈 간의 상호작용이 가능하다.
3. 화면을 여러개의 프래그먼트로 나눠서 다양한 레이아웃을 생성 가능하고 여기 저기 쓸 수 있으니 재사용성에도 기여한다. (화면이 작은 디바이스면 프래그먼트 하나 딱 보여주고 화면이 크면 프래그먼트 여러 개 띄어서 보여준다.) + 동적인 UI 업데이트
4. 액티비티는 안드로이드 시스템에서 직접 관리하지만 프래그먼트는 프래그먼트 매니저가 간접적으로 관리한다.
이를 통해 메모리 리소스가 상대적으로 덜 소모된다고 한다.
5. 액티비티안에 종속되지만 자체적인 생명주기를 가지고 있다.
프래그먼트의 생명주기를 왜 이해해야하는가?
이 정도 대충 읽으면 프래그먼트가 대세구만! 하는 느낌이 온다. 그럼 이제 잘 사용하고 싶어진다. 프래그먼트를 잘 사용하려면 프래그먼트의 생명주기를 잘 이해해야한다.
또한, 메모리 누수를 방지하기 위해서 프래그먼트의 각 단계별 상황에서 어떤 적절한 액션을 취해서 대처해야할지 알아야 하기에 잘 이해해놓아야 한다.
메모리 누수(Memory Leak) 란 한정된 자원을 가진 프로그램이 할당한 메모리를 제대로 해제하지 않아 발생하는 현상이다.
즉, 일꾼들에게 작업공간을 주고서 작업이 다 끝났으면 다시 다른 일꾼에게 그 공간을 잘 할당해주어야 하는데 노는 공간이 많이 발생하면서 계속 누적되고 시스템 자원이 낭비되고 결국 성능에 악영향을 끼치는 현상이다.
우리가 객체를 참조하고 더 이상 쓰지 않거나 필요하지 않은 시점에선 적절하게 메모리를 해제시켜야 성능과 안정성을 높일 수 있다. 그런 시점을 알려면? 생명주기 이해 해야한다!
위 그림은 안드로이드 공식 문서에서 제공한 그림이다. 보면 프래그먼트의 자체의 생명주기(왼쪽)와 프래그먼트 뷰의 생명주기를 구분해서 표현한다. 이 둘 주기의 차이점을 잘 파악해두면 메모리 누수나 런타임 오류를 방지할 수 있다.
우선 액티비티 생명주기와의 콜백함수 차이점을 보면 onCreateView() onCreatedView(), onViewStateRestored() 와 onSaveInstanceState(), onDestroyView()가 있다.
차이점만 인지하고 이제 생명주기를 알아보자.
onAttach() & onCreate()
(+내 메모리에 잘 넣기 위해서 조금 각색해보았다. 정확한 표현이 아닐 수 있기에 (?) 표시해두었다.)
Fragment의 압축파일(?) 같은 녀석이 프래그먼트 매니저를 통해서 호스트 액티비티에 attach되고, onAttach() 작업이 완료되면 onCreate()에서 프래그먼트 자체가 압축해제(?) 되어 생성된다.
생명주기 그림을 보면 알겠지만 아직 프래그먼트 뷰 생성 전이므로 뷰와 관련된 작업을 이 메소드에서 진행하는건 적절하지 않다.
한줄 요약
onAttach() -> 프래그먼트가 호스트 액티비티에 attach 된다.
onCreate() -> attach된 프래그먼트 자체가 생성된다.
onCreateView & onViewCreated()
onCreateView에서 프래그먼트 뷰가 초기화되고 완료됨과 동시에 onViewCreated()를 호출하여 완전히 생성된 뷰 객체를 반환한다. onCreateView에서 레이아웃을 inflate 하기에 뷰 객체들을 참조할 수 있지만, 안정적으로 뷰 객체의 생성이 보장이 된 onViewCreated에서 참조하는 것이 안전하다. (+ 여기에서 findViewById, 뷰 바인딩, LiveData 옵저빙, 각종 어댑더 세팅하면 된다.)
이제 슬슬 생명주기를 왜 알아야하는지 감이 오기 시작하죠?? (어디서 어떤 처리를 해야하는지 알겠죠?)
onCreateView() - > 프래그먼트 뷰 초기화 + 뷰 객체 반환
onViewCreated() -> 뷰의 생성 완료를 보장
onViewStateRestored()
프래그먼트의 상태를 복원할 때 호출된다. 프래그먼트의 뷰 계층 구조와 연관된 상태를 복원하는데 사용된다.
많은 블로그에서 이렇게 설명한다. 사실 이렇게 들으면 초보입장에서는 알아듣기 힘든 것 같다.
우선, 이 콜백메소드는 일반적으로 프래그먼트가 소멸되고 다시 생성될 때 호출된다.
쉽게 이야기하자면, 우리가 앱을 보다가 잠시 떠났다가 들어왔을 때 다 초기화되어있을 수도 있지만 요즘 앱들은 내가 나갔다가 와도 내가 보던 그 화면 위치, 내가 작성하던 텍스트 등 포커싱 아웃 전 내 UI 현재 상태를 유지하고 있다.
그 상태들을 복원시킬 때 쓰이는게 이 메소드다.
onViewStateRestored() - > 소멸된 프래그먼트 상태 복원
onStart()
프래그먼트가 사용자에게 보여질 수 있을 때 호출되며 이 때부터 사용자에게 프래그먼트 뷰가 보이게 된다. 이 시점부터 프래그먼트는 자식 프래그먼트매니저를 통해 프래그먼트의 추가, 교체, 제거 등의 작업으로 관리되어진다.
onResume()
액티비티와 마찬가지로 onResume() 부터 사용자와 상호작용할 수 있는 상태이다. 이 때 상호작용에 필요한 작업을 수행하면 된다.
onPause()
프래그먼트가 일시 중지될 때 호출된다.
onPause()에서는 사용자와의 상호작용이 중단되는 시점에서 필요한 작업을 수행한다.
onStop()
프래그먼트가 사용자에게 더 이상 표시되지 않을 때 호출된다.
onStop()에서는 UI 업데이트 및 리소스 정리와 같은 작업을 수행한다.
onSaveInstanceState()
프래그먼트가 소멸되기 전에 호출되며, 프래그먼트의 현재 상태를 저장하는 데 사용됩니다. 주로 화면 회전이나 다른 구성 변경 시에 발생하는 프로세스의 재시작으로부터 데이터를 보존하고 복원하는 데 활용됩니다.
onDestroyView()
프래그먼트의 뷰 계층 구조가 소멸될 때 호출됩니다.
onDestroyView()에서는 UI와 관련된 자원을 해제하는 작업을 수행합니다.
onDestroy()
프래그먼트가 소멸될 때 호출됩니다.
onDestroy()에서는 필요한 자원을 해제하고 정리하는 작업을 수행합니다.
onDetach()
프래그먼트가 액티비티에서 분리될 때 호출됩니다.
onDetach()에서는 프래그먼트가 속한 액티비티에 대한 참조를 해제하는 작업을 수행합니다.
