#JetpackCompose Stability Android Developer 공식문서
=>https://developer.android.com/jetpack/compose/performance/stability?hl=ko

-Recomposition을 해야 하는지 안 해도 되는지 Compose가 어떡해 알 수 있을까? 바로 컴포저블이 받는 인자를 통해 알 수 있다. 인자가 변경되면 해당 인자와 관련된 모든 컴포저블에서 리컴포지션이 발생한다. 그렇다고 모든 인자가 변경될 때마다 리컴포지션이 발생하는 것은 아니다. 컴포저블 함수에서 받을 수 있는 인자의 클래스 타입은 [1.Unstable] , [2.Stable] , [3.Immutable] 이렇게 세가지이다. 이들중에서 리컴포지션을 발생시키는 경우와 리컴포지션을 발생시키지 않는 경우가 존재한다.

-컴포즈는 컴포저블 매개변수의 안정성을 사용하여 리컴포지션을 생략 할 수 있는지 없는지를 판단한다는 의미이다.

컴포저블에서 매개변수로 받을 수 있는 클래스 타입

Unstable(리컴포지션 발생 가능)

  • 데이터 변경 가능
  • 데이터 변경 시 컴포즈에서 추적 불가

Stable(리컴포지션 발생 가능)

  • 데이터 변경 가능
  • 데이터 변경 시 컴포즈에서 추적 가능

Immutable(리컴포지션 발생 불가)

  • 데이터 변경 불가
  • 안정적인 데이터로 취급

똑똑한 리컴포지션

-unstable은 최대한 없애고 stable 또는 immutable 들을 활용해서 컴포저블의 매개변수로 설정하는 것이 좋다.

val Vs var

-val은 값이 바뀔 수 없다고 알려져있지만 새로운 객체를 생성하면 값을 변경 할 수 있다. 그러면 메모리상의 위치가 변경되기 때문에 객체의 hash 값이 변경되므로 리컴포지션이 발생된다.

-var은 객체의 hash 값이 바뀌지 않으므로 컴포즈에서 추적할 수 없는 unstable 타입이다. 따라서 일단은 리컴포지션 하고 본다.

Restartable Vs Startable

-아래 사진은 컴포저블이 파라미터를 바라보는 관점에 대해서 정리한 사진이다.

-컴포저블은 파라미터를 안정적이냐 불안정이냐 두가지로 분류해서 본다. 그 후 안정적인 파라미터를 [1.ImmutableType] , [2.@Immutable Annotation] , [3.stable 타입]으로 분류한다.

-참고로 Row , Column은 Inline Function으로서 컴파일시 호출 위치에 그대로 함수 본문을 때려 박기 때문에 컴파일 시점에 InlineFunction은 실제 함수가 아니다. 그냥 함수내용을 풀어서 일반적인 코드로서 작도하기 때문에 자체적인 리컴포지션 개념이 없이 그저 부모 컴포저블의 리컴포지션 여부를 따라간다.

-Recompostion 여부를 컴포지션이 결정할 때 판단하는 순서는 1.컴포저블이 받은 매개변수가 안정적인지 또는 불안정한지 체크 -> 2-1. 안정적이라면 경우에 따라 Skippable 한지 Restartable 한지 판단한후 Skippable이라면 리컴포지션을 패스하고 Restartable이라면 리컴포지션을 진행한다. 또는 2-2. 불안정하다면 일단 무조건 리컴포지션을 진행한다. 따라서 리컴포지션을 최적화하기 위해서는 안정적인 파라미터를 사용하는 것을 권장한다.

컴파일러에서 보는 컴포즈

-컴팡일러는 컴포즈를 볼 때 컴포저블의 파라미터가 Restartable 인지 Skippable인지 판단하는데, 판단 과정은 하위 컴포저블 부터 상위 컴포저블로 상향식으로 발생하고 , 리컴포지션이 발생한다면 하향식으로 발생한다.

profile
포기하지 말기

0개의 댓글

Powered by GraphCDN, the GraphQL CDN