2-1장 Compose 컴파일러(The Compose Compiler) - Compose Annotations

[ldh019]

[ldh019]

1. NonRestartableComposable 사용하기 좋은 예시 or 상황
2. Immutable 과 Stable이 Compose Compile 타임에 어떻게 동작하는지

[lee-ji-hoon]

NonRestartableComposable 사용하기 좋은 예시 or 상황

LaunchedEffect**와 같은 Effect API는 NonRestartableComposable을 사용하는 대표적인 예시

• LaunchedEffect는 컴포저블 함수가 최초로 구성되었을 때, 또는 지정된 키 값이 변경되었을 때 한 번 실행되는 코루틴
• 특정 상태가 변경되거나 UI의 재구성과는 상관없이 한 번만 실행되어야 하는 작업에 매우 적합
• NonRestartableComposable을 사용하면 불필요한 재구성으로 인한 LaunchedEffect의 불필요한 재시작을 방지

@Composable
@NonRestartableComposable
@OptIn(InternalComposeApi::class)
fun LaunchedEffect(
    ...
    block: suspend CoroutineScope.() -> Unit
) {
  ...
}

---

Immutable 과 Stable이 Compose Compile 타임에 어떻게 동작하는지

@immutable과 @stable 어노테이션은 컴파일러에게 객체의 안정성 정보를 제공하여 불필요한 재구성을 방지하고 성능을 향상시킴

Stability 클래스 구조

컴파일러는 안정성을 표현하기 위해 Stability라는 sealed class를 사용하며
이 클래스는 다양한 안정성 상태를 나타냄.

sealed class Stability {
    class Certain(val stable: Boolean) : Stability()
    class Runtime(val declaration: IrClass) : Stability()
    class Unknown(val declaration: IrClass) : Stability()
    class Parameter(val parameter: IrTypeParameter) : Stability()
    class Combined(val elements: List<Stability>) : Stability()

    // 연산자 오버로딩으로 Stability를 합치는 기능
    operator fun plus(other: Stability): Stability { /*...*/ }

    companion object {
        val Stable: Stability = Certain(true)
        val Unstable: Stability = Certain(false)
    }
}

• Certain: 안정성이 확실한 경우 (stable이 true이면 안정적)
• Runtime: 안정성이 런타임에 결정되는 경우
• Unknown: 안정성을 알 수 없는 경우
• Parameter: 타입 파라미터의 안정성
• Combined: 여러 안정성 요소의 조합

@immutable과 @stable의 역할

@immutable

• 정의: 객체가 완전히 불변(immutable)임을 나타냄
• 의미: 객체의 모든 프로퍼티가 불변이며, 상태 변화가 전혀 없음을 보장
• 컴파일러 동작: 해당 타입을 사용하는 Composable 함수는 해당 객체로 인해 재구성되지 않음

Stable

• 객체가 안정적이며(Stable), 상태 변화가 Compose에 의해 추적될 수 있음을 나타냄.
• 객체의 프로퍼티가 변경될 수 있지만, 변경 시 Compose가 이를 감지하고 필요한 재구성을 수행할 수 있음
• Compose는 해당 객체의 상태 변화를 효율적으로 추적하여 필요한 경우에만 재구성을 수행

StabilityInferencer의 안정성 추론 과정

StabilityInferencer 클래스는 컴파일 타임에 타입의 안정성을 추론하는 핵심 로직을 담고 있음

class StabilityInferencer(
    private val currentModule: ModuleDescriptor,
    externalStableTypeMatchers: Set<FqNameMatcher>,
) {

    // 안정성 추론 함수들
    fun stabilityOf(irType: IrType): Stability { /*...*/
    }

    private fun stabilityOf(
        declaration: IrClass,
        substitutions: Map<IrTypeParameterSymbol, IrTypeArgument>,
        currentlyAnalyzing: Set<SymbolForAnalysis>,
    ): Stability { /*...*/
    }
// ...
}

클래스의 안정성 판단

• Annotation 확인: 클래스나 상위 클래스에 @stable 또는 @immutable 어노테이션이 있는지 확인

if (declaration.hasStableMarkedDescendant()) return Stability.Stable

1. 특수한 클래스 처리:
2. Enum 클래스나 기본 타입은 안정적인 것으로 간주
3. Protobuf 생성 클래스 등은 안정적인 것으로 처리
4. 외부 안정 타입 확인: if (declaration.isExternalStableType()) return Stability.Stable

• 클래스의 모든 프로퍼티와 필드의 타입 안정성을 분석
• var 프로퍼티가 있으면 불안정한 것으로 간주

for (member in declaration.declarations) {
    when (member) {
        is IrProperty -> { /*...*/
        }
        is IrField -> { /*...*/
        }
    }
}

타입의 안정성 판단

• 기본 타입 처리: Unit, Primitive Types, String 등은 안정적인 것으로 간주
• 타입 파라미터 처리: 타입 파라미터의 대체 타입이 있으면 그 타입의 안정성을 사용
• Nullable 타입 처리: Non-Nullable 타입으로 변환하여 안정성을 추론
• Inline 클래스 처리: 내부의 실제 타입(Underlying Type)의 안정성을 사용
• Simple 타입 처리: 해당 클래스의 안정성을 확인하고, 타입 인자들의 안정성을 함께 고려

표현식의 안정성 판단

• 상수 처리: IrConst는 안정적인 것으로 간주
• 함수 호출 처리: 호출된 함수의 안정성과 타입 인자의 안정성을 함께 고려
• 변수 참조 처리: 변경 불가능한(val) 변수의 경우 초기화된 값의 안정성을 사용
• 복합 표현식 처리: 내부의 모든 표현식이 안정적인지 확인

@immutable과 @stable이 안정성 추론에 미치는 영향

안정성 마커 확인

hasStableMarker() 함수: 클래스나 어노테이션 컨테이너에 @StableMarker 어노테이션이 있는지 확인

fun IrAnnotationContainer.hasStableMarker(): Boolean = annotations.any { it.isStableMarker() }

isStableMarker() 함수: 어노테이션이 @StableMarker인지 확인

private fun IrConstructorCall.isStableMarker(): Boolean =
    annotationClass?.owner?.hasAnnotation(ComposeFqNames.StableMarker) == true

• @stable과 @immutable은 @StableMarker로 표시되어 있으므로, 안정성 추론에서 동일하게 처리

클래스의 안정성 결정

• 클래스에 @stable 또는 @immutable이 있으면: 해당 클래스는 안정적인 것으로 간주
• 상위 클래스에 어노테이션이 있는 경우: 재귀적으로 확인하여 안정성을 판단
• 컴파일러는 이러한 정보를 활용하여 타입의 안정성을 정확하게 추론

컴파일 타임에서의 최적화

• 안정성 정보를 통한 재구성 최소화:
  • 안정적인 타입은 변경되지 않거나 Compose가 그 변화를 추적할 수 있으므로, 불필요한 재구성을 방지
• 컴파일러의 역할:
  • 타입의 안정성을 추론하여 재구성 전략을 최적화
  • 어노테이션 정보를 활용하여 안정성을 정확하게 판단
• 성능 향상 효과:
  • 불필요한 재구성을 줄여 UI 업데이트의 효율성을 높임
  • 앱의 전체적인 성능 향상에 기여

[ldh019]

NonRestartableComposable 사용하기 좋은 예시 or 상황

아무래도 recomposition이 잘 안일어나게 막는거니까!
상태랑 아무상관 없는 내용의 컴포저블이라거나, 연산 비용이 너무 비싸서 내가 원하는 타이밍에만 다시 그리고 싶은 경우!
가 되지 않을까요~

Immutable 과 Stable이 Compose Compile 타임에 어떻게 동작하는지

둘다 기본적으로 StableMarker 의 뜻을 따르는 애들이니까 쉽게 변하지 않는다는 전제를 들고가고
Immutable은 값이 바뀌지 않으니까 다시 그리지 않아도 된다! 즉 컴파일할때 한번 그리고 유지하도록 할거고
Stable은 값이 바뀔때만 그리는 거니까, 내부에 있는 값들의 변화를 감지해서 변했다? -> 다시그려 이렇게 동작할것입니다요