2025년 7월 30일, Androidx Lifecycle 2.10.0-alpha01 버전이 릴리즈 되었습니다. 눈길을 끌었던 변화로는 LifecycleOwner 컴포저블이 새롭게 나왔던 것인데요, 왜 이 Composable이 새롭게 등장했는지 분석을 해보고자 합니다.

기존 LocalLifecycleOwner가 제공하는 값은 무엇일까?

가장 먼저 든 생각은, Compose에서 LifecycleOwner가 제공하는 값이 무엇일까에 대한 것입니다. 이 내용은 ProvideAndroidCompositionLocals라는 함수를 보고 알 수 있는데요

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@Composable
@OptIn(ExperimentalComposeUiApi::class)
internal fun ProvideAndroidCompositionLocals(
    owner: AndroidComposeView,
    content: @Composable () -> Unit,
) {
    val view = owner
    val viewTreeOwners =
        owner.viewTreeOwners
            ?: throw IllegalStateException(
                "Called when the ViewTreeOwnersAvailability is not yet in Available state"
            )
    // ...
    CompositionLocalProvider(
        // ...
        LocalLifecycleOwner provides viewTreeOwners.lifecycleOwner,
        // ...
    ) {
        ProvideCommonCompositionLocals(/* UN-IMPORTANT */)
    }
}

LocalLifecycleOwner가 viewTreeOwners.lifecycleOwner를 제공하고 있습니다.

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
internal class AndroidComposeView(context: Context, coroutineContext: CoroutineContext) :
    ViewGroup(context) {

    // ...
    
    @OptIn(ExperimentalComposeUiApi::class)
    override fun onAttachedToWindow() {
        val lifecycleOwner = findViewTreeLifecycleOwner()
        if (/* UN-IMPORTANT */) {
            if (lifecycleOwner == null) {
                throw IllegalStateException(
                    "Composed into the View which doesn't propagate ViewTreeLifecycleOwner!"
                )
            }
            // ...
            lifecycleOwner.lifecycle.addObserver(this)
            val viewTreeOwners =
                ViewTreeOwners(
                    lifecycleOwner = lifecycleOwner,
                    savedStateRegistryOwner = savedStateRegistryOwner,
                )
            _viewTreeOwners = viewTreeOwners
            // ...
        }
    }
}

viewTreeOwners는 View의 findViewTreeLifecycleOwner() 라는 것을 확인할 수 있습니다.

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
    /**
     * Sets the view tree owners before setting the content view so that the inflation process and
     * attach listeners will see them already present.
     */
    @CallSuper
    open fun initializeViewTreeOwners() {
        window.decorView.setViewTreeLifecycleOwner(this)
        window.decorView.setViewTreeViewModelStoreOwner(this)
        window.decorView.setViewTreeSavedStateRegistryOwner(this)
        window.decorView.setViewTreeOnBackPressedDispatcherOwner(this)
        window.decorView.setViewTreeFullyDrawnReporterOwner(this)
        window.decorView.setViewTreeNavigationEventDispatcherOwner(this)
    }

그리고 viewTreeOwners가 제공하는 LifecycleOwner는 Activity, Fragment가 설정한 것에 따라, window.decorView에서 얻을 수 있는 LifecycleOwner를 사용하는 것임을 알 수 있습니다.

그렇다는 것은, 하나의 Activity 내에서 사용하는 모든 Composable들은 LifecycleOwner를 공유하고 있다는 것을 알 수 있습니다.

LifecycleOwner를 따로 두어야 하는 경우를 상정해보자

하나의 Activity 위에 떠있는 Composable들이 하나의 LifecycleOwner를 공유하는 것은 어떤 문제를 야기하기 때문에 안드로이드 팀에서 LifecycleOwner Composable을 따로 제작했을 것입니다. 그렇다면 어떤 문제를 생각해볼 수 있을까요? 이는 안드로이드 팀에서 이 기능을 제작할 때 올린 PR의 설명을 확인하면 알 수 있습니다.

This logic was originally implemented in SinglePaneNavDisplay (see aosp/3517756) to ensure screen lifecycles were correctly managed during transitions. By making it a standalone composable, its utility is broadened beyond navigation.

It can now be used to scope lifecycles for any component (e.g., MapView, video player) that requires its own lifecycle management, capped at a specific max state.

조금 더 확실하게 하기 위해 이 글에 링크된 PR의 설명도 읽어보겠습니다.

SinglePaneNavDisplay only displays one screen at a time and that screen should be RESUMED.

However, since the transition between screens takes a non-zero amount of time, there is a brief time when both screens on visible and interactive. In this case, we don't want both screens to be RESUMED during the transition.

Instead, we want our Lifecycle.State to be:

RESUMED only if that screen is on the back stack and 'settled' (no transition running)

STARTED only if that screen is on the back stack and in the middle of a transition

CREATED if the screen is no longer on the back stack (e.g., it has been popped) and is in the middle of a transition

This has the added benefit that existing APIs like dropUnlessResumed automatically start working, avoiding accidental double clicks.

We can use the APIs provided by NavLocalProvider to install a LocalLifecycleOwner that uses the current transition state and the state of the back stack as the input into the max Lifecycle.State, enforcing the above requirements.

This first approach uses the existence of the key on the back stack as a signal that it is on the back stack since there's no way to tell two identical keys apart when you only have a NavEntry.

위의 내용들을 정리를 해보자면

하나의 Composable 스택에서 Composable이 pop되고 새로운 Composable이 들어오는 경우에 이탈되는 Composable, 새롭게 들어오는 Composable 모두 RESUMED 상태로 화면전환이 이뤄지고 있는 것입니다. 만약 Composable 스택에 쌓인 화면 내에 영상이나 MapView와 같이 기기 리소스를 많이 사용하는 화면이 그려진다면, 짧은 시간이지만 기기의 리소스를 잡아먹어서 예상치 못한 에러가 발생하거나 발열이 발생하는 등의 사용성에 문제를 줄 수 있습니다.

그러면 안드로이드 팀에서는 LifecycleOwner Composable로 어떻게 Composable들을 Lifecycle 상태를 관리할 수 있었을까요?

LifecycleOwner Composable 분석하기

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
@Composable
public fun LifecycleOwner(
    maxLifecycle: State = RESUMED,
    parentLifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
    content: @Composable () -> Unit,
) {
    val childLifecycleOwner = remember(parentLifecycleOwner) { ChildLifecycleOwner() }

    // Pass LifecycleEvents from the parent down to the child.
    DisposableEffect(childLifecycleOwner, parentLifecycleOwner) {
        val observer = LifecycleEventObserver { _, event ->
            childLifecycleOwner.handleLifecycleEvent(event)
        }

        parentLifecycleOwner.lifecycle.addObserver(observer)

        onDispose { parentLifecycleOwner.lifecycle.removeObserver(observer) }
    }

    // Ensure that the child lifecycle is capped at the maxLifecycle.
    LaunchedEffect(childLifecycleOwner, maxLifecycle) {
        childLifecycleOwner.maxLifecycleState = maxLifecycle
    }

    // Now install the LifecycleOwner as a composition local.
    CompositionLocalProvider(LocalLifecycleOwner provides childLifecycleOwner, content = content)
}

/**
 * A private [LifecycleOwner] that is controlled by a parent's lifecycle and capped by a maximum
 * state.
 */
private class ChildLifecycleOwner : LifecycleOwner {

    private val lifecycleRegistry = LifecycleRegistry(this)

    override val lifecycle = lifecycleRegistry

    // Tracks the last known state from the parent lifecycle.
    private var parentLifecycleState: State = State.INITIALIZED

    // The maximum state this lifecycle can enter.
    var maxLifecycleState: State = State.INITIALIZED
        set(value) {
            field = value
            updateLifecycleState()
        }

    fun handleLifecycleEvent(event: Lifecycle.Event) {
        parentLifecycleState = event.targetState
        updateLifecycleState()
    }

    private fun updateLifecycleState() {
        // The child's state is capped at the minimum of the parent's state and the max state.
        // For example, if parent is RESUMED and max is STARTED, the child state becomes STARTED.
        lifecycleRegistry.currentState =
            if (parentLifecycleState.ordinal < maxLifecycleState.ordinal) {
                parentLifecycleState
            } else {
                maxLifecycleState
            }
    }
}

내용이 길지만 주요 코드 위주로 분석을 해보도록 하겠습니다.

우선 LifecycleOwner 내부에서 독자적인 LifecycleOwner를 만들고 있다는 것을 볼 수 있습니다.

kotlin

1

2

3

val childLifecycleOwner = remember(parentLifecycleOwner) { 
    ChildLifecycleOwner() 
}

DisposableEffect에서 childLifecycleOwner의 Lifecycle은 parentLifecycleOwner(기존 LifecycleOwner)에 의해 조절되는 것을 알 수 있습니다.

                        Auto (kotlin)
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
private class ChildLifecycleOwner : LifecycleOwner {

    private var parentLifecycleState: State = State.INITIALIZED
  
    fun handleLifecycleEvent(event: Lifecycle.Event) {
        parentLifecycleState = event.targetState
        updateLifecycleState()
    }

    private fun updateLifecycleState() {
        lifecycleRegistry.currentState =
            if (parentLifecycleState.ordinal < maxLifecycleState.ordinal) {
                parentLifecycleState
            } else {
                maxLifecycleState
            }
    }
}

그러면 이 LifecycleOwner를 적용한 실제 예시도 한번 볼까요?

NavDisplay 분석

이 Composable이 적용된 것은 Navigation 3의 NavDisplay Composable입니다.

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@Composable
public fun <T : Any> NavDisplay(
    backStack: List<T>,
    modifier: Modifier = Modifier,
    // ...
) {
    var isSettled by remember { mutableStateOf(true) }
    val transitionAwareLifecycleNavEntryDecorator =
        transitionAwareLifecycleNavEntryDecorator(backStack, isSettled)

    DecoratedNavEntryProvider(
        backStack = backStack,
        entryDecorators = entryDecorators + transitionAwareLifecycleNavEntryDecorator,
        entryProvider = entryProvider,
    ) { entries ->
        // ...
    }
}

여기서 transitionAwareLifecycleNavEntryDecorator 에서 LifecycleOwner를 사용하고 있습니다.

                        kotlin
                    
1
2
3
4
5
6
7
8
9
10
11
12
@Composable
internal fun transitionAwareLifecycleNavEntryDecorator(backStack: List<Any>, isSettled: Boolean) =
    navEntryDecorator<Any> { entry ->
        val isInBackStack = entry.isInBackStack(backStack)
        val maxLifecycle =
            when {
                isInBackStack && isSettled -> Lifecycle.State.RESUMED
                isInBackStack && !isSettled -> Lifecycle.State.STARTED
                else /* !isInBackStack */ -> Lifecycle.State.CREATED
            }
        LifecycleOwner(maxLifecycle = maxLifecycle) { entry.Content() }
    }

즉 위의 상황을 다시 보면

이렇게 화면 전환이 없는 Composable의 상태는 RESUMED로, 스택에서 화면 전환이 이뤄지고 있는 화면들은 CREATED, STARTED와 같은 상태로 기존 View 기반 화면들의 로직을 그대로 승계하고 있다는 것을 알 수 있습니다.

참조

3705848: Add LifecycleOwner composable | https://android-review.googlesource.com/c/platform/frameworks/support/+/3705848
3517756: Add transition aware LifecycleOwner to SinglePaneNavDisplay | https://android-review.googlesource.com/c/platform/frameworks/support/+/3517756
3708610: Update NavEntryDecorators | https://android-review.googlesource.com/c/platform/frameworks/support/+/3708610
cs.android.con — NavDisplay | https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:navigation3/navigation3-ui/src/commonMain/kotlin/androidx/navigation3/ui/NavDisplay.kt?q=NavDisplay&ss=androidx%2Fplatform%2Fframeworks%2Fsupport:navigation3%2Fnavigation3-ui%2Fsrc%2FcommonMain%2Fkotlin%2Fandroidx%2Fnavigation3%2F