선언형 UI vs 명령형 UI

Jetpack compose를 공부하던 중 선언형UI라는 단어가 나왔고 이에 대해 정리를 해보려고 한다.

---

명령형UI

기존의 UI를 만드는 방식으로 기존 안드로이드는 트리형태로 뷰를 구성한다.
레이아웃을 맨 아래에 깔고 그 위에 브랜치처럼 텍스트뷰, 이미지뷰를 넣고 다시 레이아웃을넣는 등 쌓아가는 개념으로 뷰를 그렸다.

이와같은 작업 방식은 개발자로 하여금 논리적으로 뷰를 쌓게 만들어줍니다. 하지만 xml이라는 막대한 리소스를 반복적으로 낭비하게 됩니다.
또한 노드를 변경하기 위해 findViewById( ), viewBinding, dataBinding을 통하여 노드에 접근하고 setText(), setImageBitmap( ) 등의 메서드를 사용하여 변경해야합니다.

이런 노드 접근 방식은 불필요한 코드를 만들 뿐만아니라 한 노드에 대한 업데이트의 충돌이 발생할 확률을 높이게 된다.

시나리오

명령형 UI의 시나리오는 다음과 같다.

어떤 변수를 참조하는 UI가 있다. 이벤트에 의해 변수가 변경되었고 UI에 반영해야한다. 명령형UI 프로그래밍 방식은 변경된 내용을 갱신할 것을 UI 객체에 명령한다.

해당 시나리오의 중요한 점은 개발자가 UI객체와 변수에 대한 연결고리를 정확하게 해야한다는 점이다.

// Imperative style
b.setColor(red)
b.clearChildren()
ViewC c3 = new ViewC(...)
b.add(c3)

---

선언형UI

선언형UI는 새로 나온 개념으로 화면 전체를 개념적으로 재생성한 후 필요한 변경사항만 적용하는 방식으로 적용됩니다.

선언형UI에서 중요한 부분은 State라는 개념이다. 뷰마다 State가 있고, 이 값을 변경하게 되면 새로운 화면을 생성해서 다시 화면을 업데이트하게 된다. 따라서 개발자는 State변화에만 집중을 하면 된다.

이러한 접근 방식은 스테이트풀(Stateful) 뷰 계층 구조를 수동으로 업데이트할 때의 복잡성을 방지할 수 있습니다. 화면 전체를 재생성하는 데 있어 문제는 시간, 컴퓨팅 성능 및 배터리 사용량 측면에서 비용이 많이 든다는 것입니다. 이 비용을 줄이기 위해 Compose는 특정 시점에 UI의 어떤 부분을 다시 그려야 하는지를 지능적으로 선택합니다.

시나리오

선언형 UI의 시나리오는 다음과 같다.

어떤 변수를 참조하는 UI가 있다. 이벤트에 의해 변수가 변경되었고 UI에 반영해야한다.
이벤트에 의해 변수를 변경해주면 해당 변수를 참조하고 있는 뷰는 State의 변경에 따라 뷰를 재생성한다.

선언형UI는 명령형UI와는 달리 변화가 생긴 UI객체를 다시 생성한다.

이로써 얻는 장점은 개발자가 변수와 UI객체간의 연결고리에 대하여 고민할 필요가 없다는 점이다.

// Declarative style
return ViewB(
  color: red,
  child: ViewC(...),
)