Glacier's Daily Log

UI 작성시 ConstraintLayout을 활용을 권장하는 이유 본문

Coding/Android

UI 작성시 ConstraintLayout을 활용을 권장하는 이유

h__glacier_ 2024. 1. 25. 18:03
반응형

 안드로이드에서 UI 요구사항을 작성하는 방법은 크게 3가지가 있다.

  1. 동적으로 프로그래머틱하게 View를 생성
  2. XML 파일을 활용해 UI 작성
  3. Jetpack Compose를 활용하여 작성

아직까지 대부분의 구현은 XML 파일을 활용해 UI를 작성하는 방식을 채택하고 있는데,
수많은 ViewGroup중 LinearLayout이나 RelativeLayout을 활용한 구현이 많이 보인다.

 현재 안드로이드 권장사항은 ConstraintLayout 사용인데, ConstraintLayout을 활용하면 어떤 장점이 있는지 알아보자.

 


 

  1. 우리가 XML로 작성한 코드는 실제로 View기반의 구현체로 바뀌어 화면에 그려지게 된다.
  2. 그 View 또한 특수한 생명주기를 따른다 (참고 : https://www.charlezz.com/?p=29013)

           

3. 그렇게 만들어진 뷰를 그릴 때 각 위젯을 화면에 렌더링하는 과정은 아래와 같다.
 점, 선, 면 정보를 활용해 3개의 정점을 삼각형으로 만든 폴리곤을 만들고, 이를 여러개 활용해 매쉬로 변환한다.
 모든 변환과정이 끝난 뒤 변환된 데이터가 OpenGL에 의해 CPU에서 GPU로 전달되게 된다.


 이렇게 UI정보를 매쉬로 변환하는 과정이 매우 큰 비용을 필요로 하는데, 이미 한번 GPU에 업로드된 UI데이터는 GPU에 메모리상에 적재된 상태로 다음 프레임을 그릴때 재사용 되기 때문에 매번 변환 과정을 거치지는 않는다.
따라서 화면 렌더링 퍼포먼스는 GPU에 메모리를 얼마나 효율적으로 적재/제거 하냐에 따라 결정된다.

         

 

4. 디스플레이 리스트에서는 렌더링이 필요한 뷰에 대한 그리기 명령들이 포함되어 있다.
 뷰가 렌더링 된 이후에 뷰의 속성에 대한 변화가 있다면, 간단히 디스플레이 리스트를 변경하여  렌더링할 수 있다.
 하지만 전체적인 변화가 크다면 새롭게 디스플레이 리스트를 생성하여 화면 갱신이 필요하다.

 이 과정에서 LinearLayout이나 RelativeLayout과 같은 ViewGroup에 변화가 생긴다면 모든 Child View의 그리기 과정이 다시 진행되어야 한다.
따라서 View 렌더링 과정의 성능을 높이려면 View의 계층구조를 Flat하게 유지해야한다.

 

5. LinearLayout은 가로/세로 기준으로 뷰를 중첩하며 그룹화시킨다. 따라서 복잡한 UI요구사항을 구현하려면 View 계층구조가 깊어질 수 밖에 없는 한계가 있다.

따라서 복잡한 구조의 화면일수록 LinearLayout → ConstraintLayout으로 마이그레이션 한다면 큰 성능상 이점을 얻을 수 있다.


 ConstraintLayout은 Flat한 계층구조로 복잡한 레이아웃을 설계할 수 있게 많은 기능을 제공한다.

    • 상대적 배치
    • Guideline 
    • Circular positioning
    • Chains
    • Barrier
    • Group

특히 Guideline은 전체 View의 패딩값을 지정할 때 elevation 속성으로 인한 그림자가 잘리는 현상 등의 문제가 없이 잘 활용할 수 있었던 기억이 있고,
Group은 많은 수의 View의 Visibility를 한번에 동적으로 변경할 때 유용하게 활용한 기억이 있다.

 

  • 추가적인 화면 렌더링 퍼포먼스를 향상시킬 수 있는 몇가지 방법..
    • 레이아웃에 불필요한 background 속성 사용 지양 (오버드로잉)
    • alpha값 남용 지양 (ex: Gray 색상을 표현하기 위해 Black * alpha0.7 사용 등)
반응형
Comments