본문 바로가기

안드로이드

컴포즈 스터디 2차 구성 가능한 함수

구성 가능한 함수

들어가기에 앞서 동영상 진짜 번역부터 열받아죽겠다 그냥 글로 만들어줬으면 좋겠다.

Composable

기본적인 컴포저블 함수에대해서 설명한다.

이건 앞에서 다뤘으니 생략

 

 

희안하게 초반부에 리사이클러뷰를 대체하는 lazyColumn 같은게 아닌 그냥 forEach를 통해서 리사이클러뷰 같이 리스트를 구성하는것을 보여준다.

 

 

컴포저블 함수는 불변값이기 떄문에 이렇게 변수를 담고 해봐야 상태값을 변경하고 이럴수 없다. 그런 개념이 아니다 애초에

 

 

 

내부에서 이렇게 분기를 쳐서 empty View 혹은 visibility 처리를 할수도 있는것이다. (visibility 속성을 건드는게 아니라 그냥 표시자체를 안해버림)

 

 

 

또한 당장 왜인지는 설명안하는데 컴포저블 함수내에서 전역변수를 수정하면 안된다고 한다.

 

UI는 매개변수에 의해서 완전제어된다

UI는 매개변수에 의해 제어된다.

-> 이것이 상태를 UI로 변환한다는 뜻이라고 한다.

 

상태가 변경된다면 이미있는 뷰객체를 변경하는게 아니라 새로운 상태값으로 새롭게 컴포저블 함수를 호출하여 다시그리는 형태를 띈다고 한다.

이를 Recomposition이라고 한다고한다.

 

Recomposition

이제 이 리컴포지션이 UI를 다시 그리는 것임은 알게되었다.

일단 매개변수 변경에 의해서도 Recomposition이 일어날 수 있지만 내부 상태값 변경에 의해서도 UI가 다시 그려질 수 있는것이다.

그 방법에 대해서 지금부터 살펴본다.

 

 

예를 들어 위의 이미지처럼 라디오 버튼의 selected상태를 나타내는 내부 변수를 둔다고 가정해보자

 

근데 이렇게 단순 놓는다고 리컴포지션이 일어나지 않는다.

리컴포지션이 일어나도록 내부 상태값을 구성하고 싶다면 내부적으로 MutableState라는 컴포즈 관련 옵저버블을 사용해야한다.

이를 사용하면 이 값이 변경될 때만다 리컴포지션이 일어난다.-> 변경 작업이 알아서 예약된다.

 

 

그래서 이제 isSelected 속성을 비교해줄때 이 상태값을 이용하는데

이제 짜증나는게 라이브데이터 마냥 value값을 꺼내서 사용해야한다. -> 이에대한 해결책이 나중에 나온다.

 

 

 

또한 remember이라는 것으로 또 래핑해줘야하는데 이렇게 되어야 기존 상태값이 리컴포지션때 재설정 되는것을 막을수 있다.

만약 remember를 하지않는다면 리컴포지션 때마다 매번 새로운 null 값이 설정되어 원하는 목표를 이루지 못할것이다.

 

 

하지만 remember는 구성변경(configuration change)에는 대응이 안되는데 이를 대응하기 위해서는 rememberSaveable를 사용해아한다고 한다.

 

 

 

또한 이를 by를 사용한다면 바로 래핑 타입을 다 쌩까고 원하는 객체타입으로 다룰수 있어서 mutableState.value이런거 안해도되어서 좋다.

 

결론적으로 깔끔하게 이렇게 쓰는게 맞다.

 

 

그래서 람다를 통해서 클릭등이 있을때 내부적으로 상태값을 변경하여 다시 UI를 그리고 할수있다(근데 그럼 selected 값은 어캐꺼내지?)

 

 

컴포저블 함수를 구성할때 주의점

  • 컴포저블 함수는 사이드이펙트가 없어야하고 같은 인자를 받는다면 같은 값을 내보내야한다.(함수형 프로그래밍 할때 봤었던거 추억돋네)

 

  • 컴포즈 함수는 순서대로 진행되지 않음을 상기하자.

 

이런식으로 있을때 컴포즈 함수자체에 우선순위가 있어 순서대로 처리되지 않을 가능성이 있다.

 

 

  • 컴포즈 함수는 병렬적으로 실행될 수 있다.

컴포즈 다중 코어를 사용하여 성능이 높여서 이부분을 주의해야한다.

 

 

  • 리컴포지션은 다시 안그려도 되는것들은 최대한 다시 안그리려한다.

컴포즈는 다시 재구성하는 부분만 그리려한다.

리컴포지션을 유도하는 state가 아니라면 무시하고 넘어가버릴 수 있다.

 

 

이런상황에서 name 이 바뀌면 Header와 Footer는 다시 그려지지 않는다.(상태에 의존하지 않아서)

 

 

  • 리컴포지션은 낙관적이란다.(optimistic 낙관적???)

컴포즈의 리컴포지션의 업데이트가 파라미터가 재변경 되기전에 완료되리라 예상한다.

리컴포지션이 끝나기전에 매개변수가 변경되면 컴포즈는 리컴포지션을 취소시켜버리 다시 새로운 매개변수로 작업을 시작할수 있다.

 

 

  • 컴포즈 함수는 시도 때도 없이 실행될 수 있다.(Composable functions might run frequently)

컴포즈 함수에 프레임마가 실행되어야하는 애니메이션 같은것들이 있을때 이러한 일들이 일어난다.

그래서 컴포즈 함수는 빨라야한다(무거운 내부 작업을 하면안된다는것 같음) -> 안그러면 프레임 드랍일어난다.

 

 

안좋은 예시

 

이런식으로 지역변수를 올바르지 못하게 사용하는 경우 사이드 이펙트가 발생하여 UI동작이 이상해질 수 있다.