[Android Compose] Compose 이해

 

---

잡설....

선언형 UI 인 제트팩 컴포즈

 

팀에서 프로젝트를 부분부분 컴포즈로 옮겨가고 있었는데, 이번에 새 프로젝트를 시작하게 되면서 가능하면 100% 컴포즈를 이용해보기로했다 (아직은 뷰바인딩이 더 유려한 컴포넌트도 있긴 있응게..)

 

암튼 그래서 새로운 기술스택들이 좀 추가되기도 하고, 이전에 알던걸 좀 더 잘 알아야할 필요가 느껴져서 이전에 공부하던 내용 업로드도 하고 내용 추가도 하면서 나도 공부를 좀 더 해보려함

---

 

오늘 내용인 컴포즈의 이해는 

 

https://developer.android.com/jetpack/compose/mental-model?hl=ko

Compose 이해  |  Jetpack Compose  |  Android Developers

해당 링크 내용을 내가 다시 보고 이해하기쉽게 나름대로 정리해본것이다.

 

선언형 API 

기존의 UI : UI 위젯트리를 findViewById() 등으로 탐색하고 메서드를 호출, 위젯의 내부 상태를 수정 

선언형 API : 위젯 트리를 인스턴스화하여 UI를 초기화, 비교적 stateless 하고 getter, setter 를 노출하지 않음 (객체로 노출되지 않음), 데이터가 변하면 동일 컴포저블을 다른 param 으로 호출하여(새로운 인스턴스) 업데이트

 

@Composable : 이 함수는 데이터 -> UI 변환을 위한 함수임을 컴파일러에 알림

컴포저블은 다른 컴포저블을 호출하여 UI 계층 구조를 내보낸다.

 

뭐랄까.. 트리구조라고하니까 사과나무를 생각해보면

13번 사과를 익힌다 라고했을 때 기존 방식은 나무검색>13번사과찾아>그사과의 컬러를 레드로 set해라 

라는 느낌이라면 

컴포즈는 13번사과(익음) 을 호출하면 그냥 익은사과가 만들어지고 초록사과 자리에 들어가는 느낌

트리는 13번 사과를 다시 찾을 필요가 없으며 사과는 스스로가 무슨색인지 기억할 필요가 없다(stateless)

 

사용자와의 상호작용 

재구성(recomposition) : onClick 같은 이벤트가 발생하면 앱 상태를 변경 > 그러면 데이터가 변하고 변화 된 새 데이터가 컴포저블을 다시 호출 (위젯을 직접 찾고 수정할 필요 없음)

또한 나무는 사과들을 알아서 관리중이기에 사과를 구성한 데이터가 바뀌면 알아서 

해당 가지와 사과만 업데이트해준다.

 

재구성

 

재구성을 이해하기 전에 부작용이란?

부작용(부수효과)

부작용 : 컴포저블 함수의 범위 밖에서 발생하는 앱 상태에 관한 변경사항 

컴포저블이 아닌 앱의 나머지 부분에 표시되는 변경사항 

ex: 공유객체 속성 쓰기, 뷰모델에 업데이트, 공유 환경설정 업데이트..

 

컴포저블이 실행되면서 컴포저블 밖의 데이터를 건드는 것을 부작용이라 한다. 뭔가 부정적인 네이밍이 개념을 헷갈리게 한다 갠적으로는…. 부작용의 ‘부' 는 부정적인 의미가 아니다. 부작용의 단어정의도 혹시 도움이될까하여 첨부 

: 본래의 치료 효과 이외의 부수적인 효과가 나타나는 것이다. 부수적 효과가 도움이 된다면, 부작용은 치료 목적으로도 물론 이용할 수 있다. (출처 : 위키백과-부작용)

 

새 데이터 인풋으로인해 리컴포지션이 일어날 때, 영향을 받는 있는 함수/람다만 호출되고 나머지는 최대한 건너뛴다.

따라서 리컴포지션 시 부작용을 이용하려 하면 안된다. 

또한 코드가 반드시 표시 된 순서대로 실행되지는 않으므로 순서상 위쪽 코드의 부작용(전역변수 설정 등)을 이용해 아래쪽 코드가 활용하는 구현 또한 불가하다.

 

부작용은 onClick 등의 콜백을 이용해 트리거 되어야 한다.

 

컴포저블의 재구성 특징을 이해하고 있으면 부작용의 오남용을 막을 수 있고, 의도대로 동작하는 코드를 짜는데 도움이 된다.

 

1. 구성 가능한 함수(Composable)는 동시에 실행할 수 있음

컴포저블은 최적화를 위해 여러 다른 스레드에서 동시에 호출될 수 있음

따라서 컴포저블 람다의 변수를 수정하는 코드는 피해야함

여기저기 불려가서 엉망진창의 값이 될 수 있으니까….

 

2. 재구성은 가능한 한 많이 건너뜀

재구성 시에 최대한 많은 요소를 건너뛰므로 다시한번, 부작용이 없어야한다.

 

3. 재구성은 낙관적임

매개변수가 변경되었을 ‘수’ 있을 때마다 재구성이 시작되고, 중간에 매개변수가 또 변하면 취소>재구성이 될 수 있으므로 표시되는 UI에 종속되는 부작용이 있으면 앱 상태가 일관적이지 않을 수 있음

 

4. 구성 가능한 함수(Composable)는 매우 자주 실행될 수 있음

‘공유환경설정에서 읽기’ 등 비용이 많이 드는 작업은 백그라운드 코루틴에서 실행하고 그 결과를 매개변수로 컴포저블에 전달하여야 함.

비용이 많이 드는 작업이 컴포저블 내에 있으면 이것이 불필요하게 반복실행되면서 UI버벅임이 생길 수 있다.

따라서 비용이 많이 드는 작업은 외부 스레드로 이동시키고 mutableStateOf / LiveData 등으로 그 결과를 컴포저블에 전달해야한다.

쉽게 요약하면 내가 컴포저블을 선언은했지만, 실행,재구성하는 시점이나 횟수는 내가 통제하는 것이 아니므로 

컴포저블에 다른거 시키는건(부작용) 지양하자..  

마치 마계생물을 함부로 소환하면 안된다거나 시간축을 건드려서는 안된다는 금기같은것이지 하하

 

 

 

 

 

 

틀린내용 댓글로 달아주시면 감사합니다