[Android/Compose] Modifier를 파라미터로 전달하는 이유

 

Jetpack Compose에서 Column과 같은 레이아웃 컴포저블을 사용할 때, Modifier를 기본 인자로 직접 설정할 수 있습니다.
그런데, 코드에서 Modifier를 바로 적용할 수 있는데도 불구하고, 굳이 파라미터로 Modifier를 전달하는 방식을 사용하는 이유가 궁금했습니다.
이러한 의문을 가지고 공부하던 중, Compose의 재구성(Recomposition)과 성능 최적화와 관련된 중요한 개념을 알게 되었습니다.

이 글에서는 왜 Modifier를 직접 선언하는 것이 아니라, 파라미터로 전달하는 것이 더 좋은 방법인지 정리해 보겠습니다.

---

Modifier를 직접 사용하면 생기는 문제

처음에는 아래처럼 Column 내부에서 바로 Modifier.padding(16.dp)을 적용하는 것이 자연스러워 보였습니다.

@Composable
fun ExampleComposable() {
    Column(
        modifier = Modifier.padding(16.dp) // Modifier를 직접 선언
    ) {
        Text("Hello, Jetpack Compose!")
    }
}

 

하지만, Compose에서는 컴포저블 함수가 재구성(Recomposition)될 수 있습니다.
📌 재구성이란?

• 컴포저블 함수의 코드 블록이 다시 실행되는 것을 의미합니다.
• 화면이 다시 그려질 때, 상태가 변경될 때 등 여러 상황에서 발생할 수 있습니다.

위 코드에서는 재구성이 발생할 때마다 Modifier.padding(16.dp)가 새롭게 생성됩니다.
이렇게 되면 불필요한 객체가 계속 생성되면서 성능이 저하될 가능성이 있습니다.

---

Modifier를 파라미터로 전달하면?

Compose에서는 Modifier를 외부에서 전달받도록 설계하는 것이 더 효율적입니다.
아래처럼 Modifier를 함수의 인자로 받으면, 재구성이 발생해도 불필요한 Modifier 생성이 방지됩니다.

@Composable
fun ExampleComposable(modifier: Modifier = Modifier) { 
    Column(
        modifier = modifier.padding(16.dp) // Modifier를 파라미터로 받아서 사용
    ) {
        Text("Hello, Jetpack Compose!")
    }
}

 

📌 이렇게 하면 어떤 점이 좋을까?

1. 불필요한 Modifier 객체 생성을 방지하여 성능이 최적화됩니다.
2. 컴포저블의 재사용성이 증가합니다.
   • 호출하는 곳에서 원하는 Modifier를 전달할 수 있어 확장성이 높아집니다.
3. 기본값(Modifier = Modifier)을 설정하면, 외부에서 Modifier를 전달하지 않더라도 기본 동작을 유지할 수 있습니다.

---

Modifier를 파라미터로 전달하는 것이 더 좋은 이유

이 방식을 적용하면, 컴포저블이 재구성될 때 기존 Modifier를 재사용할 수 있습니다.
이는 불필요한 객체 생성을 줄이고 성능을 최적화하는 데 큰 도움이 됩니다.

📌 최종 정리

• Modifier를 직접 선언하면 → 재구성될 때마다 새로운 객체가 생성됨
• Modifier를 파라미터로 받으면 → 기존 객체를 재사용하여 성능 최적화 가능
• 기본값(Modifier = Modifier)을 설정하면 → 필요할 때만 커스텀 Modifier 적용 가능