[260114] Android Jetpack Compose의 3단계 실행 파이프라인(컴포지션, 레이아웃, 그리기)

컴포지션(Composition), 레이아웃(Layout), 그리기(Drawing)

• Jetpack Compose 는 선언형 UI 코드를 화면의 픽셀(렌더링된 UI) 로 변환하기 위해 위 3단계를 거친다. 
• 상태 변수가 바뀔때마다 모든 것을 다시 그리는 것이 아니라, 셋 중 꼭 필요한 작업만 수행한다. 
• ex. drawing 에만 영향을 주는 변경은 composition 과 layout 을 완전히 건너뛸 수 있음. 
• 반면 ui 구조 자체가 바뀌는 경우에는 세 단계가 모두 필요할 수 있음. 
• 각 단계는 이전 단계가 완료되어야 진행될 수 있지만, 모든 상태 변경이 세 단계를 다 거치는 것은 아님. 

 

---

 1. 컴포지션 (Composition) 

• 컴포저블 함수를 실행하며, UI 트리를 구축하고, 무엇을 표시해야할지를 기록함. 
• @Composable 함수들이 실행 됨. 
• 단순히 트리를 만드는 것을 넘어, SlotTable 이라는 메모리에 상태를 저장하고 이전과 비교(Diffing) 하는 과정

컴포저블(Composable) 함수 : UI 를 구성하는 함수로 @Composable 어노테이션이 붙으며 UI 를 선언함
어노테이션 사용 기준 및 특징
1) UI 요소 (예: Text, button, cloumn, row 등) 
2) 다른 컴포저블을 포함하는 함수에 붙여서 재사용 가능한 UI 요소 
3) 화면에 무언가를 "그리기 위한 정보" 를 제공한다면 무조건 @Composable 을 붙여야 함. 
4) 어노테이션이 붙은 함수들은 컴포지션 단계에서 실행되어 UI 트리(노드) 를 구축함. 
5) 상태(state) 변화에 따라 다시 실행(restart) 되어서 UI 갱신(재컴포지션) 해야 한다면, @Composable 붙어야 함. 

 

• 내 프로젝트 예시(feat. 로그인 랜딩 화면) 

• 위 나열된 기준을 보면서 내가 구현한 코드를 다시 보았다 
• 장기적으로 봤을때 비효율적인 부분이 많았다
• 현재 코드 : 로그인 랜딩 화면에서 @Composable 선언된 부분은 아래와 같음. 

// 1. 전체 화면 자체 (screen level) 
@Composable
fun LoginLandingScreen( // 이벤트 호이스팅(Event Hoisting), 함
    onKakaoLogin: () -> Unit,
    onGoogleLogin: () -> Unit,
    onEmailStart: () -> Unit,
    onHomeClick: () -> Unit,      // 임시 홈버튼
    onDashboardClick: () -> Unit  // 임시 대시보드 버튼
) {
Column(modifier = Modifier.fillMaxSize().background(Color.White)) {
        // 상단/하단 레이아웃 배치 로직...
        SocialLoginButton(text = "또는 이메일로 시작하기", onClick = onEmailStart)
        // ...
    }
}

// 2. 로그인 버튼 (component level - 사용성) 
@Composable
fun SocialLoginButton(
    text: String,
    onClick: () -> Unit
) {
    Button(
        onClick = onClick,
        modifier = Modifier
            .fillMaxWidth()
            .height(56.dp), // 피그마의 도톰한 버튼 높이
        shape = RoundedCornerShape(28.dp), // 아주 둥근 알약 모양
        colors = ButtonDefaults.buttonColors(
            containerColor = Color.White,
            contentColor = Color.Black
        ),
        elevation = ButtonDefaults.buttonElevation(defaultElevation = 0.dp)
    ) 
    
    
// 3. 프리뷰 (개발 도구) 
@Preview(showBackground = true, showSystemUi = true)
@Composable
fun LoginLandingScreenPreview() {
    AuriTheme() {
        LoginLandingScreen(
            onKakaoLogin = {},
            onGoogleLogin = {},
            onEmailStart = {},
            onHomeClick = {}, // 임시 홈버튼
            onDashboardClick = {}) // 임시 대시보드 버튼
    }
}

• 내가 작성한 코드는 큼직한 기능 단위로 나눠져있다. 애초에 기능이 버튼 몇개뿐인 화면이라 .... 
• 로그인 버튼(공통) 을 재사용하는 것처럼 재사용성과, 최소한의 재컴포지션을 다방면으로 고려하여 @Composable 단위로 분리하는 것이 좋다.    
  • 재사용성 : 여러 화면에서 쓰이는 버튼, 텍스트 스타일 등 
  • 성능 최적화 : 화면 전체가 재컴포지션 되는 것을 막기 위해, 자주 바뀌는 부분만 별도의 @Composable 함수로 분리한다고 함. 
• 사실은 위보다 더 세밀하게 컴포저블 단위를 나누는 것이 좋다

---

개선할만한 부분 

1. 버튼 

• 현재 로그인 버튼의 경우, 높이 56.dp, pill 모양 28.dp 라는 동일한 레이아웃 제약을 가지고 있다.
• 만약 나중에 버튼 높이를 조정하게 됐을때 세 군데 코드를 모두 수정해야 한다. 이는 레이아웃 단계 유지보수 효율을 떨어뜨린다. 
• 버튼 개선 방안: Auri base button 이라는 공통 컴포넌트를 만들고 "그리기(drawing)" 요소(로고, 배경색, 텍스트) 만 파라미터로 받게한다. 
• 현재 공통 ui component 경로 : ui/core/componenets 

2. 스크린 뼈대 구조 

• 또한 현재 LoginLandingScreen 이라는 거대한 함수 안에 모든 버튼이 들어있는 구조이다. 왜 이렇게 짰지? 
• 발생할 수 있는 일: 만약 버튼 하나에 "로그인 중" 이라는 로딩 상태가 추가되어서 text 값이 바뀌면, 부모인 LoginLandingScreen 전체가 재컴포지션 대상이 될 수 있다. 
• 스크린 개선 방안: 각 버튼을 별도의 @Composable 함수로 완전히 독립 시키면, Composer 는 slot table 을 확인하여 입력 값이 변하지 않은 다른 버튼들은 skipToGroupEnd() 를 통해 실행 건너뛸 수 있다. 

 

---

2. 레이아웃 (Layout) 

• 생성된 트리를 바탕으로 각 요소의 크기와 위치를 결정함. 
• 컴포지션에서 생성된 트리를 바탕으로, 각 노드의 크기(measure)를 측정하고 화면 상의 좌표(place)를 결정하는 과정. 
• 즉, ui 요소를 어디에, 얼마나 크게 그릴지 결정한다. 
• 제약 조건(Constraints) 
  • 부모 column 이 자식 버튼에게 제약을 걸 수 있음
    • 예: 가로, 세로 최대최소 길이 
    • 가중치 계산 
    • 간격 배치 
  • 기존 Android View 와의 차이점 Single Pass Measurement (단 한번의 측정) 
    • Jetpack Compose의 레이아웃은 단 한 번의 측정(Single Pass)만으로 모든 요소의 크기를 결정하도록 설계되어 있음. 
    • 기존 안드로이드 view 시스템이 복잡한 계층 구조에서, 한 프레임 안에서도 on measure 을 여러번 호출 성능 저하를 일으켰었으나 "단방향 제약 조건 전달(Constraints flow down, Sizes return up)" 방식으로 해결함
      • (자식 component 측정, 그 결과를 토대로 부모 측정, 자식에게 최종 크기 통보 등등 ... )
      • 이 규칙 덕분에 UI 가 아무리 깊게 중첩되어도 성능이 일정하게 유지됨. 
    • Modifier 필터 
      
      • 단순히 속성을 주는 것이 아니라, 부모로부터 온 제약 조건(constraints) 을 자식에게 전달하기 전 수정하는 필터 역할을 함. 
      • 그렇다면 최상위 column에 위치한 modifier 의 "부모"는? 
        • 안드로이드 시스템 창 
        • 제약 조건 예시 : "너는 가로 0~1080px, 세로 0~2400px(폰 해상도) 사이에서 네 크기를 결정해"

    Column(
        // 전체 화면
        modifier = Modifier
            .fillMaxSize()
            .background(Color.White),

 

---

3. 그리기 (drawing) 

• 위치가 정해진 요소들을 실제 화면의 픽셀로 렌더링함. 
• 즉, 실제 화면에 색을 칠하고 이미지를 올리는 단계 
• ex. 불투명도 애니메이션 구현시, 투명도가 바뀔때마다 3단계를 전부 거치는 것이 아니라, 그래픽 레이어(GraphicsLayer) 를 통해 그리기 단계만 트리거함. 왜냐하면 불투명도가 트리의 구조 or 위치에 영향을 미치는 것이 아니기 때문 
• 그래픽 레이어 (GraphicsLayer) 
  • 개념 : 화면의 특정 요소를 별도의 레이어에 그려두는 것 
  • 내 프로젝트 적용 예시 : 챗봇의 음성 인식 아이콘이 부드럽게 깜빡이는 애니메이션을 넣고자 할때 
    • 일반 방식 : 매번 컴포지션 부터 다시 시작함 = 사용자 기기 발열 발생 
    • GraphicsLayer 방식 : Modifier.graphicsLayer { alpha = ... }를 사용 = 이미 그려진 투명도 조절만 하면 되기 때문에, 레이아웃과 컴포지션을 건너뛰고 gpu 가 그리기 단계만 담당할 수 있음. 
    • 현재 음성 챗봇 프로젝트에서 적용할만한 부분 : 음성 인식 시각화 애니메이션 도입 시, graphicsLayer의 scale과 alpha를 조절하여 일렁이는 애니메이션의 부드러운 움직임을 구현할 수 있다. 

 

 

- 개인 공부를 위해 기록되었습니다. 

- 잘못된 정보에 대한 피드백 환영합니다