24.01.03 프래그먼트 바인딩 방식의 차이

KSang·2024년 1월 3일

목록 보기

24/101

그 외 복습

프래그먼트 바인딩 방식의 차이

private val binding by lazy { FragmentFirstBinding.inflate(layoutInflater) }
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
// Inflate the layout for this fragment
return binding.root
}

private var _binding: FragmentSecondBinding? = null
private val binding get() = _binding!!
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View {
_binding = FragmentSecondBinding.inflate(inflater,container,false)
// Inflate the layout for this fragment
return binding.root
}

첫 번째 방식에서는 lazy 위임을 사용하여 FragmentFirstBinding 객체를 초기화함.
이 방식은 프래그먼트의 뷰가 생성될 때까지 바인딩 객체의 초기화를 지연시킨다.
그러나 onDestroyView에서 바인딩 객체를 null로 설정하지 않기 때문에 메모리 누수가 발생할 수 있다.
프래그먼트의 뷰가 파괴되더라도 바인딩 객체는 계속 메모리에 남아있을 수 있기 때문.
간편해서 실무에서도 자주쓰는 방식이고 기본적인 방식이라고함
캠프 단계에선 이것만 써도 무방하다
두 번째 방식에서는 nullable한 _binding 변수를 사용하여 FragmentSecondBinding 객체를 초기화하고,
non-null한 binding 속성을 통해 바인딩 객체에 접근
이 방식은 onDestroyView에서 _binding을 null로 설정하여 메모리 누수를 방지한다
프래그먼트의 뷰가 파괴될 때 _binding을 null로 설정함으로써 바인딩 객체가 더 이상 메모리에 남아있지 않도록 함.
앱의 위젯이 많고 복잡해지면 쓰게 되는 방식
메모리활용에 효율적이지만 캠프수준에선 위에 방식과 크게 차이는 나지 않는다고한다
캠프 단계에선 위에것만 써도 무방함

프래그먼트 뷰가 파괴될때

다른 프래그먼트로 이동할 때: 프래그먼트를 교체하거나 스택에서 제거할 때, 현재 프래그먼트의 뷰는 파괴

액티비티가 닫힐 때: 액티비티가 종료되면 그 안에 포함된 모든 프래그먼트의 뷰도 파괴

백스택에서 복구될 때: 프래그먼트를 백스택에 추가하고 나서 사용자가 뒤로 가기 버튼을 눌러 이전 상태로 돌아갈 때, 프래그먼트의 뷰는 파괴되고 다시 생성.

구성 변경 시: 사용자가 디바이스를 회전하거나 키보드를 표시/숨기는 등의 작업을 수행하여 액티비티가 재생성되면, 그 안에 포함된 모든 프래그먼트의 뷰도 파괴되고 다시 생성

메인 페이지에서 의문

private fun setFragment(frag: Fragment) {
        supportFragmentManager.commit {
            replace(R.id.frameLayout, frag) // 프레임 레이아웃에 프래그먼트 뿌리겠다
            setReorderingAllowed(true)
            addToBackStack("")
        }
    }