시배's Android

[RevenueCat] DroidKnights 2025 컨퍼런스 후기

si8ae — Mon, 23 Jun 2025 20:52:03 +0900

지난주, 대한민국 최대 안드로이드 개발자 행사인 드로이드나이츠 2025에 다녀왔습니다.
주니어부터 시니어까지 모든 안드로이드 개발자들이 모여 지식을 나누고 공감하는 뜻깊은 자리였는데요,
저 역시 다양한 세션을 들으며 많은 인사이트를 얻을 수 있었습니다.

✨ 내가 들은 세션 & 소감

✅ ReadMoreTextView : 텍스트 ‘더보기’ 기능 구현하기

기존 라이브러리의 약간의 깜빡임 문제를 개선한 새로운 구현이 인상적이었습니다.
특히 RTL(LTR 포함) 까지 고려해서 작성된 점이 정말 신기했고, 발표자의 세심함이 느껴졌습니다.

✅ Benchmark와 BaselineProfile을 사용해 LazyColumn 스크롤 성능을 75% 개선하기까지의 여정

Benchmark를 활용해 스크롤 성능을 수치로 측정하고 이를 개선하는 과정이 흥미로웠습니다.
다만, 발표 제목과 달리 BaselineProfile 활용 사례는 부족해서 조금은 아쉬움이 남았습니다.

✅ 전방위 자동화 시대, CI/CD를 넘어 PM과 QA까지 확장하기

현재 회사에서는 이미 잘 구축된 CI/CD 덕분에 편하게 일하고 있지만,
자동화가 PM과 QA까지 확장되는 사례를 보며 앞으로 더 고민해야 할 부분이라는 생각이 들었습니다.

✅ Android에서 실현 가능한 모든 AI

On-device AI를 가능하게 하기 위해 nano 모델을 별도로 제공한다는 점이 놀라웠습니다.
특히 Gemini를 활용한 국내 사례로 우리 회사가 소개된 부분은 반갑고 신기했습니다!

✅ 당신의 클린아키텍처는 틀렸다

발표자의 의견에 대부분 공감하며 들을 수 있었던 세션이었습니다.
기존에 생각하던 클린 아키텍처의 관점을 다시 돌아보게 되는 계기가 되었습니다.

✅ 나도 edgeToEdge 적용하기 싫어. 근데 누군가는 해야 하잖아?

현재 회사에서도 edgeToEdge 적용 시 dialog 관련 이슈로 골머리를 앓고 있었는데,
이 발표 덕분에 실마리를 찾고 회사 이슈를 해결할 수 있었습니다. 정말 유익한 세션이었습니다.

RevenueCat 부스 후기

RevenueCat 부스는 귀여운 양말을 나눠주며 관람객들의 발걸음을 사로잡았습니다.
부스에서 QR코드를 스캔하면 추첨 이벤트에 참여할 수 있었고,
skydoves 님의 Manifest Android Interview 책과 키보드를 경품으로 받을 기회도 있었습니다.

책 내용을 살펴보니 예제 코드와 설명이 디테일하고 색상 강조도 잘 되어 있어 가독성이 뛰어났습니다.
가격이 꽤 있는 편이라 회사에서 구매를 검토했지만, 이름이 Interview 라 눈치가 보여 쉽지 않을 것 같고,
개인적으로 조만간 구매할 생각입니다.

RevenueCat 소개

In-App Subscriptions Made Easy – RevenueCat

The world’s best apps use RevenueCat to power in-app purchases, manage customer data, and grow revenue across iOS, Android, and the web.

www.revenuecat.com

RevenueCat은 개발자들이 더 많은 수익을 올릴 수 있도록 돕는 서비스입니다.
인앱 구매, 구독, 페이월 기능을 손쉽게 구현하고, 고객 데이터를 관리하며 수익화 전략을 최적화할 수 있도록 지원합니다.

주요 특징:

연간 11조 원 이상의 인앱 결제를 처리
손쉬운 페이월 커스터마이징 및 게시
A/B 테스트를 통한 수익 극대화 및 사용자층 맞춤 전략 최적화
서버 드리븐 UI 기반 A/B 테스트, LTV 보고서, 다양한 수익화 기능 제공
비개발 직군도 사용 가능한 간편한 관리 UI

RevenueCat 부스를 통해 서비스 철학과 다양한 기능을 직접 들을 수 있었고,
인앱 결제 및 구독 관리의 최신 트렌드를 이해하는 좋은 기회였습니다.

마치며

드로이드나이츠 2025는 다양한 인사이트와 영감을 얻을 수 있는 값진 자리였습니다.
세션과 부스 모두 알차게 즐길 수 있었고, 내년 행사도 벌써부터 기대됩니다!

Android | Server Driven UI 구현하기 with Custom KSerializer

si8ae — Thu, 12 Dec 2024 16:42:40 +0900

Server-Driven UI

Server-Driven UI는 서버에서 UI를 정의하고 클라이언트에서 이를 동적으로 렌더링하는 방식으로, 서버에서 전달되는 JSON 형식을 파싱하여 적절한 UI를 생성하는 것이 핵심입니다. 이번 글에서는 Kotlin Serialization의 KSerializer를 사용하여 JSON 형식을 커스텀 파싱하는 방법에 대해 다룹니다.

왜 KSerializer가 필요한가?

일반적으로 JSON 데이터를 Kotlin 데이터 클래스로 매핑할 때는 Kotlin Serialization에서 제공하는 기본적인 매핑 기능을 사용할 수 있습니다. 하지만 아래와 같이 type이 JSON 키로 사용되고, 데이터가 해당 키의 값으로 내려오는 구조라면, 이를 효과적으로 처리하기 위해 Custom KSerializer가 필요합니다.

Json 데이터 예시 :

{
    "Row" : {},
    "Column" : {},
    "Text" : {},
    "Image" : {},
}

위 데이터를 파싱하려면 type과 이를 기반으로 한 UI 컴포넌트 매핑이 필요합니다. 이를 위해 Kotlin의 KSerializer를 사용해 맞춤형 디코딩 로직을 구현할 수 있습니다.

목표 Kotlin 구조

@Serializable
sealed interface UiComponentResponse

@Serializable(with = UiComponentResponseWrapperSerializer::class)
data class UiComponentResponseWrapper(
    val type: String,
    val component: UiComponentResponse,
)

UiComponentResponse는 다양한 UI 컴포넌트를 나타내는 sealed interface이며, 이를 감싸는 UiComponentResponseWrapper는 JSON 데이터를 type과 component로 구분하여 파싱할 수 있도록 설계되었습니다.

Custom KSerializer 구현하기

KSerializer는 Kotlin Serialization에서 커스텀 직렬화/역직렬화 로직을 구현하는 핵심 도구입니다. 아래는 UiComponentResponseWrapper를 처리하기 위한 Custom KSerializer의 구현입니다.

object UiComponentResponseWrapperSerializer : KSerializer<UiComponentResponseWrapper> {
    override val descriptor: SerialDescriptor =
        buildClassSerialDescriptor("UiComponentResponseWrapper") {
            element("type", String.serializer().descriptor)
            element("component", buildClassSerialDescriptor("UiComponentUnion"))
        }

    override fun deserialize(decoder: Decoder): UiComponentResponseWrapper {
        val jsonObject = (decoder as? JsonDecoder)?.decodeJsonElement()?.jsonObject
            ?: throw SerializationException("Expected JSON object")

        val entry = jsonObject.entries.firstOrNull()
            ?: throw SerializationException("Empty JSON object")

        val type = entry.key

        val element = when (type) {
            "Text" -> Json.decodeFromJsonElement<TextResponse>(entry.value)
            "Column" -> Json.decodeFromJsonElement<ColumnResponse>(entry.value)
            "Row" -> Json.decodeFromJsonElement<RowResponse>(entry.value)
            "Box" -> Json.decodeFromJsonElement<BoxResponse>(entry.value)
            "Image" -> Json.decodeFromJsonElement<ImageResponse>(entry.value)
            "HorizontalGrid" -> Json.decodeFromJsonElement<HorizontalGridResponse>(entry.value)
            "VerticalGrid" -> Json.decodeFromJsonElement<VerticalGridResponse>(entry.value)
            "Icon" -> Json.decodeFromJsonElement<IconResponse>(entry.value)
            "Spacer" -> Json.decodeFromJsonElement<SpacerResponse>(entry.value)
            "List" -> Json.decodeFromJsonElement<ListResponse>(entry.value)
            "Divider" -> Json.decodeFromJsonElement<DividerResponse>(entry.value)
            "LazyColumn" -> Json.decodeFromJsonElement<LazyColumnResponse>(entry.value)
            "LazyRow" -> Json.decodeFromJsonElement<LazyRowResponse>(entry.value)
            "TopAppBar" -> Json.decodeFromJsonElement<TopAppBarResponse>(entry.value)
            "HorizontalPager" -> Json.decodeFromJsonElement<HorizontalPagerResponse>(entry.value)
            "VerticalPager" -> Json.decodeFromJsonElement<VerticalPagerResponse>(entry.value)
            else -> throw SerializationException("Unknown component type: $type")
        }

        return UiComponentResponseWrapper(type, element)
    }

    override fun serialize(encoder: Encoder, value: UiComponentResponseWrapper) {
        val jsonObject = buildJsonObject {
            put(value.type, Json.encodeToJsonElement(value.component))
        }
        (encoder as? JsonEncoder)?.encodeJsonElement(jsonObject)
    }
}

주요 구현 포인트

Descriptor 정의
- UiComponentResponseWrapper의 구조를 정의하여 JSON 직렬화/역직렬화 시 사용합니다.
- type은 JSON 키, component는 값으로 매핑됩니다.
deserialize
- JSON 데이터를 디코딩하여 첫 번째 엔트리(type)에 따라 적절한 데이터 클래스를 생성합니다.
- when 문을 통해 타입별 매핑을 처리합니다.
serialize
- Kotlin 객체를 JSON으로 변환할 때 type과 component를 포함하는 JSON 객체를 생성합니다.

예시

Firebase Realtime Database를 활용하여, 저의 사이드 프로젝트인 Cherish 앱의 메인 화면을 JSON 형태로 서버에서 내려받아 Server-Driven UI로 구현해 보았습니다.

https://github.com/koreatlwls/server-driven-ui

Android | Firebase Realtime Database를 더 쉽게 사용하기

si8ae — Mon, 25 Nov 2024 09:45:33 +0900

Firebase Realtime Database를 더 쉽게 사용하기: flowList() 함수로 오픈소스 기여 이야기

GitHub - skydoves/firebase-android-ktx: Kotlin & Compose-friendly Firebase extensions designed to help you focus on your bu

Kotlin & Compose-friendly Firebase extensions designed to help you focus on your business logic. - skydoves/firebase-android-ktx

github.com

안녕하세요! 이번 글에서는 제가 최근에 firebase-android-ktx 오픈소스 프로젝트에 기여한 경험을 공유하고자 합니다. 이 글에서는 제가 추가한 flowList() 함수의 동작 원리, 작성 배경, 그리고 오픈소스에 기여하면서 느낀 점을 다뤄보겠습니다.

️ 기여한 내용: flowList() 함수

문제 상황

Firebase Realtime Database를 사용하다 보면 리스트 형식으로 데이터를 저장하고 이를 읽어오는 경우가 많습니다. 하지만 기존의 API는 데이터 변화를 비동기적으로 감지하기 어렵고, 이를 간편하게 처리하기 위한 유틸리티 함수가 부족했습니다.

저는 이러한 필요성을 느끼고, 데이터를 Flow<Result<List<T?>>> 타입으로 반환하는 flowList() 함수를 추가했습니다. 이 함수는 데이터를 실시간으로 구독할 수 있고, Result를 통해 성공과 실패를 명확히 구분합니다.

‍ 추가한 코드: flowList()

public fun <T : Any> DatabaseReference.flowList(
  path: (DataSnapshot) -> DataSnapshot,
  decodeProvider: (String) -> T
): Flow<Result<List<T?>>> = callbackFlow {
  val listener = object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
      val children = path.invoke(snapshot).children
      val result = mutableListOf<T?>()
      for (data in children) {
        result.add(data.serializedValue(decodeProvider))
      }
      trySend(Result.success(result))
    }

    override fun onCancelled(error: DatabaseError) {
      trySend(Result.failure(error.toException()))
    }
  }
  addValueEventListener(listener)
  awaitClose { removeEventListener(listener) }
}

코드 설명

callbackFlow를 사용한 Flow 생성
이 함수는 callbackFlow를 활용해 Firebase의 ValueEventListener 이벤트를 Flow로 변환합니다.
path를 통한 데이터 경로 설정
path는 DataSnapshot에서 필요한 하위 데이터를 선택할 수 있도록 제공합니다.
decodeProvider를 통한 데이터 디코딩
각 데이터 항목을 디코딩하는 방법을 decodeProvider로 정의할 수 있어 다양한 타입의 데이터를 처리할 수 있습니다.
Result를 활용한 상태 관리
데이터를 성공적으로 가져오거나 실패 시 예외를 반환하는 구조로 안정성과 가독성을 높였습니다.

동기: 왜 이 기능이 필요했는가?

이 기능은 제가 진행하던 Server-Driven UI 프로젝트에서 필요성을 느껴 기여하게 되었습니다. 해당 프로젝트는 UI와 데이터를 서버에서 받아 동적으로 렌더링해야 했고, 리스트 데이터를 실시간으로 구독해야 했습니다. 기존 API로는 비효율적이라 이를 더 간결하게 처리할 수 있는 유틸리티 함수가 필요했죠.

✨ 결론

이번 기여는 Firebase Realtime Database를 더 쉽게 사용할 수 있도록 돕기 위한 작은 발걸음이었지만, 저에게는 큰 의미가 있었습니다. 앞으로도 다양한 오픈소스 프로젝트에 기여하며 개발자로서 성장해 나가고 싶습니다.

Android | Build Optimization (2)

si8ae — Fri, 4 Oct 2024 19:36:11 +0900

Gradle 옵션을 활용한 Build Optimization

대규모 Android 프로젝트에서 빌드 시간이 느려지는 것은 큰 생산성 저하를 야기할 수 있습니다. 이 문제를 해결하기 위해, Gradle은 다양한 빌드 최적화 옵션을 제공하고 있으며, 이를 적절히 활용하면 빌드 시간을 크게 단축할 수 있습니다. 이번 포스트에서는 Gradle 옵션을 통해 실제로 빌드 시간을 얼마나 줄일 수 있는지 그 과정을 공유하고, 각 옵션에 대해 설명하겠습니다.

기본 환경에서의 빌드 시간

우선, 아무 옵션도 적용하지 않은 기본 프로젝트 환경에서의 빌드 시간을 측정했습니다.

Clean Build -> Build APK
결과: 1분 52초
처음에는 기본적인 clean 빌드를 수행했으며, 상당히 긴 시간이 소요되는 것을 확인했습니다.

이제 Gradle 최적화 옵션을 하나씩 적용해 보며, 빌드 시간을 얼마나 줄일 수 있는지 확인해보겠습니다.

org.gradle.parallel=true 옵션

org.gradle.parallel=true 옵션을 활성화하면 Gradle은 가능한 경우 여러 작업을 병렬로 실행합니다. 특히 멀티모듈 프로젝트에서 각 모듈의 독립적인 작업들이 병렬로 수행되면서 빌드 시간이 단축될 수 있습니다.

적용 방법
프로젝트의 gradle.properties 파일에 다음을 추가합니다:

org.gradle.parallel=true

빌드 결과
결과: 1분 26초
빌드 시간이 약 26초 단축되었습니다. 이는 Gradle이 여러 모듈을 동시에 빌드하면서 빌드 과정의 효율성을 높였기 때문입니다. 이 때, Gradle Configuration 시간은 약 11초가 소요되었습니다.

org.gradle.unsafe.configuration-cache=true 옵션

org.gradle.unsafe.configuration-cache=true 옵션은 Gradle 빌드의 구성 단계(configuration phase)를 캐시하여, 동일한 설정의 빌드를 다시 할 때 빌드 구성을 재활용할 수 있게 합니다. 이를 통해 구성 단계에 소요되는 시간을 절감할 수 있습니다.

적용 방법
프로젝트의 gradle.properties 파일에 다음을 추가합니다:

org.gradle.parallel=true
org.gradle.unsafe.configuration-cache=true

빌드 결과
결과: 1분 20초
빌드 시간이 더 줄었으며, 구성 단계 시간도 7초로 줄어들었습니다. Configuration Cache 덕분에, 동일한 빌드를 여러 번 반복할 때 빌드 구성을 캐시에서 재사용함으로써 불필요한 설정 작업이 생략됩니다.

org.gradle.caching=true 옵션과 로컬 빌드 캐시

org.gradle.caching=true 옵션은 작업 결과물(output)을 캐싱하여, 동일한 입력에 대해 동일한 출력이 요구될 때 캐시된 결과를 재사용하도록 합니다. 특히 코드 변경이 없는 상태에서 동일한 작업을 다시 실행할 때 큰 효과를 볼 수 있습니다.

추가적으로 로컬 캐시를 활용하면, 이전 빌드 결과를 로컬 디스크에 저장하여 더 빠른 빌드가 가능합니다.

적용 방법
프로젝트의 gradle.properties 파일에 다음을 추가합니다:

org.gradle.parallel=true
org.gradle.unsafe.configuration-cache=true
org.gradle.caching=true

프로젝트의 setting.gradle.properties 파일에 다음을 추가합니다:

buildCache {
    local {
        isEnabled = true
        directory = File(rootDir, "build-cache")
        removeUnusedEntriesAfterDays = 30
    }
}

빌드 결과
결과: 20초
로컬 캐싱 덕분에 빌드 시간이 20초로 크게 단축되었습니다. 이 옵션은 특히 clean 빌드 이후 변경이 거의 없는 상태에서 빌드를 반복할 때 매우 유용합니다. 빌드가 완료되면 Gradle은 빌드 결과를 캐시에 저장하고, 이후 동일한 작업에 대해 캐시된 결과를 재사용함으로써 빌드 시간이 비약적으로 단축됩니다.

Android | Build Optimization (1)

si8ae — Wed, 2 Oct 2024 17:02:41 +0900

Build Optimization

대규모 안드로이드 프로젝트에서 빌드 시간이 느려지는 것은 개발 생산성을 크게 저해하는 문제 중 하나입니다. 이를 해결하기 위한 방법으로 multi modularization이 자주 언급됩니다. 하지만, 여러 개의 모듈이 단순히 구현체 모듈을 참조하는 구조에서는 여전히 빌드 성능의 한계가 존재합니다. 이는 구현체 모듈에 변경 사항이 생길 때, 이를 참조하는 여러 모듈도 빌드 과정을 거쳐야 하기 때문입니다.

구현체 모듈과 참조 모듈의 문제점

다수의 모듈이 특정 구현체 모듈을 참조할 경우, 해당 구현체가 변경될 때마다 참조하는 모든 모듈이 다시 빌드되는 문제가 발생합니다. 이러한 상황에서는 모듈 분리만으로는 빌드 최적화가 부족하며, 참조 모듈이 불필요하게 빌드되지 않도록 하는 추가적인 전략이 필요합니다.

Dependency Inversion을 활용한 해결책

이 문제를 해결하기 위한 방법 중 하나는 impl(implementation) 모듈과 api 모듈을 분리하는 방식입니다. 이 구조에서는 impl 모듈이 오직 app 모듈에서만 참조되며, 나머지 모듈은 api 모듈을 참조하도록 합니다. 이를 통해 api 모듈을 참조하는 모듈들은 impl 모듈의 변경사항에 영향을 받지 않으며, 추가적인 빌드가 발생하지 않도록 할 수 있습니다.

Android 공식 문서에서도 이 방식을 Dependency Inversion이라는 개념으로 소개하고 있습니다. Dependency Inversion은 구현체(Concrete Implementation)와 추상화(Abstraction)를 분리하여 모듈 간 의존성을 줄이는 방법입니다.

일반적인 모듈화 패턴 | Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. 일반적인 모듈화 패턴 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 모든 프로젝트에 맞는 하나의

developer.android.com

이 방식을 통해, 각 모듈은 구체적인 구현에 의존하지 않고, 추상화된 API에만 의존하게 됩니다.

예시: 데이터베이스 모듈

예를 들어, 어떤 기능 모듈이 데이터베이스에 의존한다고 가정해 봅시다. 이때 해당 기능 모듈은 구체적으로 어떤 데이터베이스를 사용하는지에 대해 알 필요가 없습니다. 로컬 Room 데이터베이스든, 원격 Firestore든 상관없이 데이터만 저장하고 불러오는 역할을 할 뿐입니다.

기능 모듈은 데이터베이스 API를 제공하는 추상화된 모듈에 의존하며, 구체적인 데이터베이스 구현은 별도의 구현체 모듈에서 처리됩니다. 이때 구현체 모듈 역시 추상화 모듈에 의존하여, 추상화된 API 규약을 따르게 됩니다.

의존성 주입(Dependency Injection) 활용

여기서 의문이 생길 수 있습니다. "기능 모듈은 어떻게 구현체 모듈과 연결되는가?" 그 해답은 의존성 주입(Dependency Injection)입니다. 기능 모듈은 필요한 데이터베이스 인스턴스를 직접 생성하지 않고, 외부에서 주입받습니다. 일반적으로는 app 모듈에서 이 역할을 수행하며, Hilt 같은 DI 프레임워크를 사용하여 구현체와 API를 연결할 수 있습니다.

이점

API와 구현체를 분리함으로써 얻을 수 있는 이점은 다음과 같습니다:

교체 가능성(Interchangeability): 동일한 API를 기반으로 여러 구현체를 개발할 수 있으며, 이를 상황에 따라 자유롭게 교체할 수 있습니다. 예를 들어, 테스트 환경에서는 Mock 구현을 사용하고, 실제 배포 환경에서는 실제 구현을 사용할 수 있습니다.
디커플링(Decoupling): 모듈들이 특정 구현체에 의존하지 않기 때문에, 예를 들어 Room에서 Firestore로 데이터베이스를 변경하더라도, 변경 사항은 구현체 모듈에만 영향을 미칩니다.
테스트 용이성(Testability): 구현체를 분리함으로써 API 규약을 기준으로 테스트를 작성할 수 있으며, 다양한 시나리오를 테스트하기 위한 Mock 구현을 쉽게 활용할 수 있습니다.
빌드 성능 향상(Build Performance): API와 구현체를 분리하면, 구현체 모듈의 변경이 API 모듈에 의존하는 다른 모듈에 영향을 주지 않습니다. 결과적으로 불필요한 빌드가 줄어들어 빌드 시간이 단축됩니다.

실제 성능 개선 사례

실제로 위 방식으로 data 모듈을 분리하고 증분 빌드 시간을 측정해본 결과, 약 20초에서 10초 가량의 유의미한 성능 차이를 확인할 수 있었습니다. 이러한 최적화는 대규모 프로젝트에서 개발 속도를 크게 향상시키며, 더 나은 개발 경험을 제공합니다.

Hi Jack Mocker | 개선기 (5) feat.SharedFlow

si8ae — Thu, 25 Jul 2024 21:49:49 +0900

Hi Jack Mocker란?

GitHub - koreatlwls/Hi-Jack-Mocker: Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify net

Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify network requests and responses, allowing you to verify the UI easily. - koreatlwls/Hi-Jack-Mocker

github.com

Hi Jack Mocker는 비개발자도 UI 엣지 케이스를 쉽게 테스트할 수 있도록 돕는 라이브러리입니다. 이 프로젝트는 OkHttp3 인터셉터를 활용하여 네트워크 요청과 응답을 가로채고 수정할 수 있게 합니다. 이를 통해 개발자뿐만 아니라 다양한 사용자들이 다양한 시나리오를 테스트할 수 있게 합니다.

소개

응답을 가로채고 수정한 후 다시 전달하는 과정에서 흥미로운 문제에 직면했고, 이를 해결하는 과정에서 코틀린의 Channel에서 SharedFlow로 전환하게 되었습니다. 이 포스트에서는 그 과정과 학습한 내용을 공유하고자 합니다.

초기 구현 : Channel 사용

처음에는 다음과 같은 방식으로 구현했습니다.

override fun intercept(chain: Interceptor.Chain): Response = runBlocking {
    var response = chain.proceed(chain.request())

    if (hjmDataStore.getHjmMode()) {
        interceptorManager.sendWithInterceptorChannel(response)

        startHjmActivityIfNeeded()
        response = interceptorManager.receiveWithResultChannel()
    }

    return@runBlocking response
}
 suspend fun receiveWithResultChannel(): Response {
    if (resultChannel.isClosedForReceive) {
        resultChannel = Channel(UNLIMITED)
    }

    return resultChannel.receive()
}

이 구현에서는 Channel을 사용하여 HjmActivity에서 수정된 응답을 다시 Interceptor로 전달했습니다.

문제점 인식

이 접근 방식은 단일 요청에 대해서는 잘 작동했지만, 여러 개의 동시 요청을 처리할 때 문제가 발생했습니다. Channel의 특성상 첫 번째로 도착한 응답이 첫 번째로 대기 중인 Interceptor에 전달되는 문제가 있었습니다.

해결책 : SharedFlow 도입

이 문제를 해결하기 위해 SharedFlow를 도입했습니다. SharedFlow는 여러 소비자가 동시에 값을 관찰할 수 있어, 우리의 사용 사례에 더 적합했습니다.

override fun intercept(chain: Interceptor.Chain): Response = runBlocking {
    var response = chain.proceed(chain.request())

    if (hjmDataStore.getHjmMode()) {
        val uuid = UUID.randomUUID().toString()
        interceptorManager.sendEventAtInterceptorEvent(uuid, response)

        startHjmActivityIfNeeded()

        response = interceptorManager.resultEvent.filter { it.first == uuid }.first().second
    }

    return@runBlocking response
}

class InterceptorManager {
    val isHjmActivityRunning = AtomicBoolean(false)

    private val _interceptorEvent = MutableSharedFlow<Pair<String, Response>>(replay = 1)
    val interceptorEvent = _interceptorEvent.asSharedFlow()

    private val _resultEvent = MutableSharedFlow<Pair<String, Response>>()
    val resultEvent = _resultEvent.asSharedFlow()

    suspend fun sendEventAtInterceptorEvent(uuid: String, response: Response) {
        _interceptorEvent.emit(Pair(uuid, response))
    }

    suspend fun sendEventAtResultEvent(uuid: String, response: Response) {
        _resultEvent.emit(Pair(uuid, response))
    }
}

Channel과 SharedFlow의 주요 차이점

1. 데이터 공유 방식:

Channel: point-to-point 통신 방식으로, 하나의 sender와 하나의 receiver가 연결되어 데이터를 주고받습니다. 즉, 각각의 collector는 독립적인 데이터 스트림을 받습니다.
SharedFlow: broadcast 통신 방식으로, 하나의 sender가 여러 receiver에게 동일한 데이터를 전송합니다. 즉, 모든 collector가 동일한 데이터 스트림을 공유합니다.

2. 데이터 버퍼링:

Channel: 버퍼 크기를 지정할 수 있으며, 버퍼가 가득 차면 sender는 receiver가 데이터를 가져갈 때까지 대기합니다. (blocking)
SharedFlow: replay, extraBufferCapacity 설정을 통해 버퍼링 동작을 제어할 수 있습니다. 기본적으로 최신 데이터만 유지하며, 이전 데이터는 버려집니다. (non-blocking)

3. 사용 용도:

Channel: 주로 coroutine 간의 직접적인 통신에 사용됩니다. 예를 들어, producer coroutine에서 생성한 데이터를 consumer coroutine으로 전달하는 데 사용할 수 있습니다.
SharedFlow: 여러 coroutine 또는 컴포넌트가 동일한 데이터를 관찰해야 하는 경우에 유용합니다. 예를 들어, 앱의 상태 변경을 여러 화면에서 관찰해야 하는 경우에 사용할 수 있습니다.

4. Cold vs. Hot:

Channel: cold stream으로, collector가 collect를 호출할 때마다 새로운 스트림이 생성됩니다.
SharedFlow: hot stream으로, collector의 존재 여부와 관계없이 데이터를 방출합니다

Compose | Pager OOM(Out of Memory) issue

si8ae — Fri, 19 Jul 2024 19:56:30 +0900

최근 진행 중인 홈노크타운 프로젝트에서 Hi-Jack-Mocker 라이브러리를 연동하는 과정에서 OOM 문제를 겪었습니다. 이 문제를 해결하기 위해 여러 시도를 해보았고, 그 과정을 공유하고자 합니다.

GitHub - koreatlwls/Hi-Jack-Mocker: Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify net

Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify network requests and responses, allowing you to verify the UI easily. - koreatlwls/Hi-Jack-Mocker

github.com

Hi Jack Mocker는 비개발자도 UI 엣지 케이스를 쉽게 테스트할 수 있도록 돕는 라이브러리입니다. 이 프로젝트는 OkHttp3 인터셉터를 활용하여 네트워크 요청과 응답을 가로채고 수정할 수 있게 합니다. 이를 통해 개발자뿐만 아니라 다양한 사용자들이 다양한 시나리오를 테스트할 수 있게 합니다.

문제의 시작 : 무한 스크롤 배너

홈노크타운 프로젝트 상단 배너: 프로젝트 상단에 사용자가 무한 스크롤할 수 있는 롤링 배너가 존재합니다.
PagerState 설정: 이 배너는 무한 스크롤 기능을 위해 PagerState의 pageCount를 Int.MAX_VALUE로 설정했습니다.

프로젝트 구성과 버전 차이

Compose 버전 차이: 홈노크타운 프로젝트는 비교적 낮은 버전의 Compose를 사용하고 있었습니다. 하지만 HiJackMocker는 최신 Compose 버전을 사용하고 있었습니다.
의존성 추가: 개발 도중 HiJackMocker를 devImplementation에 추가한 후, OOM 문제가 발생하기 시작했습니다.

문제 분석

LeakCanary 사용: 메모리 누수를 의심해 LeakCanary를 추가하여 살펴보았지만, 문제점을 발견하지 못했습니다.
원인 추적: 우연히 배너가 스와이핑되지 않아 배너를 제거하고 확인해보니 OOM이 발생하지 않았습니다. 이를 통해 배너와 관련된 문제가 있다는 것을 알게 되었습니다.

해결 과정

Issue Tracker 확인: Compose의 Issue Tracker를 확인해보니 유사한 문제가 보고되어 있었습니다.
수정 사항 확인: 해당 문제의 수정 사항을 보니, maxScrollOffset을 Int.MAX_VALUE에서 Float.MAX_VALUE로 변경한 것이었습니다.

Google Issue Tracker

issuetracker.google.com

PagerState의 문제점

1. maxScrollOffset 계산

internal fun PagerLayoutInfo.calculateNewMaxScrollOffset(pageCount: Int): Long {
    val pageSizeWithSpacing = pageSpacing + pageSize
    val maxScrollPossible =
        (pageCount.toLong()) * pageSizeWithSpacing + beforeContentPadding + afterContentPadding
    // ... 나머지 코드
}

이 부분에서 pageCount가 매우 크면 maxScrollPossible이 Int.MAX_VALUE를 쉽게 초과할 수 있습니다.

2. 스크롤 계산

private var maxScrollOffset: Int = Int.MAX_VALUE
	private set

private fun performScroll(delta: Float): Float {
    val currentScrollPosition = currentAbsoluteScrollOffset()
    // ... 중간 코드 생략
    val updatedScrollPosition = (currentScrollPosition + decimalAccumulationInt)
    val coercedScrollPosition = updatedScrollPosition.coerceIn(minScrollOffset, maxScrollOffset)
    // ... 나머지 코드
}

여기서 updatedScrollPosition과 coercedScrollPosition이 Int.MAX_VALUE를 초과하는 경우, 이전에는 오버플로우나 부정확한 계산이 발생했을 수 있습니다.

Pager는 일반적으로 가상화 기법을 사용하여 화면에 보이는 항목만 메모리에 유지합니다.
scrollPosition이 잘못 계산되면, 시스템이 실제로 필요한 것보다 훨씬 많은 페이지를 메모리에 로드하려 할 수 있습니다.

3. 리소스 누수

internal fun applyMeasureResult(
    result: PagerMeasureResult,
    visibleItemsStayedTheSame: Boolean = false
) {
    // ... 코드 생략
    pagerLayoutInfoState.value = result
    // ... 나머지 코드
}

잘못된 scrollPosition으로 인해 applyMeasureResult가 부정확한 결과를 적용할 수 있습니다.
이로 인해 더 이상 필요하지 않은 페이지 객체들이 메모리에서 해제되지 않을 수 있습니다.

4. 무한 루프 가능성

private fun notifyPrefetch(delta: Float, info: PagerLayoutInfo) {
    // ... 코드 생략
    val indexToPrefetch = // 계산 로직
    if (indexToPrefetch in 0 until pageCount) {
        // 프리페치 로직
    }
}

indexToPrefetch 계산 시 매우 큰 값이 사용될 수 있으며, 이는 과도한 메모리 사용으로 이어질 수 있습니다.

이러한 부분들에서 Int.MAX_VALUE를 초과하는 값들이 사용될 때 오버플로우, 부정확한 계산, 또는 예상치 못한 동작이 발생할 수 있었고, 이는 결과적으로 과도한 메모리 사용이나 OOM을 유발할 수 있었습니다.

scrollPosition 계산 오류로 인해 notifyPrefetch가 계속해서 새로운 페이지를 프리페치하려 할 수 있습니다.
이는 지속적인 메모리 할당으로 이어질 수 있습니다.

이러한 부분들에서 Int.MAX_VALUE를 초과하는 값들이 사용될 때 오버플로우, 부정확한 계산, 또는 예상치 못한 동작이 발생할 수 있었고, 이는 결과적으로 과도한 메모리 사용이나 OOM을 유발할 수 있었습니다. Float.MAX_VALUE로 변경함으로써 OOM이 발생하지 않게 되었습니다.

향후 계획

안정화 버전 기다리기: 현재 이 수정 사항은 1.7.0-alpha01 버전에만 적용되어 있습니다. 아직 stable 버전으로 올라오지 않았기 때문에, 안정화 버전을 기다려야 할 것 같습니다.

결론

이번 경험을 통해 최신 라이브러리를 사용하는 프로젝트와의 의존성 추가 시 발생할 수 있는 문제를 해결하는 과정을 배웠습니다. 특히, 메모리 관련 문제는 작은 설정 하나로도 큰 영향을 미칠 수 있다는 점을 다시 한번 깨닫게 되었습니다. 앞으로도 꾸준한 모니터링과 최신 정보 확인을 통해 더 안정적인 서비스를 제공할 수 있도록 노력해야겠습니다.

Hi Jack Mocker | 개선기 (4) feat.out of order

si8ae — Sat, 13 Jul 2024 19:55:54 +0900

Hi Jack Mocker란?

GitHub - koreatlwls/Hi-Jack-Mocker: Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify net

Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify network requests and responses, allowing you to verify the UI easily. - koreatlwls/Hi-Jack-Mocker

github.com

Channel의 동시 네트워크 요청 처리 순서 문제

동시에 여러 네트워크 요청을 처리하는 데 어려움이 있었습니다. 처음에는 Kotlin의 채널을 사용하여 모킹된 네트워크 응답을 인터셉터에 전달했습니다. 하지만 채널은 여러 인터셉터 간에 메시지를 공정하게 분배하기 때문에 응답이 순서대로 전달되지 않는 문제가 발생했습니다. 이로 인해 A 데이터를 받아야 하는 요청이 B 데이터를 받는 등의 예기치 않은 문제가 발생했습니다.

future.complete(interceptorManager.receiveWithResultChannel())

suspend fun receiveWithResultChannel(): Response {
	if (resultChannel.isClosedForReceive) {
		resultChannel = Channel(UNLIMITED)
    }

    return resultChannel.receive()
}

위 코드에 보다시피 아무런 조건 없이 receive()를 하다 보니 문제가 발생했습니다.

해결책

이 문제를 해결하기 위해 다수의 구독자가 있는 경우에 적합한 Kotlin의 SharedFlow로 전환했습니다. 추가로 UUID를 도입하여 각 인터셉터가 올바른 응답을 받을 수 있도록 했습니다. 구현 방법은 다음과 같습니다.

각 요청에 대해 UUID 생성: 각 요청-응답 쌍을 고유하게 식별할 수 있도록 합니다.
UUID와 함께 이벤트 전송: 인터셉터가 이벤트를 UUID와 함께 전송합니다.
UUID로 응답 필터링: 응답을 받을 때 UUID로 필터링하여 올바른 응답을 받도록 합니다.

override fun intercept(chain: Interceptor.Chain): Response = runBlocking {
    var response = chain.proceed(chain.request())

    if (hjmDataStore.getHjmMode()) {
        val uuid = UUID.randomUUID().toString()
        interceptorManager.sendEventAtInterceptorEvent(uuid, response)

        startHjmActivityIfNeeded()

        response = interceptorManager.resultEvent.filter { it.first == uuid }.first().second
    }

    return@runBlocking response
}

이를 통해 각 요청이 적절한 응답을 받도록 보장할 수 있었습니다.

Hi Jack Mocker | 개선기 (3) feat.channel data loss

si8ae — Sat, 13 Jul 2024 19:00:49 +0900

Hi Jack Mocker란?

GitHub - koreatlwls/Hi-Jack-Mocker: Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify net

Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify network requests and responses, allowing you to verify the UI easily. - koreatlwls/Hi-Jack-Mocker

github.com

Channel의 send와 consumeEach 동시 호출 시 데이터 유실 문제

문제 상황

private var interceptorChannel = Channel<Response>(UNLIMITED)
private var resultChannel = Channel<Response>(UNLIMITED)
val isHjmActivityRunning = AtomicBoolean(false)

@OptIn(DelicateCoroutinesApi::class)
suspend fun sendWithInterceptorChannel(response: Response) {
    if (interceptorChannel.isClosedForSend) {
        interceptorChannel = Channel(UNLIMITED)
    }
    interceptorChannel.send(response)
}

@OptIn(DelicateCoroutinesApi::class)
suspend fun consumeEachInterceptorChannel(action: (Response) -> Unit) {
    if (interceptorChannel.isClosedForReceive) {
        interceptorChannel = Channel(UNLIMITED)
    }

    interceptorChannel.consumeEach {
        action(it)
    }
}

Hi Jack Mocker 라이브러리는 OkHttp3를 통해 네트워크 응답을 가로채어 이를 모킹하고 UI에 전달합니다. 하지만 간헐적으로 네트워크 요청이 3개가 send 되었지만 1~2개만 receive 되는 문제가 발생하였습니다.

데이터 유실의 원인

초기에는 send와 receive 과정에서 동시성 문제라고 생각하여 mutex를 추가하였습니다.

@OptIn(DelicateCoroutinesApi::class)
suspend fun sendWithInterceptorChannel(response: Response) {
    mutex.withLock {
        if (interceptorChannel.isClosedForSend) {
            interceptorChannel = Channel(UNLIMITED)
        }

        interceptorChannel.send(response)
    }
}

@OptIn(DelicateCoroutinesApi::class)
suspend fun receiveAllWithInterceptorChannel(action: (Response) -> Unit) {
    mutex.withLock {
        if (interceptorChannel.isClosedForReceive) {
            interceptorChannel = Channel(UNLIMITED)
        }

        for (response in interceptorChannel) {
            action(response)
        }
    }
}

이는 문제를 해결하는 것처럼 보였습니다.

실제 원인은 이벤트 순서 문제였으며, 액티비티 종료가 send와 receive 이벤트 이후에 호출되어 데이터가 손실되는 것이었습니다.

모킹된 응답을 UI로 전송.
액티비티 종료 요청.
새로운 네트워크 요청 발생.

비동기 특성상 이벤트가 1, 2, 3 순서대로 처리되지 않고 1, 3, 2 순서로 처리될 수 있었기 때문입니다.

실제로 1, 3, 2 순서로 처리가되어 HjmActivity에서는 빈 리스트를 보여주는 것을 확인할 수 있습니다.

해결책

모든 모킹된 데이터를 전송한 후, onFinishEvent라는 SharedFlow를 사용하여 true를 방출하고 이를 통해 액티비티를 종료했습니다.

그러나 ViewModel에서 인터셉터를 통해 새로운 데이터를 수신할 경우, onFinishEvent에 false를 방출하여 액티비티 종료를 막았습니다. 이때 300밀리초의 debounce를 추가하여 새로운 이벤트가 없고 true가 collect 될때만 액티비티가 종료되도록 했습니다.

LaunchedEffect(Unit) {
    hjmViewModel.onFinishEvent
        .distinctUntilChanged()
        .debounce(300)
        .collectLatest { isFinish ->
            if (isFinish) {
                interceptorManager.isHjmActivityRunning.set(false)
                finish()
            }
        }
}

Hi Jack Mocker | 개선기 (2) feat.JSON 변환 이슈

si8ae — Fri, 12 Jul 2024 18:09:42 +0900

Hi Jack Mocker란?

GitHub - koreatlwls/Hi-Jack-Mocker: Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify net

Hi-Jack-Mocker is a project that leverages OkHttp3's interceptor to intercept and modify network requests and responses, allowing you to verify the UI easily. - koreatlwls/Hi-Jack-Mocker

github.com

SingleItem 클래스의 value 타입을 Any로 변경하여 JSON 변환 문제 해결하기

HiJackMocker 라이브러리의 SingleItem 클래스에서 value의 타입을 String에서 Any로 변경한 이유와 그로 인해 해결한 문제들에 대해 다루겠습니다.

기존의 SingleItem 클래스와 문제점

기존의 SingleItem 클래스는 다음과 같이 value를 String 타입으로 한정하고 있었습니다:

data class SingleItem(
    override val key: String,
    val value: String
) : JsonItem

이 SingleItem 클래스는 JSON 데이터를 String 값으로만 표현할 수 있어서, 다양한 JSON 데이터 타입을 처리하는 데 한계가 있었습니다. 실제 JSON 객체에서는 String 외에도 Int, Double, Boolean 등 다양한 데이터 타입이 존재할 수 있습니다.

이로 인해 SingleItem을 사용하여 UI에 JSON 데이터를 표시하고, Mocking 후 JSON 객체로 다시 변환하는 과정에서 여러 문제가 발생했습니다. 예를 들어, Int, Double, Boolean과 같은 기본형 타입이 String으로만 처리되다 보니, Mocking이 완료된 이후 JSON 객체로 변환할 때 문제가 발생했습니다.

이런 문제로 인해 Moshi나 Gson과 같은 JSON 변환 라이브러리에서 에러가 발생할 수 있었습니다.

SingleItem 클래스의 개선

문제를 해결하기 위해 SingleItem 클래스의 value 타입을 Any로 변경했습니다.

data class SingleItem(
    override val key: String,
    val value: Any
) : JsonItem

Any 타입으로 변경함으로써 String뿐만 아니라 Boolean, Int, Float, Double 등 다양한 JSON 데이터 타입을 지원할 수 있게 되었습니다.

이제 SingleItem은 JSON의 모든 기본형 타입을 처리할 수 있으며, Mocking 완료 후에도 JSON 객체를 정확하게 재생성할 수 있습니다.

UI에서 SingleItem의 value를 표시하는 방법

value의 타입이 Any가 되면서, UI를 그릴 때 value의 실제 타입에 따라 다른 방법으로 표시하도록 개선했습니다. 예를 들어, Boolean, Int, Float, Double 등의 타입에 따라 UI를 다르게 표현합니다.

is JsonItem.SingleItem -> {
            when (item.value) {
                is Boolean -> {
                    BooleanValue(
                        value = item.value,
                        onValueChange = { onValueChange(it) }
                    )
                }

                is Int, is Long, is Float, is Double -> {
                    NumberValue(
                        value = item.value,
                        onValueChange = { onValueChange(it) }
                    )
                }

                else -> {
                    TextValue(
                        value = item.value.toString(),
                        onValueChange = { onValueChange(it) }
                    )
                }
            }
        }

여기서 BooleanValue, NumberValue, TextValue는 각 타입에 맞는 UI 컴포넌트를 보여줍니다.

@NonNull public JSONObject put(@NonNull String name, @Nullable Object value) throws JSONException {
        if (value == null) {
            nameValuePairs.remove(name);
            return this;
        }
        if (value instanceof Number) {
            // deviate from the original by checking all Numbers, not just floats & doubles
            JSON.checkDouble(((Number) value).doubleValue());
        }
        nameValuePairs.put(checkName(name), value);
        return this;
    }

JSONObject의 put 함수는 Object 타입의 값을 허용하기 때문에, SingleItem 클래스의 value를 String에서 Any로 변경하면 JSON 변환 과정에서 발생할 수 있는 문제를 해결할 수 있었습니다.