Rust로 Compose 모양의 UI를 쓰면, Compose가 그립니다.

무엇인가

compose-rust는 네 가지를 합친 것입니다.

• Compose 모양의 Rust API. 슬롯 테이블과 recomposition 런타임을 갖춥니다. composable은 함수이고, 상태는 remember 에 둡니다. 상태가 바뀌면 그 상태를 읽은 스코프만 다시 실행됩니다. 무엇이 바뀌었는지 트리를 비교해서 찾지 않습니다. 1.0.0을 향한 계획입니다.
• 좁은 C ABI 경계와 스키마. 위젯, 속성, 레코드를 Rust에서 한 번 정의합니다. Kotlin 타입과 플랫폼 심은 그 정의에서 생성하고, 손으로 쓰지 않습니다. 구현
• AOT 컴파일된 Compose 렌더러. 모든 플랫폼에서 미리 네이티브 코드로 컴파일하고, 브라우저에서는 Kotlin/Wasm, Android에서는 Android 라이브러리입니다. 그리기와 입력은 Compose 자신의 텍스트 레이아웃, 위젯, 플랫폼 IME가 맡습니다. 구현
• 웹뷰 없음, 동봉된 JVM 없음. 데스크톱의 목표는 시스템 라이브러리만 링크하는 실행 파일 하나입니다. 0.0.1은 아직 거기에 닿지 않았습니다. 플랫폼을 보십시오. 부분

왜 만드나

하루 종일 켜 두는 애플리케이션을 겨냥합니다. 그런 앱은 무게가 매시간 느껴집니다. 웹뷰는 브라우저 엔진을 함께 데려옵니다. 동봉된 Java 런타임은 jlink 를 거쳐도 80~120 MB를 더합니다.

순수 Rust UI 툴킷은 글을 많이 다루는 앱에 가장 중요한 곳, 곧 글자 자체에서 막힙니다. 한국어, 일본어, 중국어 입력은 플랫폼 IME를 거치고, 90%만 맞는 IME로는 앱을 쓸 수 없습니다. Compose Multiplatform에는 이미 성숙한 텍스트, IME, 위젯 동작이 있습니다. compose-rust는 딱 그것을 빌려 옵니다. 애플리케이션 코드는 Rust에 남고, Compose는 Rust가 보낸 UI 트리를 해석합니다.

현재 상태

0.0.x는 이름을 확보하고 렌더러를 배포하는 단계입니다. API는 바뀝니다. 0.0.1 크레이트에 지금 들어 있는 것은 다음과 같습니다.

1.0.0 전까지 이 크레이트는 트리를 만드는 층이 올라설 토대입니다. 아직 화면을 직접 쓰는 도구가 아닙니다.

계획한 모양

#[composable]
fn counter() {
    let count = remember(|| mutable_state_of(0));
    Column(Modifier::new().fill_max_width(), || {
        Text(format!("{}", count.get()));
        Button(|| count.set(count.get() + 1), || Text("+1"));
    });
}

fn main() {
    compose_rust::launch(counter);
}

정해진 것은 세 가지입니다. #[composable] 이 그룹을 넣으므로 그룹이나 키를 손으로 쓰지 않으며, 분기, 반복문, 조기 return, ?, 되감기를 지나도 그룹이 맞게 닫힙니다. 이름은 Compose를 따릅니다. 위젯 어휘는 스키마에 있는 그것 하나이므로 두 번 정의하지 않습니다. 작성 API의 나머지는 UI 작성하기에 있습니다.

플랫폼

아래 표는 0.0.1에서 플랫폼마다 받는 렌더러입니다. "처음부터 끝까지 동작"은 사람이 직접 써 본 플랫폼이라는 뜻입니다. "빌드되고 시작됨"은 CI가 빌드하고 스모크 테스트가 창을 열어 그린다는 뜻이며, 증명하는 것이 그보다 적습니다.

실제 무게

notepad 샘플을 릴리스로 빌드하고 스트립한 숫자이며, Kotlin/Native 렌더러를 링크했습니다. 0.0.1이 배포하는 경로가 아니라 0.0.1 다음에 기본이 되는 경로입니다. 결과는 실행 파일 하나이고, 옆에 놓이는 런타임도 안에 든 가상 머신도 없습니다.

비교하자면, 렌더러가 아직 Java 런타임을 싣고 있던 때 macOS의 같은 종류 앱은 파일 넷, 93.1 MB였고 실제 점유는 56 MB였습니다. 브라우저에서는 렌더러와 Skia를 합쳐 gzip으로 6.95 MB입니다.

다음으로