[Android] Compose UI - (1)

Compose UI와 런타임의 통합

Compose Runtime을 위한 클라이언트 라이브러리로써 Compose UI를 결합하는 이유는 사용자가 보게될 화면의 레이아웃 트리를 구축하기 위해서이다.

이 트리는 Composable 함수를 실행함으로써 만들어지고, 트리에 사용되는 노드 타입은 Compose UI만 알고 있기 때문에 런타임은 이를 알지 못한다.

Compose UI와 같은 클라이언트 라이브러리에서 생성하는 노드 타입은 클라이언트 라이브러리만 알고 있어야 하기 때문에, 런타임은 트리에서 노드를 삽입, 삭제, 이동 또는 교체 작업을 위임한다.

예약된 변경 목록을 실제 트리의 변경 목록으로 매핑

Composition이나 recomposition에 의해 Composable 함수가 자신의 변경 사항을 방출할 때 composition이라는 side table이 사용된다.

이 table은 실제 노드 트리의 변경으로 매핑하고 이러한 작업과 관련된 정보를 가지고 있다.

Compose UI 관점에서의 Composition

안드로이드를 예로 들면, 하나의 화면에서 setContent를 호출할 때 Compose UI 라이브러리에서 runtime 단계로 진입된다.

class MainActivity: ComponentActivity() {
	oerride fun onCreate(savedInstanceState: Bundle?) {
		super.onCreate(savedInstanceState)
		setContent {
			MaterialTheme {
				Text("Hello Compose")
			}
		}
	}
}

하지만 꼭 화면에서 setContent를 호출할 수 있는건 아니다. setContent는 View 계층의 중간에서도 호출될 수 있고, 아래와 같이 호출될 수도 있다.

ComposeView(requireContext()).apply {
	setContent {
		MaterialTheme {
			Text("Hello Compose")
		}
	}
}

setContent 함수는 새로운 루트 Composition을 생성하고, 최대한 재사용 되고자 한다.

루트 Composition이라 부르는 이유는 각각 독립적인 Composable 트리를 호스트 하기 때문이고, 이들은 서로 연결되어 있지 않다.

이러한 관점으로 하나의 앱에는 여러 개의 노드를 쌓아 관리하는 트리가 있으며, 각기 다른 Composition에 연결된 모습을 상상하면 된다.

레이아웃 계층을 생성하기 위해 Composer가 setContent안에 있는 모든 Composable 함수들을 실행하며, 변경 사항이 방출되어 UI의 노드들이 삽입, 삭제, ,이동, 교체 되며 UI 요소들에 반영된다.

이런 Composable들은 일반적으로 서로 다른 라이브러리(foundation, matrial3 등등)에 속하지만, 결국 모두 Layout으로 정의되므로 동일하다고 볼 수 있다.