🔎 Lifecycle-Aware Components로 수명주기 관리

일반적으로 액티비티와 프래그먼트의 라이프사이클 메서드 안에서 종속 컴포넌트의 작업을 구현함.

👉 이러한 패턴은 코드의 구성을 나쁘게하고 오류가 증가하는 원인이 됨.

Lifecycle-aware 컴포넌트를 이용하면 종속 컴포넌트의 코드를 라이프사이클 메서드 밖으로 이동시킬 수 있음.
Lifecycle-aware 컴포넌트는 액티비티 및 프래그먼트의 라이프사이클 상태 변화에 따라 작업을 수행함. 이러한 컴포넌트들은 더 가볍고 조직화된 코드를 생산할 수 있게 해주고 관리를 쉽게 해줌.

internal class MyLocationListener(
        private val context: Context,
        private val callback: (Location) -> Unit
) {

    fun start() {
        // connect to system location service
    }

    fun stop() {
        // disconnect from system location service
    }
}

class MyActivity : AppCompatActivity() {
    private lateinit var myLocationListener: MyLocationListener

    override fun onCreate(...) {
        myLocationListener = MyLocationListener(this) { location ->
            // update UI
        }
    }

    public override fun onStart() {
        super.onStart()
        myLocationListener.start()
        // manage other components that need to respond
        // to the activity lifecycle
    }

    public override fun onStop() {
        super.onStop()
        myLocationListener.stop()
        // manage other components that need to respond
        // to the activity lifecycle
    }
}

위의 코드는 문제가 없어보이지만 라이프사이클의 현재 상태에 따라 UI 및 다른 컴포넌트를 관리하는 호출이 너무 많아지는 문제가 발생.

여러 컴포넌트를 관리할 경우 onStart() 및 onStop() 과 같은 라이프 사이클 메서드에 상당한 양의 코드를 작성하게 되어 유지보수가 어려워짐.

컴포넌트가 액티비티나 프래그먼트가 중지되기 전에 시작된다는 보장이 없음. (예를 들어 onStart()에서 설정 확인과 같은 긴 작업을 수행해야 할 경우)

onStop() 메서드가 onStart() 메서드보다 먼저 완료되어 컴포넌트가 필요 이상으로 오래 유지되는 경쟁상태(race condition)가 발생하게 됨.

개선된 코드

class MyActivity : AppCompatActivity() {
    private lateinit var myLocationListener: MyLocationListener

    override fun onCreate(...) {
        myLocationListener = MyLocationListener(this) { location ->
            // update UI
        }
    }

    public override fun onStart() {
        super.onStart()
        Util.checkUserStatus { result ->
            // what if this callback is invoked AFTER activity is stopped?
            if (result) {
                myLocationListener.start()
            }
        }
    }

    public override fun onStop() {
        super.onStop()
        myLocationListener.stop()
    }

}

📖 Lifecycle

라이프 사이클은 액티비티나 프래그먼트와 같은 컴포넌트의 생명주기 상태에 대한 정보를 보유하고 다른 객체들이 이 상태를 관찰할 수 있도록 해주는 클래스.

• Event
  프레임워크와 라이프사이클 클래스에서 전달되는 라이프사이클 이벤트. 이벤트는 액티비티와 프래그먼트의 콜백 이벤트와 매핑됨.

• State
  라이프사이클 객체에 의해 추적되는 구성요소의 현재 상태.

위 그림에서 State는 그래프의 노드, Event는 노드 사이의 엣지.

class MyObserver : DefaultLifecycleObserver {
    override fun onResume(owner: LifecycleOwner) {
        connect()
    }

    override fun onPause(owner: LifecycleOwner) {
        disconnect()
    }
}

myLifecycleOwner.getLifecycle().addObserver(MyObserver())

DefaultLifecycleObserver를 구현하고, onCreate onStart 등과 같은 매서드를 재정의하여 컴포넌트 라이프사이클 상태를 모니터링 할 수 있음.
Lifecycle 클래스의 addObserver() 메서드를 호출하여 옵저버 인스턴스를 전달하여 옵저버를 추가할 수 있음.

---

📖 LifecycleOwner

LifecycleOwner는 해당 클래스가 생명주기를 가지고 있다는 것을 나타내는 단일 메서드 인터페이스. getLifecycle()이라는 하나의 메서드를 가지며 해당 클래스에서 구현되어야 함.
Fragment 및 AppCompatActivity와 같은 개별 클래스로부터 라이프사이클 소유권을 추상화하고 이와 작동하는 컴포넌트를 작성할 수 있게 함.

owner는 라이프사이클을 제공하고 observer는 이를 등록하여 감시할 수 있기 때문에 DefaultLifecycleObserver를 구현하는 컴포넌트는 LifecycleOwner를 구현하는 컴포넌트와 원활하게 작동함.

⭐️ 예시 - 위치 추적 예제
MyLocationListener 클래스를 DefaultLifecycleObserver를 구현하도록 만들고 onCreate() 메서드에서 액티비티 라이프사이클을 초기화하도록 함.

👉 라이프사이클 상태변경에 대한 반응 로직이 액티비티가 아닌 MyLocationListener에 선언됨. 개별 컴포넌트가 자체 로직을 저장하도록 하는 것이 액티비티와 프래그먼트 로직을 관리하기 쉬움.

class MyActivity : AppCompatActivity() {
    private lateinit var myLocationListener: MyLocationListener

    override fun onCreate(...) {
        myLocationListener = MyLocationListener(this, lifecycle) { location ->
            // update UI
        }
        Util.checkUserStatus { result ->
            if (result) {
                myLocationListener.enable()
            }
        }
    }
}

일반적으로 현재 라이프사이클 상태가 좋지 않은 경우 특정 콜백을 호출하지 않도록 함.
-> 예: 액티비티 상태가 저장된 후(onSaveInstanceState) 프래그먼트 트랜잭션을 실행하는 콜백이 실행된다면 충돌이 일어날 수 있음.

위의 케이스를 간단하게 만들기 위해 Lifecycle 클래스는 다른 객체가 현재 상태를 조회할 수 있도록 허용.

internal class MyLocationListener(
        private val context: Context,
        private val lifecycle: Lifecycle,
        private val callback: (Location) -> Unit
): DefaultLifecycleObserver {

    private var enabled = false

    override fun onStart(owner: LifecycleOwner) {
        if (enabled) {
            // connect
        }
    }

    fun enable() {
        enabled = true
        if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) {
            // connect if not connected
        }
    }

    override fun onStop(owner: LifecycleOwner) {
        // disconnect if connected
    }
}

라이브러리가 안드로이드 생명주기와 함께 동작해야 하는 클래스를 제공한다면 lifecylce-aware-components 사용을 권장.

---

📖 커스텀 LifecycleOwner 구현

LifecylceOwner로 만들고 싶은 커스텀 클래스가 있다면 LifecycleRegistry 클래스를 사용할 수 있지만, 이벤트를 해당 클래스로 전달해야 함.

class MyActivity : Activity(), LifecycleOwner {

    private lateinit var lifecycleRegistry: LifecycleRegistry

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        lifecycleRegistry = LifecycleRegistry(this)
        lifecycleRegistry.markState(Lifecycle.State.CREATED)
    }

    public override fun onStart() {
        super.onStart()
        lifecycleRegistry.markState(Lifecycle.State.STARTED)
    }

    override fun getLifecycle(): Lifecycle {
        return lifecycleRegistry
    }
}

• LifecycleOwner 사용자 정의 커스텀 클래스

import androidx.lifecycle.Lifecycle
import androidx.lifecycle.LifecycleOwner
import androidx.lifecycle.LifecycleRegistry

class CustomLifecycleComponent : LifecycleOwner {
    private val lifecycleRegistry = LifecycleRegistry(this)

    init {
        // Initialize the lifecycle to CREATED state
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE)
    }

    fun start() {
        // Simulate starting the component
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START)
    }

    fun stop() {
        // Simulate stopping the component
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP)
    }

    fun destroy() {
        // Simulate destroying the component
        lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    }

    override fun getLifecycle(): Lifecycle {
        return lifecycleRegistry
    }
}

---

📖 lifecycle-aware components 권장사항

• UI 컨트롤러(액티비티, 프래그먼트)를 최대한 가볍게 유지. 데이터를 획득하려고 하지 않아야 하며, 대신 데이터를 획득하는데 ViewModel을 사용하고 LiveData 객체를 관찰하여 변경사항을 뷰에 반영해야 함.

• 데이터 주도형 UI를 작성하려고 할 것. UI 컨트롤러의 역할은 데이터가 변경될 때 뷰를 업데이트하거나 사용자 작업을 ViewModel로 알리는 것.

• 데이터 로직은 ViewModel 클래스에 둘 것. ViewModel은 UI 컨트롤러와 앱의 나머지 부분 간의 연결 역할을 해야 함. 하지만 ViewModel은 데이터를 가져오는 것(예를 들어 네트워크로부터)에 대한 책임은 없음. ViewModel은 데이터를 가져오기 위해 적절한 컴포넌트를 호출한 다음 결과를 UI 컨트롤러에 제공.

• 뷰와 UI 컨트롤러간의 깔끔한 인터페이스 유지를 위해 Data Binding을 사용할 것. 뷰를 보다 선언적으로 만들고 액티비티와 프래그먼트에서 작성해야하는 업데이트 코드를 최소화할 수 있음.
  Java로는 Butter Knife 같은 라이브러리 사용.

• 만약 UI가 복잡하다면 UI 수정을 처리하기 위한 프레젠터 클래스를 생성. UI 컴포넌트를 테스트하기 쉬워짐.

• ViewModel에서 View 또는 액티비티 컨텍스트를 참조하지 않도록 해야함. ViewModel이 액티비티 수명보다 길면(예를 들어 화면 회전 같은 구성 변경.) 액티비티가 가비지 컬렉터에 의해 제대로 폐기되지 않아 메모리 누수가 될 수 있음.

• 긴 실행 작업 및 다른 비동기 작업 관리를 위해 코루틴을 사용할 것.

---

📖 lifecycle-aware components 사용 사례

• 대략적인(coarse-grained) 위치와 세분화 된(fined-grained) 위치 업데이트 사이의 전환 시에 사용.
  라이프 사이클 컴포넌트를 사용하여 위치 앱이 화면에 표시되는 동안 세분화된 위치 업데이트를 활성화하고, 앱이 백그라운드로 이동할 때 대략적인 위치 업데이트로 전환.
  LiveData, lifecycle-aware 컴포넌트로 사용자가 위치를 변경할 때 앱이 UI를 자동으로 업뎃하도록 함.

• 비디오 버퍼링 중지 및 시작 시에 사용. lifecycle-aware 컴포넌트를 사용하여 버퍼링을 가능한 빨리 시작하고 앱이 완전히 시작할 때까지 재생 연기. 앱이 종료될 때 버퍼링을 빨리 중단하는데에도 사용됨.

• 네트워크 연결의 시작 및 중지에 사용. lifecycle-aware 컴포넌트를 사용하여 앱이 포그라운드에 있을 때 네트워크 데이터 라이브 업데이트(스트리밍)을 활성화, 앱이 백그라운드로 전환될 때 자동으로 일시중지되도록 함.

• 애니메이션 drawable의 일시 중지 및 재개. lifecycle-aware 컴포넌트를 사용하여 앱이 백그라운드에 있을 때 애니메이션 drawable을 일시중지하고 앱이 다시 포그라운드로 전환되면 drwable을 재개하는데 사용함.