seoft

컴포즈 프리뷰 에러 원인 중 일부 분석

seoft — Tue, 18 Mar 2025 22:22:44 +0900

[ compose compiler 1.5.10 / compose_bom androidx.compose:compose-bom:2024.12.01 ] 기준

컴포즈 프리뷰내 구성된 컴포즈 root 를 포함한 모든 하위 구성이 참조하는 코틀린 파일의 모든 멤버변수를 읽고

멤버변수가 주입이 덜된 구성이거나 오류를 발생할 경우 preview error 를 유발

예를들어

A.kt 구성이 다음과 같고

val version = "1.0"
val error = "".let {
error("error")
""
}

프리뷰의 컴포즈가 A.version 만 사용한다 가정했을때

error 는 사용하지 않지만 A.kt 의 멤버 프로퍼티를 읽으면서 오류발생

error 프로퍼티를 삭제하거나 다음처럼 처리하면 정상동작

val error by lazy {
  "".let {
  error("error")
  ""
  }
}

app-ads.txt

seoft — Sun, 11 Aug 2024 20:51:21 +0900

google.com, pub-1113145392459989, DIRECT, f08c47fec0942fa0

ubuntu java gradle 설치, 환경변수 설정

seoft — Sun, 18 Dec 2022 19:36:50 +0900

사전 권장사항 openssh-server 설치 후 방화벽해제

—

ubuntu20.04lts / jdk 11 / gradle 7.4.2 기준

—

apt-get update

sudo apt-get install openjdk-11-jdk

sudo nano /etc/profile.d/java.sh

#/bin/bash

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

—

sudo mkdir /downloads/gradle -p

cd /downloads/gradle

sudo wget https://downloads.gradle-dn.com/distributions/gradle-7.4.2-bin.zip

cd /downloads/gradle

sudo unzip gradle-7.4.2-bin.zip -d /opt

sudo ln -s /opt/gradle-7.4.2 /opt/gradle

sudo nano /etc/profile.d/gradle.sh

#/bin/bash

export GRADLE_HOME=/opt/gradle

export PATH=/opt/gradle/bin:${PATH}

sudo chmod +x /etc/profile.d/gradle.sh

source /etc/profile.d/gradle.sh

—

번외 rabbit mq 안도커

kotlin spring 실행시 Task :compileKotlin FAILED e: java.lang.OutOfMemoryError: Java heap space 에러

seoft — Thu, 5 May 2022 13:13:10 +0900

원래 잘 되던 kotlin spring boot 서버를 실행했더니 다음 에러를 출력하며 빌드 fail 발생

> Task :compileKotlin FAILED

e: java.lang.OutOfMemoryError: Java heap space

램 옵션 관련된 다양한 솔루션이 있었으나, 다음 명령어로 해결볼 수 있었다

gradle clean test ( in project dir )

또한 찾은곳에서 위 명령어가 안 될 경우 (작성자기준 코틀린 1.5.21 기준) 그 다음 스탭으로 다음 솔루션을 제시하였으나 나는 위 옵션으로 해결되어 해보진않았다

gradle.properties 파일에 다음 명령어 추가

org.gradle.jvmargs=-Duser.country=US -Dkotlin.daemon.jvm.options=-Xmx2400m -Dfile.encoding=UTF-8

삽질어록

seoft — Sat, 19 Feb 2022 20:09:17 +0900

- AlarmChannel 개발할때 NotificationManager::createNotificationChannel 사용시 이미 존재하는기존 ChannelId를 할당할 경우 NotificationChannel 설정이 덮어씌어지지 않고 기존게 유지되는사항 개발때 염두필요

추후작성

seoft — Sun, 16 Jan 2022 03:06:40 +0900

Execution failed for task ':app:kaptDebugKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.gradle.internal.KaptWithoutKotlincTask$KaptExecutionWorkAction
   > java.lang.reflect.InvocationTargetException (no error message)

위와 같이 세부적인 에러를 출력하지 않을경우 다음 명령어 gradle.properties 에 기입

kapt.use.worker.api=false
kapt.incremental.apt=false

자동완성 안됨 / javax.net.ssl.SSLHandshakeException: Chain validation failed

seoft — Sun, 12 Dec 2021 13:18:59 +0900

코드랩 도중에 초기 설정 시행착오에 관한 기록

https://developer.android.com/codelabs/advanced-kotlin-coroutines?hl=ko#0

자동완성 안됨 :

별도의 개인 프로젝트에서는 그래들버전이 동일한데도 자동완성이 잘되나 코드랩 예제를 열었을때는 되지않았다

그래들 버전 4.1.2 -> 7.0.4

javax.net.ssl.SSLHandshakeException: Chain validation failed :

위의 에러로 네트워킹 오류가 발생하여 예제엡 초기에서 진행이 잘 안되어 검색 후

1. 시간대가 안맞다(약 10일후로 시간대가 맞춰져있어서 avd 의 auto시간 설정을 풀고 직접설정) -> 그래도안됨 (이게 해결을위한 중간에 필수항목인지 의문)

2. avd 끈후에 avd manager 에서 cold reboot

ref : https://stackoverflow.com/questions/45923747/android-emulator-chain-validation-failed-connecting-developers-machine-with-se/51767841

https://stackoverflow.com/questions/29159242/auto-complete-not-working-in-android-studio (여기 그래들 버전관련 언급으로 7.0.4 시도)

리사이클러뷰 보일러 플레이트 최소화 방안 (with Antonio)

seoft — Sat, 13 Nov 2021 20:07:40 +0900

개요

최근 들어 리사이클러뷰가 포함되지 않는 앱이 거의 없을 정도이고 앱의 요구사항이 복잡해지면서 멀티타입이나 중첩 구조도 쉽게 접할 수 있습니다. 리사이클러뷰의 구성을 위해서는 아답터와 뷰홀더도 함께 구성해야 하지만, 특이한 케이스가 아니라면 불필요한 보일러플레이트 코드로도 자리매김할 수 있어 보입니다.

이번 포스팅에서는 리사이클러뷰 구성시 아답터와 뷰홀더의 보일러플레이트를 최소화하는 방법과 관련된 라이브러리 또한 소개하고자 합니다.

샘플 프로젝트 소개

여러 방식 비교를 위해 리스트를 페이징 하는 간단한 샘플 프로젝트를 구성하였습니다. (링크)

설명을 덧붙이면 다음과 같습니다.

- 동일 시나리오 세 가지 방식 구성
   - A. 일반적인 리사이클러뷰 구성
   - B. 바인딩을 통한 보일러플레이트 감소 방안의 리사이클러뷰 구성
   - C. Antonio 라이브러리를 사용한 리사이클러뷰 구성 (B방법에서 개선되고 다양한 기능들을 포함하고 있는 라이브러리)
- MVVM 아키텍처와 연동하여 간단한 페이징 시나리오 구성
- 세 개의 멀티타입 뷰홀더 구성

공통 구성

세 가지 방식에서 차이점은 아답터, 뷰홀더의 유무와 없을 경우에 대체를 위한 처리방안이 차이가 있고, 그 외에는 대부분 구성이 동일합니다. 다음 코드들은 세 가지 구성 중 동일하거나 비슷한 맥락을 가지고 있는 부분입니다.

Mock 데이터를 위한 인터페이스이며 서버 데이터라 가정하고 구성돼있습니다.

Mock 에서 발행되는 데이터를 각 구성의 Ui모델에 맞게 맵핑하는 역할을 합니다. 여기 코드는 같은 맥락이지만 각각 방식에 따라 다르게 구성되어있습니다.

뷰모델에서의 일부 코드입니다.

생성자로 MockApi 인터페이스의 실 구현체가 주입됩니다.

loadMoreUiModels 함수 내에서 Mock 을 통해 리스트를 받아 맵핑을 진행 후 uiModels LiveData로 결과가 구성됩니다.

엑티비티에서의 일부 코드입니다.

onCreate 혹은 페이징 로직에서 viewModel.loadMoreUiModels() 를 호출합니다

uiModels LiveData 를 옵저빙하고 있고 각 방식에 맞게 리사이클러뷰 출력을 진행합니다.

뷰홀더에서 터치 이벤트로 콜백을 처리하기 위한 인터페이스이며 각각 방식의 모델에 맞게 인자가 구성되어있습니다.

뷰홀더 아이템의 xml 파일 중 일부 파일입니다.

각각 방식에 따른 xml 들이 타입마다 3개씩 존재하며, variable 구성도 사용하는 모델과 인터페이스에 알맞게 구성되어있습니다.

밑에 세 가지 구성은 모두 해당 공통 구성에 따른 플로우를 따라가게 됩니다.

A. 일반적인 구성

일반적으로 리사이클러뷰를 구성할 때의 코드입니다. 뷰홀더가 존재하고 아답터에 포함되며, 아답터는 리사이클러뷰에 주입되어 사용됩니다.

일반적인 구성에서만 존재하는 아답터와 뷰홀더입니다.

onCreateViewHolder 함수와 뷰홀더 파일에서 비효율적으로 반복되는 코드가 존재합니다.

액티비티 일부 코드입니다.

생성한 NormalAdapter 의 submitList 를 통해 리스트를 출력합니다.

B. 바인딩을 통한 보일러플레이트 감소 방안의 리사이클러뷰 구성

보일러플레이트를 최소화하고자 관련된 유틸성 클래스가 사전에 준비되어있어야 합니다. (링크)

*A방식과 동일한 뷰모델, 모델, 맵퍼를 사용합니다

유틸성 클래스들로 유틸성 뷰홀더와 사용하여 구현된 아답터, UI모델을 layoutId와 매칭 시켜주는 모델로 구성되어 있습니다.

액티비티 일부 코드입니다.

위의 유틸클래스를 통해 아답터를 양식에 맞게 생성하며 옵저빙 하는 곳에서 submitList 직전 모델에 layout 을 매칭시켜주고 있습니다.

A방법과 비교하였을 때 아답터와 뷰홀더에 대한 코드에 대한 일부 매칭하는 부분만 작성해주면 되고 타입이 다양할수록 보일러플레이트는 감소합니다.

이렇게 구성이 가능한 이유는 xml에서 사용되는 variable의 변수 네임이 BR클래스로 할당되고 ViewDataBinding 의 setVariable 함수를 통해 BR클래스에 매칭되는 variable 변수에 특정 값을 넣을 수 있기 때문입니다.

A방법의 아답터의 onCreateViewHolder와 뷰홀더의 반복되는 코드들이 엑티비티에서 아답터 구성을 시작으로 뷰홀더의 xml 까지 딜리버리 되면서 대체되게 됩니다.

A방법의 아답터와 뷰홀더의 보일러플레이트는 많이 감소하였지만, BindingItem 클래스에 한번 감싸 져 있는 게 코드 사용처로부터 신경 쓰면서 구현해야 된다는 점과 submitList 직전 각 데이터 타입에 따라 전처리가 필요한 점은 아쉽습니다.

C. Antonio 라이브러리를 사용한 리사이클러뷰 구성

NaverZ 사에서 제공하는 리사이클러뷰, 뷰페이져 구성을 위한 오픈소스라이브러리입니다. 실제 메타버스 프로젝트인 ZEPETO 서비스에서 활용되는 것으로 알고 있습니다.

https://github.com/naverz/Antonio

GitHub - naverz/Antonio: Android library for the adapter view (RecyclerView, ViewPager, ViewPager2)

Android library for the adapter view (RecyclerView, ViewPager, ViewPager2) - GitHub - naverz/Antonio: Android library for the adapter view (RecyclerView, ViewPager, ViewPager2)

github.com

부분적으로 B방법에서 비슷한 맥락으로 구성되는 부분도 포함돼있지만 사용 방식이 훨씬 개선되었습니다.

뿐만 아니라 다음 장점들이 있습니다.

- DiffUtil 을 통한 구성 외의 기존 notifyXXX 등 다양한 지원범위

- 중첩의 중첩 관계에서 뷰 관리를 위한 LiveData 옵저빙 지원

- LifeCycleOwner 자동 주입

- annotation 을 통한 생성 자동화

- 등등...

라이브러리 사용을 위해서 사전에 그래들 설정이 필요합니다

A, B방식과 다르게 UI모델에서 AntonioBindingModel 의 구현이 필요하며 여기서 사용할 xml과 UI모델이 매칭될 xml variable 변수를 결정합니다.

Antonio 에서는 리사이클러뷰 상태를 관리하는 고수준 클래스인 SubmittableRecyclerViewState 라는 개념이 사용되고 있고, 이는 DIffUtil 만 구성하여 손쉽게 구성할 수 있습니다.

setState 라는 확장함수를 통하 리사이클러뷰에 설정이 되며 사용방법은 동일하게 submitList로 사용할 수 있습니다.

B방식과 다르게 고수준으로 캡슐화돼있어 별도로 신경 쓸 사항 없이 보일러플레이트를 최소화하면서 리사이클러뷰를 구성할 수 있습니다.

내부 원리는........ ~~저는 아직 잘 이해를 하지 못한 상태입니다.~~

하지만 2021 드로이드나이츠에서 발표한 내용으로 Antonio 관련한 개요부터 발전단계와 내부 구성에 대한 세부 설명도 포함되어있으니 참고 바랍니다.

https://youtu.be/mqY3GWid7ug

결론

일반적으로 리사이클러뷰를 구성하는 방식과 보일러플레이트를 낮추는 전략, 관련된 라이브러리까지 함께 알아보았습니다. 리사이클러뷰나 뷰페이져의 특별한 구성이 필요할 경우에는 세부적인 커스텀을 위해서 직접 아답터와 뷰홀더를 구성하는 것도 필요하겠지만 대부분의 요구사항은 보일러 플레이트를 감소시키면서 구성할 수 있을 것 같습니다.

또한 프로젝트 구성에 따라 리사이클러뷰가 여러 페이지에서 반복되지 않는 상황이면 B, C방식을 이해하고 도입하는 버든이 더 들 수도 있어 보이지만, 일반적으로는 잘 사용될 수 있는 방안일 것 같습니다.

긴 글 읽어주셔서 감사합니다.

버전 코드는 이미 사용되었습니다. 다른 버전 코드를 사용해 보세요.

seoft — Sat, 16 Oct 2021 00:12:29 +0900

DiffUtil 아이템 개수와 데이터 교체 방법에 따른 종합 성능 테스트

seoft — Sun, 3 Oct 2021 22:55:43 +0900

개요

개인적으로 리사이클러뷰를 구현할 때 DiffUtil을 엄청 믿고 신뢰하며 사용해왔었는데, 팀 내에서 수동적인 notifyXXX 갱신 방식과 DiffUtil 방식의 차이에 대해 잠시 이야기가 나왔습니다.

notifyXXX 는 변경대상을 알고 대상 부분에만 변경요청을 하는데 비해, 디프유틸을 사용하게 되면 하나의 아이템에 대한 변경을 위해서 full size diff 를 검사가 필요하기 때문에 성능적인 측면에서 비효율적인 것은 사실입니다.

하지만 예전부터 디바이스 성능이 상향 표준화가 되면서 DiffUtil 도입시의 성능갭이 별로 차이가 나지 않는다면 구현 혹은 유지보수의 용이성과 티가 안나는 성능차이는 트레이드오프할 가치가 있을 것이고 그렇기에 구글 프레임워크에도 포함되어 나오고 있는 거라 생각하고 있었고,
그렇다면 어느 수준의 요구사항까지 DiffUtil의 성능이 커버가 될지, 리스트의 갯수 혹은 아이템 변경 방법에 따른 사용성에 어떤 영향을 미칠지 궁금하여 테스트를 진행해봤습니다.

구글에서 설명하는 DiffUtil

구글 디벨롭문서에서 DiffUtil 관련하여 기재된 사항중 성능과 테스트 관련하여 작성해보겠습니다.
https://developer.android.com/reference/androidx/recyclerview/widget/DiffUtil

DiffUtil 내부에서 Myers Difference 알고리즘을 사용하며 성능은 다음과 같습니다.

변경점을 찾는 비용
공간복잡도 : O(N)
시간복잡도 : O(N + D^2)

M의 추가항목과 N의 제거항목을 찾게 될 : O(MN)의 추가 시간복잡도

또한 다음과 같은 성능 지표를 안내하고 있습니다.

테스트 환경

- 디바이스 Nexus5 (OS M)
- random UUID (36 사이즈의 스트링?) 아이템

100 items and 10 modifications: avg: 0.39 ms, median: 0.35 ms
100 items and 100 modifications: 3.82 ms, median: 3.75 ms
100 items and 100 modifications without moves: 2.09 ms, median: 2.06 ms
1000 items and 50 modifications: avg: 4.67 ms, median: 4.59 ms
1000 items and 50 modifications without moves: avg: 3.59 ms, median: 3.50 ms
1000 items and 200 modifications: 27.07 ms, median: 26.92 ms
1000 items and 200 modifications without moves: 13.54 ms, median: 13.36 ms

테스트 앱 구성

구글에서 제공하는 대략적인 성능 평가가 있었지만 저는 다음 두 사유로 직접 테스트를 진행하게 되었습니다.

- Nexus5 기기가 13년도의 오래된 단말기라 현시점의 비교적 성능이 업된 단말기에서의 결과 도출하기 위함
- 디벨롭 문서에 기재된 수정 케이스 뿐만 아니라 추가, 셔플, 삭제 등의 더 다양한 케이스에서의 결과 도출하기 위함

테스트를위해 앱을 구현하였고 테스트앱은 여기서 만나보실 수 있습니다

-> https://github.com/seoft/android-laboratory/tree/dev/diff-util-test

GitHub - seoft/android-laboratory

Contribute to seoft/android-laboratory development by creating an account on GitHub.

github.com

테스트앱 스크린샷

테스트 환경

- 현 시점에 적당히 마지노선의 단말기(?)인 갤럭시 S8(OS 9)로 테스트
- 기존 테스트의 UUID 보다는 실제 유즈케이스와 더 밀접한 환경(?)
- 멀티타입의 뷰홀더
- 실제 모델 id값으로 areItemsTheSame을, ui 변경대상 파라미터만으로 areContentsTheSame 로 비교
- payload 전달로 뷰 부분 업데이트 진행
- 테스트 케이스 : 순차적 추가, 랜덤 추가, 삭제, 셔플, 수정, (단일 추가,수정,삭제)
- 테스트 개수 범위 : 200*n (~1000) , 5000*n (~50000)
- 단일 업데이트 경우 인덱스 마지막 부근에서 진행

* 부분 삭제, 변경 경우 다음 테스트 갯수(last 25000)에서 다음 테스트갯수 - 현 테스트 갯수만큼 진행,(ex, 2번째 테스트 경우 600개에서 200개 수행)

테스트 결과

테스트 결과는 다음과 같습니다. 각 항목을 10번 진행하여 평균낸 결과이며, 20초가까이 넘어가는 내용들은 무의미하다고 판단하여 복수 테스트는 하지않았습니다.

*평균내기 전 raw 값도 포함된 excel 파일은 github 테스트앱 프로젝트 디렉토리에 포함되있습니다.

결론

테스트 결과를 보고 몇 가지 기술하자면,

- 전체 셔플에 대한 비교수행 비용은 굉장히 큽니다.(충분히 나올 수 있는 요구사항이고, 셔플범위가 넓을 경우에는 삭제 후 새로 추가하는게 더 용이해보입니다)
- 리사이클러뷰가 디폴트로 애니메이션 가지게 되는데 이를 off 할 경우 리스트 갯수와 추가타입에 따라 성능차이가 있을 수 있습니다.
- 개인차가 있어 몇 ms부터 느리다고 판단하기는 힘들지만 랜덤 추가방식 경우 2000개, 삭제 경우 6000개 이상이 될 경우 160ms, 200ms 가 넘으면서 사용자 입장에서 반응이 느리게 느껴질 수도 있을듯합니다.
- 제가 주로 리스트를 구성할 때에는 페이징과 부분 아이템의 일부의 상태를 교체하는 요구사항이 일반적인 것 같습니다. 이러한 요구사항에서는 아이템의 갯수가 많아져도 크게 무리가 되지 않아 보입니다. (이 부분은 특정 리스트 기능을 사용할때 유저의 max 페이징 수 지표가 파악되면 더 좋을듯하네요..)

조심스럽게..

" 일반적인 요구사항에서는 DiffUtil을 도입해도 충분히 괜찮으나, 리스트 구성이나 사용방식에 대해 특이사항이 있을 경우 성능 검토 고려가 필요하다 "

로 개인적으로 결론지어봅니다.

위에 테스트 프로젝트 구성 외에도 디바이스 환경이나 실제 구성에서의 diff 조건, 뷰홀더명세 등등 테스트 결과에 영향이 미치는 요소가 더 있기 때문에, 제가 가정한 조건에 따른 결과임을 염두 부탁드리며, 추가로 필요시 코드 수정해서 테스트 하셨으면 하는 바램으로 공유드립니다.

읽어주셔서 감사합니다.