오늘은 Manifest Android Interview를 읽어보며 Modifier에 대해 더 잘 알아보고자 한다. Modifier를 깊게 파보기보다는 Modifier를 넓게 살펴보는 글로 여러 메서드가 어떻게 동작하는지를 간단하게 살펴볼 것이다.

requiredSize()는 어떻게 제약 조건을 무시할까?

requiredSize()는 부모의 제약 조건에 관계없이 고정된 크기를 적용하는 메서드이다.

그렇다면 size(), height() 같은 다른 크기 관련 메서드와 달리 어떻게 requiredSize()는 고정된 크기를 적용하는 걸까?

size()와 requiredSize()의 내부 구조를 통해 알아보자.

@Stable
fun Modifier.size(size: Dp) =
    this.then(
        SizeElement(
            minWidth = size,
            maxWidth = size,
            minHeight = size,
            maxHeight = size,
            enforceIncoming = true,
            inspectorInfo =
                debugInspectorInfo {
                    name = "size"
                    value = size
                },
        )
    )

@Stable
fun Modifier.requiredSize(size: Dp) =
    this.then(
        SizeElement(
            minWidth = size,
            maxWidth = size,
            minHeight = size,
            maxHeight = size,
            enforceIncoming = false,
            inspectorInfo =
                debugInspectorInfo {
                    name = "requiredSize"
                    value = size
                },
        )
    )

두 메서드에서 주목할 유의미한 차이는 enforceIncoming다.

size()는 enforceIncoming가 true이고 requiredSize()는 false인데 이것이 두 메서드의 차이를 만든다.

private class SizeElement(
    private val minWidth: Dp = Dp.Unspecified,
    private val minHeight: Dp = Dp.Unspecified,
    private val maxWidth: Dp = Dp.Unspecified,
    private val maxHeight: Dp = Dp.Unspecified,
    private val enforceIncoming: Boolean,
    private val inspectorInfo: InspectorInfo.() -> Unit,
) : ModifierNodeElement<SizeNode>() {
    override fun create(): SizeNode =
        SizeNode(
            minWidth = minWidth,
            minHeight = minHeight,
            maxWidth = maxWidth,
            maxHeight = maxHeight,
            enforceIncoming = enforceIncoming,
        )
        ...

SizeElement는 위와 같다. 이는 SizeNode를 생성하는데 이 SizeNode에 enforceIncoming 값이 전달된다.

private class SizeNode(
    var minWidth: Dp = Dp.Unspecified,
    var minHeight: Dp = Dp.Unspecified,
    var maxWidth: Dp = Dp.Unspecified,
    var maxHeight: Dp = Dp.Unspecified,
    var enforceIncoming: Boolean,
) : LayoutModifierNode, Modifier.Node() {
    ...
    override fun MeasureScope.measure(
        measurable: Measurable,
        constraints: Constraints,
    ): MeasureResult {
        val wrappedConstraints =
            targetConstraints.let { targetConstraints ->
                if (enforceIncoming) {
                    constraints.constrain(targetConstraints)
                } else {
                    val resolvedMinWidth =
                        if (minWidth.isSpecified) {
                            targetConstraints.minWidth
                        } else {
                            constraints.minWidth.fastCoerceAtMost(targetConstraints.maxWidth)
                        }
                    val resolvedMaxWidth =
                        if (maxWidth.isSpecified) {
                            targetConstraints.maxWidth
                        } else {
                            constraints.maxWidth.fastCoerceAtLeast(targetConstraints.minWidth)
                        }
                    val resolvedMinHeight =
                        if (minHeight.isSpecified) {
                            targetConstraints.minHeight
                        } else {
                            constraints.minHeight.fastCoerceAtMost(targetConstraints.maxHeight)
                        }
                    val resolvedMaxHeight =
                        if (maxHeight.isSpecified) {
                            targetConstraints.maxHeight
                        } else {
                            constraints.maxHeight.fastCoerceAtLeast(targetConstraints.minHeight)
                        }
                    Constraints(
                        resolvedMinWidth,
                        resolvedMaxWidth,
                        resolvedMinHeight,
                        resolvedMaxHeight,
                    )
                }
            }
    ...

이 코드를 보면 enforceIncoming가 true면 제약 조건을 적용하고 false면 제약 조건을 적용하지 않고 자신의 크기를 적용한다.

onGloballyPositioned는 어떻게 컴포넌트의 절대 좌표를 가져올까?

먼저 onGloballyPositioned는 아래와 같이 OnGloballyPositionedNode를 생성한다.

@Stable
fun Modifier.onGloballyPositioned(onGloballyPositioned: (LayoutCoordinates) -> Unit) =
    this then OnGloballyPositionedElement(onGloballyPositioned)

private class OnGloballyPositionedElement(val onGloballyPositioned: (LayoutCoordinates) -> Unit) :
    ModifierNodeElement<OnGloballyPositionedNode>() {
    override fun create(): OnGloballyPositionedNode {
        return OnGloballyPositionedNode(onGloballyPositioned)
    }
    ...

OnGloballyPositionedNode는 다음과 같이 되어있다.

private class OnGloballyPositionedNode(var callback: (LayoutCoordinates) -> Unit) :
    Modifier.Node(), GlobalPositionAwareModifierNode {
    override fun onGloballyPositioned(coordinates: LayoutCoordinates) {
        callback(coordinates)
    }

저 onGloballyPositioned를 호출함으로서 coordinates 값을 람다에 전달하는데 이것은 LayoutNode.kt에서 호출하는 것을 확인할 수 있다.

internal class LayoutNode {
    ...    
    internal fun dispatchOnPositionedCallbacks() {
        if (layoutState != Idle || layoutPending || measurePending || isDeactivated) {
            return // it hasn't yet been properly positioned, so don't make a call
        }
        if (!isPlaced) {
            return // it hasn't been placed, so don't make a call
        }
        nodes.headToTail(Nodes.GlobalPositionAware) {
            it.onGloballyPositioned(it.requireCoordinator(Nodes.GlobalPositionAware))
        }
    }    
    ...
}

컴포지션 단계중 Layout단계는 Measure와 Layout 단계로 나뉘는데 그중 Layout 단계가 마무리 될때 최종적으로 dispatchOnPositionedCallbacks()가 호출된다.

즉 최종 배치 마무리 단계에서 해당 컴포넌트의 좌표값을 호이스팅하게 되는 구조이다.

그럼 좌표값을 호이스팅하는 것을 알아봤으니 좌표값을 구하는 방법을 알아보자.

internal abstract class NodeCoordinator(override val layoutNode: LayoutNode) :
    LookaheadCapablePlaceable(), Measurable, LayoutCoordinates, OwnerScope {
    ...
    @OptIn(ExperimentalComposeUiApi::class)
    override fun localToRoot(relativeToLocal: Offset): Offset {
        checkPrecondition(isAttached) { ExpectAttachedLayoutCoordinates }
        onCoordinatesUsed()
        var coordinator: NodeCoordinator? = this
        var position = relativeToLocal
        while (coordinator != null) {
            if (ComposeUiFlags.isRectManagerOffsetUsageFromLayoutCoordinatesEnabled) {
                val layoutNode = coordinator.layoutNode
                if (
                    coordinator === layoutNode.outerCoordinator &&
                        !layoutNode.hasPositionalLayerTransformationsInOffsetFromRoot
                ) {
                    val offsetFromRectList =
                        layoutNode.requireOwner().rectManager.getOffsetFromRectListFor(layoutNode)
                    if (offsetFromRectList != IntOffset.Max) {
                        return position + offsetFromRectList
                    }
                }
            }
            position = coordinator.toParentPosition(position)
            coordinator = coordinator.wrappedBy
        }
        return position
    }
    ...
    open fun toParentPosition(
        position: Offset,
        includeMotionFrameOfReference: Boolean = true,
    ): Offset {
        val layer = layer
        val targetPosition = layer?.mapOffset(position, inverse = false) ?: position
        return if (!includeMotionFrameOfReference && isPlacedUnderMotionFrameOfReference) {
            targetPosition
        } else {
            targetPosition + this.position
        }
    }
    ...
}

이 부분이 NodeCoordinator가 좌표를 구하는 방법이다.

localToRoot 메서드가 position 값을 반환하는데 이 position은 coordinator = coordinator.wrappedBy로 coordinator를 null이 될 때까지 계속 벗기면서 coordinator.toParentPosition(position)로 현재 position값과 부모 내의 상대적 위치값을 더해나가며 구한다.

즉,

1. 부모 내의 상대 위치 구하기
2. 래퍼 벗기기
3. 루트에 도달할 때 까지 반복

이다.

dispatchOnPositionedCallbacks()가 Layout 단계가 마무리 될 때 최종적으로 호출되기에 좌표를 첫 Layout 이후에 알게 된다. 그렇기에 이를 이용해 툴팁을 그리거나 할 경우 recomposition이 일어나게 된다.

Box나 Column 등에서 align이나 weight로 어떻게 부모 레이아웃에 자식의 데이터를 전달할까?

이것도 NodeCoordinator에서 확인할 수 있다. 이어서 마저 확인해보자.

NodeCoordinator는 parentData라는 부모에게 전달하는 데이터를 가지고 있다.

internal abstract class NodeCoordinator(override val layoutNode: LayoutNode) :
    LookaheadCapablePlaceable(), Measurable, LayoutCoordinates, OwnerScope {
    ...
    override val parentData: Any?
        get() {
            // NOTE: If you make changes to this getter, please check the generated bytecode to
            // ensure no extra allocation is made. See the note below.
            if (layoutNode.nodes.has(Nodes.ParentData)) {
                val thisNode = tail
                // NOTE: Keep this mutable variable scoped inside the if statement. When moved
                // to the outer scope of get(), this causes the compiler to generate a
                // Ref$ObjectRef instance on every call of this getter.
                var data: Any? = null
                layoutNode.nodes.tailToHead { node ->
                    if (node.isKind(Nodes.ParentData)) {
                        node.dispatchForKind(Nodes.ParentData) {
                            data = with(it) { layoutNode.density.modifyParentData(data) }
                        }
                    }
                    if (node === thisNode) return@tailToHead
                }
                return data
            }
            return null
        }
    ...
}

tailToHead는 코드상 가장 마지막에 쓴 Modifier부터 부모 방향으로 거슬러 올라가는 메서드로 트리의 tail에서 해당 coordinator가 담당하는 부분의 tail까지 올라오면서 data가 null부터 시작해서 정보를 계속 누적한다.

이것이 부모의 레이아웃에 닿으면 이 값을 통해 자식 레이아웃을 배치한다. Column 코드를 예시로 살펴보면

internal data class ColumnMeasurePolicy(
    private val verticalArrangement: Arrangement.Vertical,
    private val horizontalAlignment: Alignment.Horizontal,
) : MeasurePolicy, RowColumnMeasurePolicy {
    ...
    private fun getCrossAxisPosition(
        placeable: Placeable,
        parentData: RowColumnParentData?,
        crossAxisLayoutSize: Int,
        beforeCrossAxisAlignmentLine: Int,
        layoutDirection: LayoutDirection,
    ): Int {
        val childCrossAlignment = parentData?.crossAxisAlignment
        return childCrossAlignment?.align(
            size = crossAxisLayoutSize,
            layoutDirection = layoutDirection,
            placeable = placeable,
            beforeCrossAxisAlignmentLine = beforeCrossAxisAlignmentLine,
        ) ?: horizontalAlignment.align(placeable.width, crossAxisLayoutSize, layoutDirection)
    }
    ...
}

자신의 measurePolicy에서 해당 데이터가 자신이 사용하는 align인지를 확인하며 사용하게 된다.

마무리

Modifier의 이것저것을 알아보았다. Compose로 개발하다보면 Modifier를 정말 많이 사용한다. 이걸로 조금은 친근해진 것 같긴한데 늘 어렵다.

아직 이전 글들도 마무리하지 못하고 벌써 3번째 글이 나오고 있다... 이번주 내로 무조건 마무리해야겠다..

이번에 알아볼 것은 remember이다. remember는 Jetpack Compose에서 상태를 기억하기 위해 사용되는 API로 Recomposition에서 상태값을 기억하지만 configure Change에서는 값을 유지하지 못한다.

그렇다면 어째서 remember는 recomposition에서 값을 유지하고 configure change에서는 기억하지 못하는 걸까? 내부 코드를 분석해보자.

remember

remember의 내부는 다음과 같다.

@Composable
public inline fun <T> remember(crossinline calculation: @DisallowComposableCalls () -> T): T =
    currentComposer.cache(false, calculation)

@Composable
public inline fun <T> remember(
    key1: Any?,
    crossinline calculation: @DisallowComposableCalls () -> T,
): T {
    return currentComposer.cache(currentComposer.changed(key1), calculation)
}

key가 여러 개인 remember의 경우 key 파라미터만 추가되는 구조고 각 key마다 currentComposer.changed(key) 연산을 해준다.

이 함수에 대해 주석은 다음과 같이 작성되어 있다.

Remember the value returned by calculation if key1 compares equal (==) to the value it had in the previous composition, otherwise produce and remember a new value by calling calculation

만약 key 값이 이전과 동일하다면 이전 값을 기억하고 그렇지 않다면 calculation을 수행하여 새로운 값을 생성하고 기억한다.

key 값이 없다면 재연산을 안한다.

그렇다면 일단 값의 변경 여부를 판별하는 currentComposer.changed()를 확인해보자.

currentComposer.changed()

    @ComposeCompilerApi
    override fun changed(value: Any?): Boolean {
        return if (nextSlot() != value) {
            updateValue(value)
            true
        } else {
            false
        }
    }

changed의 내부는 위와 같다.

nextSlot()

여기서 nextSlot()이라는 함수를 key 값과 비교하는데 이 nextSlot()은 다음과 같다.

internal fun nextSlot(): Any? =
    if (inserting) {
        validateNodeNotExpected()
        Composer.Empty
    } else
        reader.next().let {
            if (reusing && it !is ReusableRememberObserverHolder) Composer.Empty else it
        }

한 줄씩 설명하면

• inserting : 현재 트리에 노드를 삽입하는 작업을 예약 중인 경우, 첫 트리 구성에서는 항상 참이다.
• Composer.Empty : 비교 대상이 없다는 의미로 Empty 반환
• reader.next() : 슬롯 테이블의 reader를 사용해 슬롯 테이블의 현재 값을 가져오고 reader의 인덱스를 +1, 그룹의 끝이면 Empty 반환
• if (reusing && it !is ReusableRememberObserverHolder) : 노드가 재사용중이라면 Empty 그렇지 않다면 원래 값 반환

노드 재사용이란?

Compose는 UI를 그릴 때 Slot Table에 UI 구조를 저장한다.

reusing == true라는 것은 "UI의 껍데기(Node)는 그대로 두고, 그 안에 들어가는 데이터(State)만 싹 갈아 끼우겠다"는 의미

보통 다음과 같은 상황에서 발생:

• Lazy Layout (리스트): 스크롤 시 화면에서 사라진 리스트 아이템 노드를 새로 나타나는 아이템을 위해 재사용할 때
• MovableContent: UI 요소가 트리 상의 한 위치에서 다른 위치로 이동할 때 (예: 화면 가로/세로 전환 시 공유 요소 이동)

이렇게 슬롯 테이블에서 저장된 값을 가져오고 changed()에서 if (nextSlot() != value)로 key 값과 비교한다.

만약 같다면 false를 그렇지 않고 다르다면 updateValue()로 값을 갱신후 true를 반환한다.

그럼 updateValue()를 살펴보자

updateValue()

internal fun updateValue(value: Any?) {
    if (inserting) {
        writer.update(value)
    } else {
        if (reader.hadNext) {
            val groupSlotIndex = reader.groupSlotIndex - 1

            if (changeListWriter.pastParent) { 
                changeListWriter.updateAnchoredValue(value, reader.anchor(reader.parent), groupSlotIndex)
            } else {
                changeListWriter.updateValue(value, groupSlotIndex)
            }
        } else {
            changeListWriter.appendValue(reader.anchor(reader.parent), value)
        }
    }
}

이것도 하나씩 설명하자면

1. inserting으로 처음 그리는 중인지 확인 후 값 갱신
2. 그렇지 않다면 reader.hadNext로 이미 값이 있는 상태에서 수정하는지 확인(hadNext는 이전 next()의 결과 Boolean을 저장하는 값)
3. val groupSlotIndex = reader.groupSlotIndex - 1, -1을 하는 이유는 nextSlot()시 인덱스가 +1 되었기에 방금 읽었던 자리를 수정하기 위함
4. if (changeListWriter.pastParent)로 이미 부모 그룹을 지나쳐버렸다면 앵커를 사용하여 수정, 그렇지 않다면 방금 위치로 수정
5. hadNext에서 false 즉 읽을 것이 없었다면 append

이렇게 값을 가져오고 갱신하는 것까지 완료했다. 그렇다면 이제 다시 remember로 돌아가 currentComposer.cache() 연산을 수행해줄 차례이다.

currentComposer.cache

@ComposeCompilerApi
public inline fun <T> Composer.cache(invalid: Boolean, block: @DisallowComposableCalls () -> T): T {
    @Suppress("UNCHECKED_CAST")
    return rememberedValue().let {
        if (invalid || it === Composer.Empty) {
            val value = block()
            updateRememberedValue(value)
            value
        } else it
    } as T
}

위와 같이 되어있고 rememberValue()라는 함수로 값을 가져온다. 이 함수는 이름 그대로 기억하고 있는 값을 가져오는 것이다.

구현은 다음과 같이 되어있다.

override fun rememberedValue(): Any? = nextSlotForCache()

@PublishedApi
@OptIn(InternalComposeApi::class)
internal fun nextSlotForCache(): Any? {
    return if (inserting) {
        validateNodeNotExpected()
        Composer.Empty
    } else
        reader.next().let {
            if (reusing && it !is ReusableRememberObserverHolder) Composer.Empty
            else if (it is RememberObserverHolder) it.wrapped else it
        }
}

위에서 본 nextSlot()과 거의 유사하다. if(it is RememberObserverHolder)로 해당 값이 RememberObserver 인터페이스를 구현한 객체(예: DisposableEffect, LaunchedEffect 등)를 감싸고 있는 래퍼(Wrapper)인지 확인한다.

이렇게 기억하고 있는 값을 가져온 후 이전에 검사한 invalid와 해당 값이 Empty인지를 확인하고 해당 값을 block으로 계산한 값을 updateRememberedValue()로 갱신 후 반환한다.

마무리

즉, 모든 기억과 갱신은 Composer와 내부의 슬롯 테이블에 의존하고 있는 것을 확인할 수 있다.

그렇기 때문에 Configure Change시 해당 Activity와 연결된 Composition, 슬롯 테이블이 모두 날라가기 때문에 값을 기억하지 못한다.

다음에는 rememberSaveable을 분석해볼 예정이다.

그중 개인적으로 많이 사용하는 Coil을 까볼 것이다.

Coil의 AsyncImage

Coil에서도 가장 기본적인 AsyncImage를 분석해보려 한다. AsyncImage는 다음과 같이 작성되어 있다.

@Composable
@NonRestartableComposable
fun AsyncImage(
    model: Any?,
    contentDescription: String?,
    imageLoader: ImageLoader,
    modifier: Modifier = Modifier,
    placeholder: Painter? = null,
    error: Painter? = null,
    fallback: Painter? = error,
    onLoading: ((State.Loading) -> Unit)? = null,
    onSuccess: ((State.Success) -> Unit)? = null,
    onError: ((State.Error) -> Unit)? = null,
    alignment: Alignment = Alignment.Center,
    contentScale: ContentScale = ContentScale.Fit,
    alpha: Float = DefaultAlpha,
    colorFilter: ColorFilter? = null,
    filterQuality: FilterQuality = DefaultFilterQuality,
    clipToBounds: Boolean = true,
) = AsyncImage(
    state = AsyncImageState(model, imageLoader),
    contentDescription = contentDescription,
    modifier = modifier,
    transform = transformOf(placeholder, error, fallback),
    onState = onStateOf(onLoading, onSuccess, onError),
    alignment = alignment,
    contentScale = contentScale,
    alpha = alpha,
    colorFilter = colorFilter,
    filterQuality = filterQuality,
    clipToBounds = clipToBounds,
)

으로 되어있고 이걸 한번 더 들어가면

@Composable
private fun AsyncImage(
    state: AsyncImageState,
    contentDescription: String?,
    modifier: Modifier,
    transform: (State) -> State,
    onState: ((State) -> Unit)?,
    alignment: Alignment,
    contentScale: ContentScale,
    alpha: Float,
    colorFilter: ColorFilter?,
    filterQuality: FilterQuality,
    clipToBounds: Boolean,
) {
    val request = requestOfWithSizeResolver(
        model = state.model,
        contentScale = contentScale,
    )
    validateRequest(request)

    Layout(
        modifier = modifier.then(
            ContentPainterElement(
                request = request,
                imageLoader = state.imageLoader,
                modelEqualityDelegate = state.modelEqualityDelegate,
                transform = transform,
                onState = onState,
                contentScale = contentScale,
                filterQuality = filterQuality,
                alignment = alignment,
                alpha = alpha,
                colorFilter = colorFilter,
                clipToBounds = clipToBounds,
                previewHandler = previewHandler(),
                contentDescription = contentDescription,
            ),
        ),
        measurePolicy = UseMinConstraintsMeasurePolicy,
    )
}

위와 같이 되어있다. 그중 url주소를 넣는 model은 requestOfWithSizeResolver의 파라미터로 사용된다. 그럼 이 requestOfWithSizeResolver를 살펴보자

requestOfWithSizeResolver

/** Create an [ImageRequest] with a not-null [SizeResolver] from the [model]. */
@Composable
@NonRestartableComposable
internal fun requestOfWithSizeResolver(
    model: Any?,
    contentScale: ContentScale,
): ImageRequest {
    if (model is ImageRequest) {
        if (model.defined.sizeResolver != null) {
            return model
        } else {
            val sizeResolver = rememberSizeResolver(contentScale)
            return remember(model, sizeResolver) {
                model.newBuilder()
                    .size(sizeResolver)
                    .build()
            }
        }
    } else {
        val context = LocalPlatformContext.current
        val sizeResolver = rememberSizeResolver(contentScale)
        return remember(context, model, sizeResolver) {
            ImageRequest.Builder(context)
                .data(model)
                .size(sizeResolver)
                .build()
        }
    }
}

주석은 이 함수를 다음과 같이 설명한다.

Create an ImageRequest with a not-null SizeResolver from the model. -> model에서 null이 아닌 SizeResolver를 사용하여 ImageRequest를 생성한다.

코드를 살펴보면

1. model의 타입이 ImageRequest일때 sizeResolver가 null이 아니면 바로 model을 null이면 contentScale을 파라미터로 받는 sizeResolver를 만들어 다시 ImageRequest를 빌드한다.

2. model의 타입이 ImageRequest이 아니라면 data를 model로 갖는 새로운 ImageRequest를 생성한다.

rememberSizeResolver는 내부적으로 아래와 같이 생겼는데 contentScale이 None인지 아닌지 여부를 판별하여 SizeResolver를 생성하는 함수이다.

@Composable
private fun rememberSizeResolver(contentScale: ContentScale): SizeResolver {
    val isNone = contentScale == ContentScale.None
    return remember(isNone) {
        if (isNone) {
            SizeResolver.ORIGINAL
        } else {
            ConstraintsSizeResolver()
        }
    }
}

이렇게 생성된 ImgaeRequest를 validateRequest(request)로 유효성 검사를 해준다.

internal fun validateRequest(request: ImageRequest) {
    when (request.data) {
        is ImageRequest.Builder -> unsupportedData(
            name = "ImageRequest.Builder",
            description = "Did you forget to call ImageRequest.Builder.build()?",
        )
        is ImageBitmap -> unsupportedData("ImageBitmap")
        is ImageVector -> unsupportedData("ImageVector")
        is Painter -> unsupportedData("Painter")
    }
    validateRequestProperties(request)
}

private fun unsupportedData(
    name: String,
    description: String = "If you wish to display this $name, use androidx.compose.foundation.Image.",
): Nothing = throw IllegalArgumentException("Unsupported type: $name. $description")

/** Validate platform-specific properties of an [ImageRequest]. */
internal expect fun validateRequestProperties(request: ImageRequest)

validateRequestProperties는 android기준 다음과 같이 구현되어 있다.

internal actual fun validateRequestProperties(request: ImageRequest) {
    require(request.target == null) { "request.target must be null." }
    require(request.lifecycle == null) { "request.lifecycle must be null." }
}

이렇게 유효성 검증까지 끝난 ImageRequest를 사용해서 ContentPainterElement라는 Coil의 커스텀 Modifier로 이미지를 그리게 된다.

ContentPainterElement

/**
 * A custom [paint] modifier used by [AsyncImage].
 */
internal data class ContentPainterElement(
    private val request: ImageRequest,
    private val imageLoader: ImageLoader,
    private val modelEqualityDelegate: AsyncImageModelEqualityDelegate,
    private val transform: (State) -> State,
    private val onState: ((State) -> Unit)?,
    private val filterQuality: FilterQuality,
    private val alignment: Alignment,
    private val contentScale: ContentScale,
    private val alpha: Float,
    private val colorFilter: ColorFilter?,
    private val clipToBounds: Boolean,
    private val previewHandler: AsyncImagePreviewHandler?,
    private val contentDescription: String?,
) : ModifierNodeElement<ContentPainterNode>() {

    override fun create(): ContentPainterNode {
        val input = Input(imageLoader, request, modelEqualityDelegate)

        // Create the painter during modifier creation so we reuse the same painter object when the
        // modifier is being reused as part of the lazy layouts reuse flow.
        val painter = AsyncImagePainter(input)
        painter.transform = transform
        painter.onState = onState
        painter.contentScale = contentScale
        painter.filterQuality = filterQuality
        painter.previewHandler = previewHandler
        painter._input = input

        return ContentPainterNode(
            painter = painter,
            constraintSizeResolver = request.sizeResolver as? ConstraintsSizeResolver,
            alignment = alignment,
            contentScale = contentScale,
            alpha = alpha,
            colorFilter = colorFilter,
            clipToBounds = clipToBounds,
            contentDescription = contentDescription,
        )
    }

    override fun update(node: ContentPainterNode) {
        val previousIntrinsics = node.painter.intrinsicSize
        val previousConstraintSizeResolver = node.constraintSizeResolver
        val input = Input(imageLoader, request, modelEqualityDelegate)
        val painter = node.painter
        painter.transform = transform
        painter.onState = onState
        painter.contentScale = contentScale
        painter.filterQuality = filterQuality
        painter.previewHandler = previewHandler
        painter._input = input

        val intrinsicsChanged = previousIntrinsics != painter.intrinsicSize

        node.alignment = alignment
        node.constraintSizeResolver = request.sizeResolver as? ConstraintsSizeResolver
        node.contentScale = contentScale
        node.alpha = alpha
        node.colorFilter = colorFilter
        node.clipToBounds = clipToBounds

        if (node.contentDescription != contentDescription) {
            node.contentDescription = contentDescription
            node.invalidateSemantics()
        }

        val constraintSizeResolverChanged =
            previousConstraintSizeResolver != node.constraintSizeResolver

        // Only remeasure if intrinsics have changed.
        if (intrinsicsChanged || constraintSizeResolverChanged) {
            node.invalidateMeasurement()
        }

        // Redraw because one of the node properties has changed.
        node.invalidateDraw()
    }

    override fun InspectorInfo.inspectableProperties() {
        name = "content"
        properties["request"] = request
        properties["imageLoader"] = imageLoader
        properties["modelEqualityDelegate"] = modelEqualityDelegate
        properties["transform"] = transform
        properties["onState"] = onState
        properties["filterQuality"] = filterQuality
        properties["alignment"] = alignment
        properties["contentScale"] = contentScale
        properties["alpha"] = alpha
        properties["colorFilter"] = colorFilter
        properties["clipToBounds"] = clipToBounds
        properties["previewHandler"] = previewHandler
        properties["contentDescription"] = contentDescription
    }
}

여기서 Compose의 UI 트리를 조금 알아보자 Compose는 다음과 같은 단계로 UI를 그린다.

Composition 단계에서 Compose 런타임은 컴포저블 함수를 실행하고 UI를 나타내는 트리 구조를 구성하는데 이때의 노드가 Layout 단계에서 사용되는 정보를 담고 있는 Layout 노드이다.

androidx.compose.ui.node.NodeChain.kt 를 살펴보면 아래와 같은 코드가 있다.

...
else if (layoutNode.applyingModifierOnAttach && beforeSize == 0) {
            // common case where we are initializing the chain and the previous size is zero. In
            // this case we just do all inserts. Since this is so common, we add a fast path here
            // for this condition. Since the layout node is currently attaching, the inserted nodes
            // will not get eagerly attached, which means we can avoid dealing with the coordinator
            // sync until the end, which keeps this code path much simpler.
            coordinatorSyncNeeded = true
            var node = paddedHead
            while (i < after.size) {
                val next = after[i]
                val parent = node
                node = createAndInsertNodeAsChild(next, parent)
                logger?.nodeInserted(0, i, next, parent, node)
                i++
            }
            syncAggregateChildKindSet()
            ...

모든 Modifier는 이 NodeChain에 등록되는데 이 과정에서 Layout 노드가 처음 트리에 attach 될때 createAndInsertNodeAsChild() 라는 함수를 호출한다.

이 함수는 다음과 같다.

private fun createAndInsertNodeAsChild(
    element: Modifier.Element,
    parent: Modifier.Node,
): Modifier.Node {
    val node =
        when (element) {
            is ModifierNodeElement<*> ->
                element.create().also {
                    it.kindSet = calculateNodeKindSetFromIncludingDelegates(it)
                }
            else -> BackwardsCompatNode(element)
        }
    checkPrecondition(!node.isAttached) {
        "A ModifierNodeElement cannot return an already attached node from create() "
    }
    node.insertedNodeAwaitingAttachForInvalidation = true
    return insertChild(node, parent)
}

여기서 바로 ModifierNodeElement의 create()함수를 호출한다.

이제 다시 ContentPainterElement로 돌아오면 create 함수가 다음과 같이 되어있고 여기서 painter가 실제 이미지를 그리는 객체이다.

override fun create(): ContentPainterNode {
    val input = Input(imageLoader, request, modelEqualityDelegate)

    // Create the painter during modifier creation so we reuse the same painter object when the
    // modifier is being reused as part of the lazy layouts reuse flow.
    val painter = AsyncImagePainter(input)
    painter.transform = transform
    painter.onState = onState
    painter.contentScale = contentScale
    painter.filterQuality = filterQuality
    painter.previewHandler = previewHandler
    painter._input = input

    return ContentPainterNode(
        painter = painter,
        constraintSizeResolver = request.sizeResolver as? ConstraintsSizeResolver,
        alignment = alignment,
        contentScale = contentScale,
        alpha = alpha,
        colorFilter = colorFilter,
        clipToBounds = clipToBounds,
        contentDescription = contentDescription,
    )
}

그럼 이 AsyncImagePainter가 이미지를 어떻게 그리는지 살펴보자

/**
 * A [Painter] that that executes an [ImageRequest] asynchronously and renders the [ImageResult].
 */
@Stable
class AsyncImagePainter internal constructor(
    input: Input,
) : Painter(), RememberObserver {
    private var painter: Painter? by mutableStateOf(null)
    private var alpha: Float = DefaultAlpha
    private var colorFilter: ColorFilter? = null

    private var isRemembered = false
    private var rememberJob: Job? = null
        set(value) {
            field?.cancel()
            field = value
        }

    private var drawSizeFlow: MutableSharedFlow<Size>? = null
    private var drawSize = Size.Unspecified
        set(value) {
            if (field != value) {
                field = value
                drawSizeFlow?.tryEmit(value)
            }
        }

    internal lateinit var scope: CoroutineScope
    internal var transform = DefaultTransform
    internal var onState: ((State) -> Unit)? = null
    internal var contentScale = ContentScale.Fit
    internal var filterQuality = DefaultFilterQuality
    internal var previewHandler: AsyncImagePreviewHandler? = null

    internal var _input: Input? = input
        set(value) {
            if (field != value) {
                field = value
                restart()
                if (value != null) {
                    inputFlow.value = value
                }
            }
        }

    private val inputFlow: MutableStateFlow<Input> = MutableStateFlow(input)
    val input: StateFlow<Input> = inputFlow.asStateFlow()

    private val stateFlow: MutableStateFlow<State> = MutableStateFlow(State.Empty)
    val state: StateFlow<State> = stateFlow.asStateFlow()

    override val intrinsicSize: Size
        get() = painter?.intrinsicSize ?: Size.Unspecified

    override fun DrawScope.onDraw() {
        drawSize = size
        painter?.apply { draw(size, alpha, colorFilter) }
    }

    override fun applyAlpha(alpha: Float): Boolean {
        this.alpha = alpha
        return true
    }

    override fun applyColorFilter(colorFilter: ColorFilter?): Boolean {
        this.colorFilter = colorFilter
        return true
    }

    override fun onRemembered() = trace("AsyncImagePainter.onRemembered") {
        (painter as? RememberObserver)?.onRemembered()
        launchJob()
        isRemembered = true
    }

    private fun launchJob() {
        val input = _input ?: return

        rememberJob = scope.launchWithDeferredDispatch {
            val previewHandler = previewHandler
            val state = if (previewHandler != null) {
                // If we're in inspection mode use the preview renderer.
                val request = updateRequest(input.request, isPreview = true)
                previewHandler.handle(input.imageLoader, request)
            } else {
                // Else, execute the request as normal.
                val request = updateRequest(input.request, isPreview = false)
                input.imageLoader.execute(request).toState()
            }
            updateState(state)
        }
    }

    override fun onForgotten() {
        rememberJob = null
        (painter as? RememberObserver)?.onForgotten()
        isRemembered = false
    }

    override fun onAbandoned() {
        rememberJob = null
        (painter as? RememberObserver)?.onAbandoned()
        isRemembered = false
    }

    /**
     * Launch a new image request with the current [Input]s.
     */
    fun restart() {
        if (_input == null) {
            rememberJob = null
        } else if (isRemembered) {
            launchJob()
        }
    }

    /**
     * Update the [request] to work with [AsyncImagePainter].
     */
    private fun updateRequest(request: ImageRequest, isPreview: Boolean): ImageRequest {
        // Connect the size resolver to the draw scope if necessary.
        val sizeResolver = request.sizeResolver
        if (sizeResolver is DrawScopeSizeResolver) {
            sizeResolver.connect(lazyDrawSizeFlow())
        }

        return request.newBuilder()
            .target(
                onStart = { placeholder ->
                    val painter = placeholder?.asPainter(request.context, filterQuality)
                    updateState(State.Loading(painter))
                },
            )
            .apply {
                if (request.defined.sizeResolver == null) {
                    // If the size resolver isn't set, use the original size.
                    size(SizeResolver.ORIGINAL)
                }
                if (request.defined.scale == null) {
                    // If the scale isn't set, use the content scale.
                    scale(contentScale.toScale())
                }
                if (request.defined.precision == null) {
                    // AsyncImagePainter scales the image to fit the canvas size at draw time.
                    precision(Precision.INEXACT)
                }
                if (isPreview) {
                    // The request must be executed synchronously in the preview environment.
                    coroutineContext(EmptyCoroutineContext)
                }
            }
            .build()
    }

    private fun updateState(state: State) {
        val previous = stateFlow.value
        val current = transform(state)
        stateFlow.value = current
        painter = maybeNewCrossfadePainter(previous, current, contentScale) ?: current.painter

        // Manually forget and remember the old/new painters.
        if (previous.painter !== current.painter) {
            (previous.painter as? RememberObserver)?.onForgotten()
            (current.painter as? RememberObserver)?.onRemembered()
        }

        // Notify the state listener.
        onState?.invoke(current)
    }

    private fun ImageResult.toState() = when (this) {
        is SuccessResult -> State.Success(
            painter = image.asPainter(request.context, filterQuality),
            result = this,
        )
        is ErrorResult -> State.Error(
            painter = image?.asPainter(request.context, filterQuality),
            result = this,
        )
    }

    private fun lazyDrawSizeFlow(): Flow<Size> {
        var drawSizeFlow = drawSizeFlow
        if (drawSizeFlow == null) {
            drawSizeFlow = MutableSharedFlow(
                replay = 1,
                onBufferOverflow = DROP_OLDEST,
            )
            val drawSize = drawSize
            if (drawSize.isSpecified) {
                drawSizeFlow.tryEmit(drawSize)
            }
            this.drawSizeFlow = drawSizeFlow
        }
        return drawSizeFlow
    }

    /**
     * The latest arguments passed to [AsyncImagePainter].
     */
    @Poko
    class Input(
        val imageLoader: ImageLoader,
        val request: ImageRequest,
        val modelEqualityDelegate: AsyncImageModelEqualityDelegate,
    ) {

        override fun equals(other: Any?): Boolean {
            if (this === other) return true
            return other is Input &&
                imageLoader == other.imageLoader &&
                modelEqualityDelegate == other.modelEqualityDelegate &&
                modelEqualityDelegate.equals(request, other.request)
        }

        override fun hashCode(): Int {
            var result = imageLoader.hashCode()
            result = 31 * result + modelEqualityDelegate.hashCode()
            result = 31 * result + modelEqualityDelegate.hashCode(request)
            return result
        }
    }

    /**
     * The current state of the [AsyncImagePainter].
     */
    sealed interface State {

        /** The current painter being drawn by [AsyncImagePainter]. */
        val painter: Painter?

        /** The request has not been started. */
        data object Empty : State {
            override val painter: Painter? get() = null
        }

        /** The request is in-progress. */
        data class Loading(
            override val painter: Painter?,
        ) : State

        /** The request was successful. */
        data class Success(
            override val painter: Painter,
            val result: SuccessResult,
        ) : State

        /** The request failed due to [ErrorResult.throwable]. */
        data class Error(
            override val painter: Painter?,
            val result: ErrorResult,
        ) : State
    }

    companion object {
        /**
         * A state transform that does not modify the state.
         */
        val DefaultTransform: (State) -> State = { it }
    }
}

이 글에서 알아볼 것은 어떻게 네트워크에서 가져오고 그리는가이다.

다른 부분은 배제하고 launchedJob() 함수를 살펴보자

private fun launchJob() {
    val input = _input ?: return

    rememberJob = scope.launchWithDeferredDispatch {
        val previewHandler = previewHandler
        val state = if (previewHandler != null) {
            // If we're in inspection mode use the preview renderer.
            val request = updateRequest(input.request, isPreview = true)
            previewHandler.handle(input.imageLoader, request)
        } else {
            // Else, execute the request as normal.
            val request = updateRequest(input.request, isPreview = false)
            input.imageLoader.execute(request).toState()
        }
        updateState(state)
    }

또한 preview가 아닌 실제에서 어떻게 가져오는가가 목적이기에 바로 imageLoader의 excute 함수를 확인하자.

ImageLoader

ImageLoader의 실제 구현체는 RealIamgeLoader이다. RealImageLoader의 코드는 다음과 같은데 전체 코드중 살펴볼 코드만 일부 작성한 것이다.

internal class RealImageLoader(
    val options: Options,
) : ImageLoader {
    ...
    override val components = options.componentRegistry.newBuilder()
        .addServiceLoaderComponents(options)
        .addAndroidComponents(options)
        .addJvmComponents(options)
        .addAppleComponents(options)
        .addCommonComponents()
        .add(EngineInterceptor(this, systemCallbacks, requestService, options.logger))
        .build()
    ...
    override suspend fun execute(request: ImageRequest): ImageResult {
        if (!needsExecuteOnMainDispatcher(request)) {
            // Fast path: skip dispatching.
            return execute(request, REQUEST_TYPE_EXECUTE)
        } else {
            // Slow path: dispatch to the main thread.
            return coroutineScope {
                // Start executing the request on the main thread.
                val job = async(options.mainCoroutineContextLazy.value) {
                    execute(request, REQUEST_TYPE_EXECUTE)
                }

                // Update the current request attached to the view and await the result.
                getDisposable(request, job).job.await()
            }
        }
    }

    private suspend fun execute(initialRequest: ImageRequest, type: Int): ImageResult {
        // Wrap the request to manage its lifecycle.
        val requestDelegate = requestService.requestDelegate(
            request = initialRequest,
            job = coroutineContext.job,
            findLifecycle = type == REQUEST_TYPE_ENQUEUE,
        ).apply { assertActive() }

        // Apply this image loader's defaults and other configuration to this request.
        val request = requestService.updateRequest(initialRequest)

        // Create a new event listener.
        val eventListener = options.eventListenerFactory.create(request)

        try {
            // Fail before starting if data is null.
            if (request.data == NullRequestData) {
                throw NullRequestDataException()
            }

            // Set up the request's lifecycle observers.
            requestDelegate.start()

            // Enqueued requests suspend until the lifecycle is started.
            if (type == REQUEST_TYPE_ENQUEUE) {
                requestDelegate.awaitStarted()
            }

            // Set the placeholder on the target.
            val cachedPlaceholder = request.placeholderMemoryCacheKey?.let { memoryCache?.get(it)?.image }
            request.target?.onStart(placeholder = cachedPlaceholder ?: request.placeholder())
            eventListener.onStart(request)
            request.listener?.onStart(request)

            // Resolve the size.
            val sizeResolver = request.sizeResolver
            eventListener.resolveSizeStart(request, sizeResolver)
            val size = sizeResolver.size()
            eventListener.resolveSizeEnd(request, size)

            // Execute the interceptor chain.
            val result = withContext(request.interceptorCoroutineContext) {
                RealInterceptorChain(
                    initialRequest = request,
                    interceptors = components.interceptors,
                    index = 0,
                    request = request,
                    size = size,
                    eventListener = eventListener,
                    isPlaceholderCached = cachedPlaceholder != null,
                ).proceed()
            }

            // Set the result on the target.
            when (result) {
                is SuccessResult -> onSuccess(result, request.target, eventListener)
                is ErrorResult -> onError(result, request.target, eventListener)
            }
            return result
        } catch (throwable: Throwable) {
            if (throwable is CancellationException) {
                onCancel(request, eventListener)
                throw throwable
            } else {
                // Create the default error result if there's an uncaught exception.
                val result = ErrorResult(request, throwable)
                onError(result, request.target, eventListener)
                return result
            }
        } finally {
            requestDelegate.complete()
        }
    }
...

여기에 excute함수가 다음과 같이 구현되어 있다.

override suspend fun execute(request: ImageRequest): ImageResult {
    if (!needsExecuteOnMainDispatcher(request)) {
        // Fast path: skip dispatching.
        return execute(request, REQUEST_TYPE_EXECUTE)
    } else {
        // Slow path: dispatch to the main thread.
        return coroutineScope {
            // Start executing the request on the main thread.
            val job = async(options.mainCoroutineContextLazy.value) {
                execute(request, REQUEST_TYPE_EXECUTE)
            }

            // Update the current request attached to the view and await the result.
            getDisposable(request, job).job.await()
        }
    }
}

저 excute 함수 중 살펴볼 부분은 아래와 같다.

private suspend fun execute(initialRequest: ImageRequest, type: Int): ImageResult {
    ...

====================================================
        // Execute the interceptor chain.
        val result = withContext(request.interceptorCoroutineContext) {
            RealInterceptorChain(
                initialRequest = request,
                interceptors = components.interceptors,
                index = 0,
                request = request,
                size = size,
                eventListener = eventListener,
                isPlaceholderCached = cachedPlaceholder != null,
            ).proceed()
        }
====================================================
  ...
}

이 result가 최종 결과물로 저 결과물이 AsyncImagePainter에서 AsyncImagePainter.State로 변환되고 이것을 그리는 것이다.

proceed함수는 다음과 같다.

override suspend fun proceed(): ImageResult {
        val interceptor = interceptors[index]
        val next = copy(index = index + 1)
        val result = interceptor.intercept(next)
        checkRequest(result.request, interceptor)
        return result
    }

이것만 보면 사실 어떻게 이루어지는지 잘 감이 오지 않는다.

위 이미지는 Pluu Dev님의 Coil 요청 가로채기에서 사용된 이미지를 조금 변형한 것인데 위가 완벽한 내용은 아니지만 대충 이런 느낌으로 이해해주면 좋을 듯 하다.

이 인터셉터들이 순서대로 체크하며 정말 네트워크 통신을 해야하는지 확인 후 네트워크 통신을 하게 된다.

인터셉터는 아래와 같은 코드로 add되었다.

override val components = options.componentRegistry.newBuilder()
        .addServiceLoaderComponents(options)
        .addAndroidComponents(options)
        .addJvmComponents(options)
        .addAppleComponents(options)
        .addCommonComponents()
        .add(EngineInterceptor(this, systemCallbacks, requestService, options.logger))
        .build()

그럼 이 EngineInterceptor의 코드를 살펴보자

EngineInterceptor

아래의 코드는 EngineInterceptor에서 이 글에서 살펴볼 부분만 일부 가져온 것이다.

/** The last interceptor in the chain which executes the [ImageRequest]. */
internal class EngineInterceptor(
    private val imageLoader: ImageLoader,
    private val systemCallbacks: SystemCallbacks,
    private val requestService: RequestService,
    private val logger: Logger?,
) : Interceptor {
    ...
  private suspend fun fetch(
      components: ComponentRegistry,
      request: ImageRequest,
      mappedData: Any,
      options: Options,
      eventListener: EventListener,
  ): FetchResult {
      val fetchResult: FetchResult
      var searchIndex = 0
      while (true) {
          val pair = components.newFetcher(mappedData, options, imageLoader, searchIndex)
          checkNotNull(pair) { "Unable to create a fetcher that supports: $mappedData" }
          val fetcher = pair.first
          searchIndex = pair.second + 1

          eventListener.fetchStart(request, fetcher, options)
          val result = fetcher.fetch()
          try {
              eventListener.fetchEnd(request, fetcher, options, result)
          } catch (throwable: Throwable) {
              // Ensure the source is closed if an exception occurs before returning the result.
              (result as? SourceFetchResult)?.source?.closeQuietly()
              throw throwable
          }

          if (result != null) {
              fetchResult = result
              break
          }
      }
      return fetchResult
  }
  ...
}

이 fetch() 함수를 보면 다음의 단계를 거친다.

// 1. 등록된 컴포넌트 중 mappedData(URL 등)를 처리할 수 있는 Fetcher를 찾음
val pair = components.newFetcher(mappedData, options, imageLoader, searchIndex)
val fetcher = pair.first

// 2. 그 Fetcher에게 데이터를 가져오라고 시킴 (실제 네트워크 통신 지점)
val result = fetcher.fetch()

저 fetcher는 Fetcher 인터페이스이고 이 구현체는 NetworkFetcher이다.

마무리

참고 자료

https://pluu.github.io/blog/android/2024/09/22/coil-intercept/

ComponentActivity 코드

@Suppress("deprecation")
final override fun onRetainNonConfigurationInstance(): Any? {
    // Maintain backward compatibility.
    val custom = onRetainCustomNonConfigurationInstance()
    var viewModelStore = _viewModelStore
    if (viewModelStore == null) {
        // No one called getViewModelStore(), so see if there was an existing
        // ViewModelStore from our last NonConfigurationInstance
        val nc = lastNonConfigurationInstance as NonConfigurationInstances?
        if (nc != null) {
            viewModelStore = nc.viewModelStore
        }
    }
    if (viewModelStore == null && custom == null) {
        return null
    }
    // 'NonConfigurationInstances'라는 내부 전용 보관 상자 생성
    val nci = NonConfigurationInstances()
    nci.custom = custom
    nci.viewModelStore = viewModelStore // 여기에 현재의 ViewModel들이 담긴 바구니를 넣음
    return nci // 이 상자를 안드로이드 시스템(OS)에 맡김
}

onPause() -> onStop() -> [이 시점에 호출] -> onDestroy()

ActivityThread.java 
void performDestroyActivity(ActivityClientRecord r, boolean finishing, boolean getNonConfigInstance, String reason) {
    Class < ? extends Activity > activityClass;
    if (localLOGV) Slog.v(TAG, "Performing finish of " + r);
    activityClass = r.activity.getClass();
    if (finishing) {
        r.activity.mFinished = true;
    }
    performPauseActivityIfNeeded(r, "destroy");
    if (!r.stopped) {
        callActivityOnStop(r, false /* saveState */, "destroy");
    }
    if (getNonConfigInstance) {
        try {
            r.lastNonConfigurationInstances = r.activity.retainNonConfigurationInstances();
        } catch (Exception e) {
            if (!mInstrumentation.onException(r.activity, e)) {
                throw new RuntimeException ("Unable to retain activity "
                    + r.intent.getComponent().toShortString() + ": " + e.toString(), e);
            }
        }
    }
    ...
}

이후 액티비티 재생성시 다음 코드로부터 ViewModelStore를 가져옴

ComponentActivity.kt
override val viewModelStore: ViewModelStore
    /**
     * Returns the [ViewModelStore] associated with this activity
     *
     * Overriding this method is no longer supported and this method will be made `final` in a
     * future version of ComponentActivity.
     *
     * @return a [ViewModelStore]
     * @throws IllegalStateException if called before the Activity is attached to the
     *   Application instance i.e., before onCreate()
     */
    get() {
        checkNotNull(application) {
            ("Your activity is not yet attached to the " +
                "Application instance. You can't request ViewModel before onCreate call.")
        }
        ensureViewModelStore()
        return _viewModelStore!!
    }

private fun ensureViewModelStore() {
    if (_viewModelStore == null) {
        val nc = lastNonConfigurationInstance as NonConfigurationInstances?
        if (nc != null) {
            // Restore the ViewModelStore from NonConfigurationInstances
            _viewModelStore = nc.viewModelStore
        }
        if (_viewModelStore == null) {
            _viewModelStore = ViewModelStore()
        }
    }
}

lastNonConfigurationInstance로 파괴되기 전에 저장한 기존의 ViewModelStore를 가지고 있는NonConfigurationInstances를 가져와서 값으로 설정한다.

정리는 완전히 죽을 때만 하고 이것은 ComponentActivity의 init에서 설정

init {
    ...
    @Suppress("LeakingThis")
    lifecycle.addObserver(
        LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_DESTROY) {
                // Clear out the available context
                contextAwareHelper.clearAvailableContext()
                // And clear the ViewModelStore
                if (!isChangingConfigurations) {
                    viewModelStore.clear() <- 여기
                }
                reportFullyDrawnExecutor.activityDestroyed()
            }
        }
    )
    ...
}

마무리

Manifest Android Interview의 R8 스터디용 R8을 조금만 핥아보는 글입니다.

이 글은 traceNewInstance() 메소드 하나만 다루는 아주 짧은 글입니다.

traceNewInstance()

private DexClass traceNewInstance(
      DexType type,
      ProgramMethod context,
      InstantiationReason instantiationReason,
      KeepReason keepReason) {
    DexClass clazz = resolveBaseType(type, context);
    if (clazz != null && clazz.isProgramClass()) {
      DexProgramClass programClass = clazz.asProgramClass();
      if (clazz.isAnnotation() || clazz.isInterface()) {
        markTypeAsLive(programClass, graphReporter.registerClass(programClass, keepReason));
      } else {
        worklist.enqueueMarkInstantiatedAction(
            programClass, context, instantiationReason, keepReason);
      }
    }
    return clazz;
  }

이것은 R8이 new ClassA()와 같은 새로운 인스턴스 생성이 발견되면 호출되는 메소드이다. 한줄씩 무엇인지 살펴보면

1. DexClass clazz = resolveBaseType(type, context);
   • type이 배열일 수도 있기 때문에 기본 클래스 타입(base type)을 찾아서 DexClass로 반환
2. if (clazz != null && clazz.isProgramClass())
   • 해당 클래스가 앱 코드인지 확인한다. (라이브러리나 플랫폼 클래스는 제외)
   • 이후 asProgramClass()로 변환
3. if (clazz.isAnnotation() || clazz.isInterface())
   • 어노테이션이나 인터페이스는 new로 직접 인스턴스화할 수 없으니 "이 타입이 코드에서 참조된다"는 의미로 markTypeAsLive()를 통해 live(살아있는 상태)로 표시
4. ` worklist.enqueueMarkInstantiatedAction(

        programClass, context, instantiationReason, keepReason);`

   • 그 외에 일반 클래스는 실제 인스턴스 생성이 가능하므로 worklist(작업 큐)에 “이 클래스가 인스턴스화되었다”는 작업을 추가한다.

이후 R8의 reachability analysis(도달성 분석) 단계 worklist를 순회하며 사용 중을 판단한다.

결론

스터디를 위해 빠르게 정신없이 글을 3개나 썼는데 막상 써지는 걸 보면 평소에 내가 얼마나 게을렀나를 반성할 수 있었다..ㅎㅎ;;; 추후 worklist 순회하는 부분도 봐야겠다

Manifest Android Interview에서 ART를 더 알아보기 위한 글이다. ART의 코드는 너무나도 방대하여 그중에서 Zygote에 대한 내용만을 아주 살짝 핥아만 볼 것이다.

이 글은 말 그대로 핥아보는 글이라 내부 원리를 너무 깊이 다루진 않는다.

Zygote

일단 Zygote가 무엇인가 안드로이드 공식문서에는 다음과 같이 설명한다.

Zygote는 동일한 애플리케이션 바이너리 인터페이스 (ABI)를 사용하는 모든 시스템 및 앱 프로세스의 루트 역할을 하는 Android 운영체제의 프로세스입니다.

좀더 설명하자면 Zygote는 모든 안드로이드 앱 프로세스의 부모 역할을 수행한다. 기기가 부팅되면 Zygote는 가상 머신을 초기화하고 필요한 시스템 및 앱 클래스를 메모리에 미리 로딩하여, 애플리케이션이 시작될 때마다 이 과정을 반복하지 않고 재사용함으로써 앱 실행 속도를 단축시킨다.

앱은 이 Zygote를 fork()해서 새로운 프로세스를 만들고 이 fork된 자식 프로세스 안에서 앱의 코드(Dex 파일), Application 클래스, Activity 등이 로드된다.

PreZygoteFork()

이것은 fork 직전에 호출되는 함수이다.

void Runtime::PreZygoteFork() {
  if (GetJit() != nullptr) {
    GetJit()->PreZygoteFork();
  }
  if (!heap_->HasZygoteSpace()) {
    Thread* self = Thread::Current();
    // This is the first fork. Update ArtMethods in the boot classpath now to
    // avoid having forked apps dirty the memory.

    // Ensure we call FixupStaticTrampolines on all methods that are
    // initialized.
    class_linker_->MakeInitializedClassesVisiblyInitialized(self, /*wait=*/ true);

    ScopedObjectAccess soa(self);
    UpdateMethodsPreFirstForkVisitor visitor(class_linker_);
    class_linker_->VisitClasses(&visitor);
  }
  heap_->PreZygoteFork();
  PreZygoteForkNativeBridge();
}

복제를 준비하는 코드다. if (GetJit() != nullptr) { GetJit()->PreZygoteFork(); }는 fork전 JIT(Just-In-Time) 컴파일러가 있다면 Zygote fork 전 상태를 정리하고 JIT 캐시를 freeze 상태로 만든다.

이것을 왜 하냐면 Zygote가 fork될 때, JIT 캐시나 컴파일된 코드 영역이 그대로 복제되면 부모(zygote)와 자식(앱) 간에 메모리 충돌이나 불필요한 Copy-On-Write가 생길 수 있다고 한다.

!heap_->HasZygoteSpace()는 런타임의 힙에 Zygote 전용 공유 메모리 영역(zygote space)이 이미 생성되어 있는지를 반환하는데 false면 초 Zygote 생성(또는 최초 fork 전) 이라는 것을 의미한다.

검사 이유는 최초 한 번만 수행해야 할 초기화를 반복하지 않기 위해서이다. 이후 코드는 다음과 같다.

• Thread* self = Thread::Current(); → 현재 실행 중인 스레드 핸들을 가져온다
• class_linker_->MakeInitializedClassesVisiblyInitialized(self, /*wait=*/ true); → 이미 초기화된 클래스들을 완전 초기화된 상태로 다른 스레드에게 보이게(동기화) 만든다.(다른 스레드 중 초기화 진행중이면 대기)
• ScopedObjectAccess soa(self); → 네이티브 코드에서 VM 객체에 안전하게 접근하도록 스코프를 설정한다.
• UpdateMethodsPreFirstForkVisitor visitor(class_linker_); → 각 클래스의 메서드를 미리 업데이트할 방문자(visitor)를 만든다.
• class_linker_->VisitClasses(&visitor); → 모든 클래스들을 순회하며 visitor로 메서드/트램폴린 등을 확정(초기화)한다.

최초 Zygote 초기화 블록 종료

heap_->PreZygoteFork(); 는 Runtime의 PreZygoteFork()가 아닌 힙의 fork를 수행하는 것으로 GC heap 내부의 zygote 관련 영역을 준비한다.

PreZygoteForkNativeBridge()는 Zygote가 fork되기 전에 CPU 변환 계층(Native Bridge)의 상태를 고정시키는 함수이다.

Native Bridge

이게 뭔가 하니 GPT는 다음과 같이 설명한다.

안드로이드에서는앱이 꼭 ARM용 기기에서 ARM 코드만 쓸 필요는 없어. 예를 들어, 기기는 x86 CPU 인데 앱이 ARM용 네이티브 코드(.so 파일) 만 제공하는 경우가 있어. 이럴 때 “Native Bridge” 라는 녀석이 👉 ARM용 코드를 x86에서 돌릴 수 있게 중간에서 변환 해줘. 즉, “CPU가 못 읽는 네이티브 코드를 대신 번역해서 실행시켜주는 번역기”

PostZygoteFork

이것은 fork 직후 실행되는 함수이다.

void Runtime::PostZygoteFork() {
  jit::Jit* jit = GetJit();
  if (jit != nullptr) {
    jit->PostZygoteFork();
    // Ensure that the threads in the JIT pool have been created with the right
    // priority.
    if (kIsDebugBuild && jit->GetThreadPool() != nullptr) {
      jit->GetThreadPool()->CheckPthreadPriority(
          IsZygote() ? jit->GetZygoteThreadPoolPthreadPriority()
                     : jit->GetThreadPoolPthreadPriority());
    }
  }
  // Reset all stats.
  ResetStats(0xFFFFFFFF);
}

jit::Jit* jit = GetJit();
if (jit != nullptr) {
  jit->PostZygoteFork();
  ...
}

fork 전 중단했던 JIT을 다시 활성화하고 새로 생성된 앱 프로세스에서 JIT thread pool을 다시 세팅한다. Zygote 시절의 스레드들은 fork로 복제되면 동작 보장이 안 되기 때문에, 새로 앱 프로세스 전용의 JIT thread pool 을 만드는 것이다.

if (kIsDebugBuild && jit->GetThreadPool() != nullptr) {
      jit->GetThreadPool()->CheckPthreadPriority(
          IsZygote() ? jit->GetZygoteThreadPoolPthreadPriority()
                     : jit->GetThreadPoolPthreadPriority());
    }

이건 디버그용 코드로 방금 생성된 스레드풀의 스레드들의 우선순위를 점검하는 코드이다.

ResetStats(0xFFFFFFFF); 를 통해 최종적으로 ART 내부의 런타임 통계(메서드 호출 수, GC 횟수 등)를 전부 초기화한다. 초기화하는 이유는 Zygote fork시 그 통계 데이터도 그대로 복사되어 자식 앱 프로세스에 남기 때문이라고 한다.

결론

ART 너무 어렵다! 이건 또 언제 공부해야 하나 싶다..!!! 물론 코드를 뒤집어 깔 필요는 없겠지만 그래도 동작 원리는 알면 좋을 것 같은데... 심지어 이 글에서 다룬 내용도 이해 못했다...ㅎ

내부 코드가 정확히 어떻게 동작하는지까지 알아보는 건 너무도 시간이 오래 걸리고 어려워 추후 ART를 정말 싹싹 긁어먹을 때 해봐야지....

용어

• 트램폴린 : ART 런타임에서 JNI(Java Native Interface) 메서드와 같은 네이티브 코드를 호출하기 위한 내부적인 기술

참고

https://source.android.com/docs/core/runtime/zygote?hl=ko https://cs.android.com/android/platform/superproject/+/master:art/runtime/runtime.cc

Manifest Android Interview를 읽으며 안드로이드 파일 시스템에 대해 더욱 알아보기 위한 글이다.

구성 요소나 개념에 대한 내용은 책에 이미 잘 나와있으니 내가 알아볼 것은 코드에서 시작해서 실제 파일 시스템에 어떻게 접근하고 처리하는지를 알아볼 것이다.

대표적인 저장 방식인 DataStore를 다루고자 한다.

DataStore

dataStore.edit { prefs ->
      prefs[ACCESS_TOKEN] = cryptoManager.encrypt(accessToken)
}

흔히 위와 같은 형태로 DataStore를 활용한다. 이 edit은 다음과 같이 작성되어 있다.

public suspend fun DataStore<Preferences>.edit(
    transform: suspend (MutablePreferences) -> Unit
): Preferences {
    return this.updateData {
        // It's safe to return MutablePreferences since we freeze it in
        // PreferencesDataStore.updateData()
        it.toMutablePreferences().apply { transform(this) }
    }
}

그렇다면 이 updateData를 살펴보자

public suspend fun updateData(transform: suspend (t: T) -> T): T

Ctrl+B로 추적하면 실제 구현체까지는 나오지 않는다. 실제 구현체는 External Libraries에 있는 AAR 목록들에서 찾아볼 수 있는 androidx.datastore.core.DataStoreImpl에 있다.

override suspend fun updateData(transform: suspend (t: T) -> T): T {
        val parentContextElement = coroutineContext[UpdatingDataContextElement.Companion.Key]
        parentContextElement?.checkNotUpdating(this)
        val childContextElement = UpdatingDataContextElement(
            parent = parentContextElement,
            instance = this
        )
        return withContext(childContextElement) {
            val ack = CompletableDeferred<T>()
            val currentDownStreamFlowState = inMemoryCache.currentState
            val updateMsg =
                Message.Update(transform, ack, currentDownStreamFlowState, coroutineContext)
            writeActor.offer(updateMsg)
            ack.await()
        }
    }

각 코드를 하나씩 살펴보자

val parentContextElement = coroutineContext[UpdatingDataContextElement.Companion.Key]
parentContextElement?.checkNotUpdating(this)
val childContextElement = UpdatingDataContextElement(
   parent = parentContextElement,
   instance = this
)

먼저 val parentContextElement = coroutineContext[UpdatingDataContextElement.Companion.Key] 여기서 UpdatingDataContextElement.Companion.Key은 아래와 같다.

internal class UpdatingDataContextElement(
    private val parent: UpdatingDataContextElement?,
    private val instance: DataStoreImpl<*>
) : CoroutineContext.Element {

    companion object {
        internal val NESTED_UPDATE_ERROR_MESSAGE = """
                Calling updateData inside updateData on the same DataStore instance is not supported
                since updates made in the parent updateData call will not be visible to the nested
                updateData call. See https://issuetracker.google.com/issues/241760537 for details.
            """.trimIndent()
        internal object Key : CoroutineContext.Key<UpdatingDataContextElement>
    }

즉 해당 DataStore가 호출된 코루틴에서 UpdatingDataContextElement를 받아온다. parentContextElement?.checkNotUpdating(this) UpdatingDataContextElement가 있는지 확인하고 있다면 지금 해당 코루틴에서 DataStore가 업데이트 중인지 checkNotUpdating를 통해 확인한다.

만약 동일 인스턴스에 대한 중첩 호출(재진입)이 감지되면, 이는 교착 상태(Deadlock)를 유발할 수 있으므로 즉시 예외를 발생시킨다.

val childContextElement = UpdatingDataContextElement(
   parent = parentContextElement,
   instance = this
)

이제 자식이 사용할 새로운 UpdatingDataContextElement를 만든다.

처음에는 이게 잘 이해가 안 갔는데 안드로이드 DataStore에서 예를 들어

// 바깥
dataStoreA.updateData {
    // 안쪽
    dataStoreA.updateData { 

        ... 
    }
}

이런식으로 중첩되게 호출되면 데드락이 발생할 수 있지만

// 바깥
dataStoreA.updateData {
    // 안쪽
    dataStoreB.updateData { 

        ... 
    }
}

와 같은 경우는 허용되어야 한다. 그렇기에 같은 DataStore에 대하여 parentContextElement?.checkNotUpdating(this)로 작성중인지를 확인하고 다른 DataStore에 대한 중첩호출은 허용되도록 val childContextElement = UpdatingDataContextElement( parent = parentContextElement, instance = this )로 부모-자식 관계를 형성해주는 것이다.

마지막으로

val ack = CompletableDeferred<T>()
val currentDownStreamFlowState = inMemoryCache.currentState
val updateMsg =
   Message.Update(transform, ack, currentDownStreamFlowState, coroutineContext)
writeActor.offer(updateMsg)
ack.await()

이것은 경쟁 상태를 방지하고 모든 업데이트를 순차적으로 처리하기 위한 로직이다.

1. val ack = CompletableDeferred<T>()
   • 비동기적으로 수행될 업데이트 작업의 최종 결과를 수신하기 위한 객체를 생성
2. val currentDownStreamFlowState = inMemoryCache.currentState
   • 불필요한 디스크 읽기를 줄이기 위해 현재 메모리에 캐시된 데이터 상태를 가져옴
3. val updateMsg = Message.Update(transform, ack, currentDownStreamFlowState, coroutineContext)
   • 실제 업데이트를 수행할 Actor에게 전달할 메시지(작업 단위)를 생성
4. writeActor.offer(updateMsg)
   • 생성된 업데이트 메시지를 실제 작업을 처리하는 actor의 메시지 큐에 전송
5. ack.await()
   • 업데이트 작업을 완료하고 결과를 반환할 때까지 대기

writeActore는 다음과 같이 정의되어 있다.

private val writeActor = SimpleActor<Message.Update<T>>(
   scope = scope,
   onComplete = {
      // We expect it to always be non-null but we will leave the alternative as a no-op
      // just in case.
      it?.let {
         inMemoryCache.tryUpdate(Final(it))
      }
      // don't try to close storage connection if it was not created in the first place.
      if (storageConnectionDelegate.isInitialized()) {
         storageConnection.close()
      }
   },
   onUndeliveredElement = { msg, ex ->
      msg.ack.completeExceptionally(
         ex ?: CancellationException(
            "DataStore scope was cancelled before updateData could complete"
         )
      )
   }
) { msg ->
   handleUpdate(msg)
}

그중 실제로 메시지를 처리하는 handleUpdate를 살펴보자.

private suspend fun handleUpdate(update: Message.Update<T>) {
   update.ack.completeWith(
      runCatching {
         val result: T
         when (val currentState = inMemoryCache.currentState) {
            is Data -> {
               // We are already initialized, we just need to perform the update
               result = transformAndWrite(update.transform, update.callerContext)
            }

            is ReadException, is UnInitialized -> {
               if (currentState === update.lastState) {
                  // we need to try to read again
                  readAndInitOrPropagateAndThrowFailure()

                  // We've successfully read, now we need to perform the update
                  result = transformAndWrite(update.transform, update.callerContext)
               } else {
                  // Someone else beat us to read but also failed. We just need to
                  // signal the writer that is waiting on ack.
                  // This cast is safe because we can't be in the UnInitialized
                  // state if the state has changed.
                  throw (currentState as ReadException).readException
               }
            }

            is Final -> throw currentState.finalException // won't happen
         }
         result
      }
   )
}

그중 살펴볼 것은

is Data -> {
   result = transformAndWrite(update.transform, update.callerContext)
}

is ReadException, is UnInitialized -> {
   if (currentState === update.lastState) {
      readAndInitOrPropagateAndThrowFailure()
      result = transformAndWrite(update.transform, update.callerContext)
   } else {
      throw (currentState as ReadException).readException
   }
}

각각 DataStore가 이미 초기화되었고, 메모리에 정상적인 데이터를 갖고 있다는 Data와 이 막 시작되어 디스크에서 데이터를 한 번도 읽지 않은 상태인 UnInitialized이다. 둘 모두 result = transformAndWrite(update.transform, update.callerContext)로 최종적으로 update하는 건 같다.

readAndInitOrPropagateAndThrowFailure()는 그럼 뭘 할까

private suspend fun readAndInitOrPropagateAndThrowFailure() {
   val preReadVersion = coordinator.getVersion()
   try {
      readAndInit.runIfNeeded()
   } catch (throwable: Throwable) {
      inMemoryCache.tryUpdate(ReadException(throwable, preReadVersion))
      throw throwable
   }
}
internal abstract class RunOnce {
    private val runMutex = Mutex()
    private val didRun = CompletableDeferred<Unit>()
    protected abstract suspend fun doRun()

    suspend fun awaitComplete() = didRun.await()

    suspend fun runIfNeeded() {
        if (didRun.isCompleted) return
        runMutex.withLock {
            if (didRun.isCompleted) return
            doRun()
            didRun.complete(Unit)
        }
    }
}
private va readAndInit = InitDataStore(initTasksList)
private inner class InitDataStore(
        initTasksList: List<suspend (api: InitializerApi<T>) -> Unit>
    ) : RunOnce() {
    ...
    override suspend fun doRun() {
            val initData = if ((initTasks == null) || initTasks!!.isEmpty()) {
                // if there are no init tasks, we can directly read
                readDataOrHandleCorruption(hasWriteFileLock = false)
            } else {
                // if there are init tasks, we need to obtain a lock to ensure migrations
                // run as 1 chunk
                coordinator.lock {
                    val updateLock = Mutex()
                    var initializationComplete = false
                    var currentData = readDataOrHandleCorruption(hasWriteFileLock = true).value

                    val api = object : InitializerApi<T> {
                        override suspend fun updateData(transform: suspend (t: T) -> T): T {
                            return updateLock.withLock {
                                check(!initializationComplete) {
                                    "InitializerApi.updateData should not be called after " +
                                        "initialization is complete."
                                }

                                val newData = transform(currentData)
                                if (newData != currentData) {
                                    writeData(newData, updateCache = false)
                                    currentData = newData
                                }

                                currentData
                            }
                        }
                    }

                    initTasks?.forEach { it(api) }
                    // Init tasks have run successfully, we don't need them anymore.
                    initTasks = null
                    updateLock.withLock {
                        initializationComplete = true
                    }
                    // only to make compiler happy
                    Data(
                        value = currentData,
                        hashCode = currentData.hashCode(),
                        version = coordinator.getVersion()
                    )
                }
            }
            inMemoryCache.tryUpdate(initData)
        }
}

• RunOnce는 오직 한번만 실행되는 것을 보장하는 도구다

이 doRun이 실행되는데 coordinator.lock은 파일 락(File Lock) 등을 사용하여, 이 앱의 모든 프로세스(여러 앱 인스턴스 포함)를 통틀어 오직 하나의 코루틴만이 이 람다 블록에 진입할 수 있도록 보장한다.

이중 디스크에서 데이터를 읽어오고 만약 파일이 손상되었으면(corrupted) 복구(handle)하는 함수인 readDataOrHandleCorruption를 살펴보자

private suspend fun readDataOrHandleCorruption(hasWriteFileLock: Boolean): Data<T> {
        try {
            return if (hasWriteFileLock) {
                val data = readDataFromFileOrDefault()
                Data(data, data.hashCode(), version = coordinator.getVersion())
            } else {
                val preLockVersion = coordinator.getVersion()
                coordinator.tryLock { locked ->
                    val data = readDataFromFileOrDefault()
                    val version = if (locked) coordinator.getVersion() else preLockVersion
                    Data(
                        data,
                        data.hashCode(),
                        version
                    )
                }
            }
        } catch (ex: CorruptionException) {
            var newData: T = corruptionHandler.handleCorruption(ex)
            var version: Int // initialized inside the try block

            try {
                doWithWriteFileLock(hasWriteFileLock) {
                    // Confirms the file is still corrupted before overriding
                    try {
                        newData = readDataFromFileOrDefault()
                        version = coordinator.getVersion()
                    } catch (ignoredEx: CorruptionException) {
                        version = writeData(newData, updateCache = true)
                    }
                }
            } catch (writeEx: Throwable) {
                // If we fail to write the handled data, add the new exception as a suppressed
                // exception.
                ex.addSuppressed(writeEx)
                throw ex
            }

            // If we reach this point, we've successfully replaced the data on disk with newData.
            return Data(newData, newData.hashCode(), version)
        }
    }

이중 readDataFromFileOrDefault()를 통해 드디어 storage에서 파일을 읽어오게 된다!

private suspend fun readDataFromFileOrDefault(): T {
    return storageConnection.readData()
}
private val storageConnectionDelegate = lazy {
    storage.createConnection()
}
internal val storageConnection by storageConnectionDelegate

먼저 createConnection()를 살펴보자.

interface Storage<T> {
    fun createConnection(): StorageConnection<T>
}
interface StorageConnection<T> : Closeable {
    suspend fun <R> readScope(
        block: suspend ReadScope<T>.(locked: Boolean) -> R
    ): R

    suspend fun writeScope(block: suspend WriteScope<T>.() -> Unit)

    val coordinator: InterProcessCoordinator
}

interface ReadScope<T> : Closeable {

    suspend fun readData(): T
}

interface WriteScope<T> : ReadScope<T> {

    suspend fun writeData(value: T)
}

이 인터페이스의 유일한 목적은 createConnection() 메소드를 제공하는 것이다. StorageConnection<T>는 createConnection()이 반환하는 객체로, 실제로 파일(디스크)에 read() 및 write() 작업을 수행하는 구체적인 로직을 담고 있고 실제 구현체는 다음과 같다.

class FileStorage<T>(
    private val serializer: Serializer<T>,
    private val coordinatorProducer: (File) -> InterProcessCoordinator = {
        createSingleProcessCoordinator(it)
    },
    private val produceFile: () -> File
) : Storage<T> {

    override fun createConnection(): StorageConnection<T> {
        val file = produceFile().canonicalFile

        synchronized(activeFilesLock) {
            val path = file.absolutePath
            check(!activeFiles.contains(path)) {
                "There are multiple DataStores active for the same file: $path. You should " +
                    "either maintain your DataStore as a singleton or confirm that there is " +
                    "no two DataStore's active on the same file (by confirming that the scope" +
                    " is cancelled)."
            }
            activeFiles.add(path)
        }

        return FileStorageConnection(file, serializer, coordinatorProducer(file)) {
            synchronized(activeFilesLock) {
                activeFiles.remove(file.absolutePath)
            }
        }
    }

    internal companion object {
        @GuardedBy("activeFilesLock")
        internal val activeFiles = mutableSetOf<String>()

        internal val activeFilesLock = Any()
    }
}

internal class FileStorageConnection<T>(
    private val file: File,
    private val serializer: Serializer<T>,
    override val coordinator: InterProcessCoordinator,
    private val onClose: () -> Unit
) : StorageConnection<T> {

    private val closed = AtomicBoolean(false)
    private val transactionMutex = Mutex()

    override suspend fun <R> readScope(
        block: suspend ReadScope<T>.(locked: Boolean) -> R
    ): R {
        checkNotClosed()

        val lock = transactionMutex.tryLock()
        try {
            return FileReadScope(file, serializer).use {
                block(it, lock)
            }
        } finally {
            if (lock) {
                transactionMutex.unlock()
            }
        }
    }

    override suspend fun writeScope(block: suspend WriteScope<T>.() -> Unit) {
        checkNotClosed()
        file.createParentDirectories()

        transactionMutex.withLock {
            val scratchFile = File(file.absolutePath + ".tmp")
            try {
                FileWriteScope(scratchFile, serializer).use {
                    block(it)
                }
                if (scratchFile.exists() && !scratchFile.atomicMoveTo(file)) {
                    throw IOException(
                        "Unable to rename $scratchFile to $file. " +
                        "This likely means that there are multiple instances of DataStore " +
                        "for this file. Ensure that you are only creating a single instance of " +
                        "datastore for this file."
                    )
                }
            } catch (ex: IOException) {
                if (scratchFile.exists()) {
                    scratchFile.delete() // Swallow failure to delete
                }
                throw ex
            }
        }
    }

    public override fun close() {
        closed.set(true)
        onClose()
    }

    private fun checkNotClosed() {
        check(!closed.get()) { "StorageConnection has already been disposed." }
    }

    private fun File.createParentDirectories() {
        val parent: File? = canonicalFile.parentFile

        parent?.let {
            it.mkdirs()
            if (!it.isDirectory) {
                throw IOException("Unable to create parent directories of $this")
            }
        }
    }
}

일단 StorageConnection을 생성하는 createConnection()부터 살펴보면 다음과 같이 되어있다.

override fun createConnection(): StorageConnection<T> {
   val file = produceFile().canonicalFile

   synchronized(activeFilesLock) {
      val path = file.absolutePath
      check(!activeFiles.contains(path)) {
         "There are multiple DataStores active for the same file: $path. You should " +
                 "either maintain your DataStore as a singleton or confirm that there is " +
                 "no two DataStore's active on the same file (by confirming that the scope" +
                 " is cancelled)."
      }
      activeFiles.add(path)
   }

   return FileStorageConnection(file, serializer, coordinatorProducer(file)) {
      synchronized(activeFilesLock) {
         activeFiles.remove(file.absolutePath)
      }
   }
}

여길 보면 produceFile().canonicalFile로 파일을 불러오는데 그렇다면 이 produceFile()이 뭔지를 알아야 한다. produceFile은 FileStorage의 파라미터로 () -> File이다. 이건

public actual object DataStoreFactory {
    @JvmOverloads // Generate constructors for default params for java users.
    public fun <T> create(
        serializer: Serializer<T>,
        corruptionHandler: ReplaceFileCorruptionHandler<T>? = null,
        migrations: List<DataMigration<T>> = listOf(),
        scope: CoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob()),
        produceFile: () -> File
    ): DataStore<T> = create(
        storage = FileStorage(serializer = serializer, produceFile = produceFile),
        corruptionHandler = corruptionHandler,
        migrations = migrations,
        scope = scope
    )
    ...
}

이 팩토리에서 DataStore가 생성될 때 함께 생성되는데 여기서도 produceFile이 뭔지 알수 없다. 그렇다면 이 팩토리 함수가 호출되는 곳을 찾아가보자.

private val Context.tokenDataStore by preferencesDataStore(name = TOKEN_DATASTORE_NAME)

DataStore 생성을 위임할 때 사용되는 이 preferencesDataStore가 실제 DataStore를 생성하니 이것을 따라가자.

@Suppress("MissingJvmstatic")
public fun preferencesDataStore(
    name: String,
    corruptionHandler: ReplaceFileCorruptionHandler<Preferences>? = null,
    produceMigrations: (Context) -> List<DataMigration<Preferences>> = { listOf() },
    scope: CoroutineScope = CoroutineScope(Dispatchers.IO + SupervisorJob())
): ReadOnlyProperty<Context, DataStore<Preferences>> {
    return PreferenceDataStoreSingletonDelegate(name, corruptionHandler, produceMigrations, scope)
}
internal class PreferenceDataStoreSingletonDelegate internal constructor(
    private val name: String,
    private val corruptionHandler: ReplaceFileCorruptionHandler<Preferences>?,
    private val produceMigrations: (Context) -> List<DataMigration<Preferences>>,
    private val scope: CoroutineScope
) : ReadOnlyProperty<Context, DataStore<Preferences>> {

    private val lock = Any()

    @GuardedBy("lock")
    @Volatile
    private var INSTANCE: DataStore<Preferences>? = null

    /**
     * Gets the instance of the DataStore.
     *
     * @param thisRef must be an instance of [Context]
     * @param property not used
     */
    override fun getValue(thisRef: Context, property: KProperty<*>): DataStore<Preferences> {
        return INSTANCE ?: synchronized(lock) {
            if (INSTANCE == null) {
                val applicationContext = thisRef.applicationContext

                INSTANCE = PreferenceDataStoreFactory.create(
                    corruptionHandler = corruptionHandler,
                    migrations = produceMigrations(applicationContext),
                    scope = scope
                ) {
                    applicationContext.preferencesDataStoreFile(name)
                }
            }
            INSTANCE!!
        }
    }
}

PreferenceDataStoreFactory가 실제 인스턴스를 생성하는 곳을 찾았다! 저 람다가 바로 produceFile이다.

public fun Context.preferencesDataStoreFile(name: String): File =
    this.dataStoreFile("$name.preferences_pb")
public fun Context.dataStoreFile(fileName: String): File =
    File(applicationContext.filesDir, "datastore/$fileName") 

다음과 같이 파일을 생성하는 것을 확인할 수 있다.

public File(File var1, String var2) {
    if (var2 == null) {
        throw new NullPointerException();
    } else {
        if (var1 != null) {
            if (var1.path.isEmpty()) {
                this.path = FS.resolve(FS.getDefaultParent(), FS.normalize(var2));
            } else {
                this.path = FS.resolve(var1.path, FS.normalize(var2));
            }
        } else {
            this.path = FS.normalize(var2);
        }

        this.prefixLength = FS.prefixLength(this.path);
    }
}

그렇다면 이 FS, 파일시스템은 어떻게 되어있을까

static {
    if (IoOverNio.IS_ENABLED_IN_GENERAL) {
        FS = new IoOverNioFileSystem(DefaultFileSystem.getFileSystem());
    } else {
        FS = DefaultFileSystem.getFileSystem();
    }
   ...
}

일단 위와 같이 FS를 선언한다.

class IoOverNioFileSystem extends FileSystem {
    private final FileSystem parent;

    IoOverNioFileSystem(FileSystem var1) {
        this.parent = var1;
    }
    ...
}
final class DefaultFileSystem {
    private DefaultFileSystem() {
    }

    public static FileSystem getFileSystem() {
        return new UnixFileSystem();
    }
}

여기서 UnixFileSystem과 IoOverNioFileSystem을 간단히 설명하자면

• UnixFileSystem : 구형 레거시, Java 7 이전에 사용됨, Unix/Linux 시스템에서 파일 작업을 할 때 사용되던 실제 구현체로 직접 네이티브(C) 코드를 호출하여 운영체제와 통신
• IoOverNioFileSystem : 신형 어댑터, Java 7 이후에 사용됨, 클래스의 요청을 처리하는 '어댑터(Adapter)'로 실제 DefaultFileSystem이 처리한다.

여기서 처음 알게된 건데 DefaultFileSystem는 위의 코드에서 확인할 수 있다시피 UnixFileSystem을 리턴한다. 결국 처리는 UnixFileSystem가 하고 IoOverNioFileSystem는 정말 어댑터의 역할만을 수행한다.

그렇다면 File 생성자의

this.path = FS.resolve(FS.getDefaultParent(), FS.normalize(var2));

에서 이 resolve는 아래와 같이 parent에 위임하고

class IoOverNioFileSystem extends FileSystem {
    ...
    public String resolve(String var1, String var2) {
        return this.parent.resolve(var1, var2);
    }
    ...
}

이 parent는 바로 DefaultFileSystem.getFileSystem() 가 리턴하는 UnixFileSystem이다. UnixFileSystem의 resolve는 아래와 같이 되어있다.

private static String trimSeparator(String var0) {
   int var1 = var0.length();
   return var1 > 1 && var0.charAt(var1 - 1) == '/' ? var0.substring(0, var1 - 1) : var0;
}

public String resolve(String var1, String var2) {
   if (var2.isEmpty()) {
      return var1;
   } else if (var2.charAt(0) == '/') {
      return var1.equals("/") ? var2 : trimSeparator(var1 + var2);
   } else {
      return var1.equals("/") ? trimSeparator(var1 + var2) : trimSeparator(var1 + '/' + var2);
   }
}

즉 실제 파일 경로를 생성한다. 결국

public fun Context.dataStoreFile(fileName: String): File =
    File(applicationContext.filesDir, "datastore/$fileName") 

는 applicationContext.filesDir, "datastore/$fileName"로 만든 파일 경로를 갖는 File 인스턴스를 반환한다.

조금 많이 돌아왔는데 결국은 이렇게 File 인스턴스를 만드는 함수가 바로 produceFile이고 이렇게 얻은 File 인스턴스로 절대경로 등의 값으로

override fun createConnection(): StorageConnection<T> {
   val file = produceFile().canonicalFile

   synchronized(activeFilesLock) {
      val path = file.absolutePath
      check(!activeFiles.contains(path)) {
         "There are multiple DataStores active for the same file: $path. You should " +
                 "either maintain your DataStore as a singleton or confirm that there is " +
                 "no two DataStore's active on the same file (by confirming that the scope" +
                 " is cancelled)."
      }
      activeFiles.add(path)
   }

   return FileStorageConnection(file, serializer, coordinatorProducer(file)) {
      synchronized(activeFilesLock) {
         activeFiles.remove(file.absolutePath)
      }
   }
}

FileStorageConnection를 반환하는 것이다. 그리고 이 FileStorageConnection이

override suspend fun <R> readScope(
        block: suspend ReadScope<T>.(locked: Boolean) -> R
    ): R {
        checkNotClosed()

        val lock = transactionMutex.tryLock()
        try {
            return FileReadScope(file, serializer).use {
                block(it, lock)
            }
        } finally {
            if (lock) {
                transactionMutex.unlock()
            }
        }
    }
    ...
}

와 같고 이 readScope는 다음과 같다.

internal open class FileReadScope<T>(
   protected val file: File,
   protected val serializer: Serializer<T>
) : ReadScope<T> {

    private val closed = AtomicBoolean(false)

    override suspend fun readData(): T {
        checkNotClosed()
        return try {
            FileInputStream(file).use { stream ->
                serializer.readFrom(stream)
            }
        } catch (ex: FileNotFoundException) {
            if (file.exists()) {
                // Re-read to prevent throwing from a race condition where the file is created by
                // another process after the initial read attempt but before `file.exists()` is
                // called. Otherwise file exists but we can't read it; throw FileNotFoundException
                // because something is wrong.
                return FileInputStream(file).use { stream ->
                    serializer.readFrom(stream)
                }
            } else {
                serializer.defaultValue
            }
        }
    }
    ...
}

즉 FileInputStream으로 파일을 읽어오는 것이다. 그럼 이제 다시 DataStoreImpl로 돌아가서 이렇게 파일에서 읽어온 데이터로

private suspend fun readDataOrHandleCorruption(hasWriteFileLock: Boolean): Data<T> {
   try {
       return if (hasWriteFileLock) {
           val data = readDataFromFileOrDefault()
           Data(data, data.hashCode(), version = coordinator.getVersion())
       }
       ...
   }
      ...
}

Data 인스턴스를 만들고 InitDataStore가 doRun()에서

var currentData = readDataOrHandleCorruption(hasWriteFileLock = true).value

의 value인 Preferences로

val initData = if ((initTasks == null) || initTasks!!.isEmpty()) {
   readDataOrHandleCorruption(hasWriteFileLock = false)
} else {
   coordinator.lock {
      val updateLock = Mutex()
      var initializationComplete = false
      var currentData = readDataOrHandleCorruption(hasWriteFileLock = true).value

      val api = object : InitializerApi<T> {
         override suspend fun updateData(transform: suspend (t: T) -> T): T {
            return updateLock.withLock {
               check(!initializationComplete) {
                  "InitializerApi.updateData should not be called after " +
                          "initialization is complete."
               }

               val newData = transform(currentData)
               if (newData != currentData) {
                  writeData(newData, updateCache = false)
                  currentData = newData
               }

               currentData
            }
         }
      }

      initTasks?.forEach { it(api) }
      initTasks = null
      updateLock.withLock {
         initializationComplete = true
      }
      Data(
         value = currentData,
         hashCode = currentData.hashCode(),
         version = coordinator.getVersion()
      )
   }
}
inMemoryCache.tryUpdate(initData)

메모리 캐시를 이 Data의 value인 Preferences로 만든 Data 인스턴스인 initData로 tryUpdate를 통해 업데이트한다.

androidx.datastore.core/DataStoreInMemoryCache
val currentState: State<T>
    get() = cachedValue.value

val flow: Flow<State<T>>
    get() = cachedValue
fun tryUpdate(
   newState: State<T>
): State<T> {
   val updated = cachedValue.updateAndGet { cached ->
      when (cached) {
         is ReadException<T>, UnInitialized -> {
            newState
         }
         is Data<T> -> {
            if (newState.version > cached.version) {
               newState
            } else {
               cached
            }
         }

         is Final<T> -> {
            cached
         }
      }
   }
   return updated
}

즉 state가 Data로 업데이트되었으니 handleUpdate()에서 초기화 작업이 완료된 것이다.

이제 마지막으로 transformAndWrite()를 통해 작성을 해준다.

private suspend fun transformAndWrite(
   transform: suspend (t: T) -> T,
   callerContext: CoroutineContext
): T = coordinator.lock {
   val curData = readDataOrHandleCorruption(hasWriteFileLock = true)
   val newData = withContext(callerContext) { transform(curData.value) }

   curData.checkHashCode()

   if (curData.value != newData) {
      writeData(newData, updateCache = true)
   }
   newData
}

internal suspend fun writeData(newData: T, updateCache: Boolean): Int {
   var newVersion = 0

   storageConnection.writeScope {
      newVersion = coordinator.incrementAndGetVersion()
      writeData(newData)
      if (updateCache) {
         inMemoryCache.tryUpdate(Data(newData, newData.hashCode(), newVersion))
      }
   }

   return newVersion
}

최종적으로 작성되는 곳은 storageConnection.writeScope { ... writeData(newData) ... }로 이것은 아래와 같다.

internal class FileWriteScope<T>(file: File, serializer: Serializer<T>) :
   FileReadScope<T>(file, serializer), WriteScope<T> {

   override suspend fun writeData(value: T) {
      checkNotClosed()
      val fos = FileOutputStream(file)
      fos.use { stream ->
         serializer.writeTo(value, UncloseableOutputStream(stream))
         stream.fd.sync()
      }
   }
}

DataStore에서 사용할 때 키-값의 형식으로 사용하는데 이 Preferences와 디스크에 저장될 .preferences_pb 파일(바이너리 데이터) 사이를 서로 번역/변환하는 것을 serializer가 수행한다.

PreferencesFileSerializer

internal object PreferencesFileSerializer : Serializer<Preferences> {
   internal const val fileExtension = "preferences_pb"

   override val defaultValue: Preferences
      get() {
         return emptyPreferences()
      }

   @Throws(IOException::class, CorruptionException::class)
   override suspend fun readFrom(input: InputStream): Preferences {
      val preferencesProto = PreferencesMapCompat.readFrom(input)

      val mutablePreferences = mutablePreferencesOf()

      preferencesProto.preferencesMap.forEach { (name, value) ->
         addProtoEntryToPreferences(name, value, mutablePreferences)
      }

      return mutablePreferences.toPreferences()
   }

   @Suppress("InvalidNullabilityOverride") // Remove after b/232460179 is fixed
   @Throws(IOException::class, CorruptionException::class)
   override suspend fun writeTo(t: Preferences, output: OutputStream) {
      val preferences = t.asMap()
      val protoBuilder = PreferenceMap.newBuilder()

      for ((key, value) in preferences) {
         protoBuilder.putPreferences(key.name, getValueProto(value))
      }

      protoBuilder.build().writeTo(output)
   }

   private fun getValueProto(value: Any): Value {
      return when (value) {
         is Boolean -> Value.newBuilder().setBoolean(value).build()
         is Float -> Value.newBuilder().setFloat(value).build()
         is Double -> Value.newBuilder().setDouble(value).build()
         is Int -> Value.newBuilder().setInteger(value).build()
         is Long -> Value.newBuilder().setLong(value).build()
         is String -> Value.newBuilder().setString(value).build()
         is Set<*> ->
            @Suppress("UNCHECKED_CAST")
            Value.newBuilder()
               .setStringSet(StringSet.newBuilder().addAllStrings(value as Set<String>))
               .build()
         is ByteArray -> Value.newBuilder().setBytes(ByteString.copyFrom(value)).build()
         else ->
            throw IllegalStateException(
               "PreferencesSerializer does not support type: ${value.javaClass.name}"
            )
      }
   }

   private fun addProtoEntryToPreferences(
      name: String,
      value: Value,
      mutablePreferences: MutablePreferences
   ) {
      return when (value.valueCase) {
         Value.ValueCase.BOOLEAN ->
            mutablePreferences[booleanPreferencesKey(name)] = value.boolean
         Value.ValueCase.FLOAT -> mutablePreferences[floatPreferencesKey(name)] = value.float
         Value.ValueCase.DOUBLE -> mutablePreferences[doublePreferencesKey(name)] = value.double
         Value.ValueCase.INTEGER -> mutablePreferences[intPreferencesKey(name)] = value.integer
         Value.ValueCase.LONG -> mutablePreferences[longPreferencesKey(name)] = value.long
         Value.ValueCase.STRING -> mutablePreferences[stringPreferencesKey(name)] = value.string
         Value.ValueCase.STRING_SET ->
            mutablePreferences[stringSetPreferencesKey(name)] =
               value.stringSet.stringsList.toSet()
         Value.ValueCase.BYTES ->
            mutablePreferences[byteArrayPreferencesKey(name)] = value.bytes.toByteArray()
         Value.ValueCase.VALUE_NOT_SET -> throw CorruptionException("Value not set.")
         null -> throw CorruptionException("Value case is null.")
      }
   }
}

각각을 간단하게 정리하면

1. internal const val fileExtension = "preferences_pb"

• SharedPreferences의 XML과 달리 DataStore는 Protocol Buffers (Protobuf)라는 효율적인 바이너리 포맷 사용
• Protocol Buffers : 데이터의 구조를 미리 약속하고, 이 구조에 맞춰 데이터를 효율적인 바이너리 형태로 변환하는 기술

2. readFrom()

• InputStream (.preferences_pb 파일)에서 바이너리 데이터를 읽어 Protobuf 객체(Preferences)로 파싱하는 함수

3. writeTo()

• Preferences를 Map으로 변환한 후 Kotlin 타입을 Protobuf의 Value 객체로 Wrapping후 바이너리 데이터로 직렬화하여 OutputStream에 작성

그렇다면 이 writeTo를 했으니 실제로 파일에 작성되었을까? 그렇지 않다!

아직은 물리적 디스크에 저장되지 않고 메모리에 있는 버퍼(시스템 캐시)에 복사된다. 만약 OS가 이 버퍼를 디스크에 쓰기 전에 앱이 강제 종료되거나 전원이 꺼지면 데이터는 유실된다!

그것을 방지하는 것이 바로 마지막에 있는 stream.fd.sync()이다.

FileDescriptor

저 fd는 FileDescriptor이고 이 FileDescriptor는 아래와 같이 되어있다.

public final class FileDescriptor {
    ...
    public native void sync() throws SyncFailedException;
}

이 sync()는 native 키워드가 붙어있는 함수로 실제 OS의 함수를 호출한다.

sync()는 지금 바로 메모리 버퍼에 있는 모든 데이터를 물리적 디스크에 동기화하고 OS에 명령하는 함수이다. 이 함수의 핵심은 실제 물리적 매체에 기록될 때까지 반환되지 않아 이 함수가 리턴되면, 데이터가 디스크에 안전하게 저장되었음을 100% 보장한다는 것이다.

즉, DataStore는 단순 작성이 아닌 실제 물리적 디스크에 저장하는 것까지 보장한다.

결론

지금까지 DataStore가 어떻게 파일을 읽고 쓰는지를 알아보았다.

사실 대부분의 DataStore의 코드는 race condition을 방지하고 무결성과 원자성을 보장하는데 집중되어 있고 실제 입출력은 흔히들 아는 FileOutputStream과 FileInputStream로 수행한다.

아무생각없이 사용만했던 DataStore에 대해 조금은 이해한 것 같다.

필자는 nowinandroid에 몇주전 pr을 올렸었다. 이 과정에서 가볍게 공부만 하고 넘어갔던 내용들을 보다 깊이있게 공부해보고자 한다. 이번에는 그중에서 Provider와 Property를 알아볼 것이다.

Provider와 Property

그럼 일단 Provider와 Property가 무엇인지부터 간단히 알아보자. 공식 문서에는 다음과 같이 설명한다.

Property - Represents a value that can be queried and changed. Provider - Represents a value that can only be queried and cannot be changed.

한국어로 번역하면 다음과 같다.

• Provider : 값을 조회하고 변경할 수 있는 것
• Property : 값을 조회만 할 수 있고 변경할 수 없는 것

으로 Provider와 Property는 빌드스크립트에서 value와 configuration을 관리한다.

일단은 이정도만 알아두고 Gradle의 Lazy Configuration에 대해 알아보자.

Lazy Configuration

빌드가 복잡해짐에 따라 특정한 값을 추적하기가 어려워지는데 Gradle은 Lazy Configuration이라는 것을 통해 이 문제를 해결한다.

Gradle의 Lazy Property은 3가지 주요 이점을 제공한다.

• Deferred Value Resolution(값 결정 지연)
• Automatic Task Dependency Management(자동 task 의존성 관리)
• Improved Build Performance(빌드 성능 향상)

자동 Task 의존성 관리만 간단히 설명하자면 어느 한 Task의 출력을 다른 Task의 입력으로 연결하여 의존성을 자동으로 파악할 수 있다는 것이다.

즉

taskB.input.set(taskA.output)

이렇게 한 Task의 출력을 다른 Task의 입력으로 연결해주면 Gradle은 알아서 TaskA부터 실행한다.

Lazy Property는 Provider와 Property라는 2가지 인터페이스로 나타낸다. Provider

• 읽기 전용 프로퍼티
• Provider.get()으로 현재 값 반환
• Provider.map(Transformer)로 다른 Provider 생성 가능

Property

• 읽고 쓰기가 모두 가능한 프로퍼티
• Provider를 extend한다.
• Property.set(T)로 값 지정 이때 기존의 값은 덮어씌움
• Property.set(Provider)는 프로퍼티의 값으로 다른 Provider를 지정하며, 기존에 있던 값은 덮어쓴다. 이를 통해 값이 아직 정해지지 않은 상태에서도 Provider와 Property 인스턴스를 서로 연결할 수 있다.

실제 사용 예시

public abstract class Download extends DefaultTask {
    @Input
    public abstract Property<URI> getUri(); // abstract getter of type Property<T>

    @TaskAction
    void run() {
        System.out.println("Downloading " + getUri().get()); // Use the `uri` property
    }
}

참고자료

https://docs.gradle.org/current/userguide/properties_providers.html https://docs.gradle.org/current/userguide/lazy_configuration.html#lazy_configuration

안드로이드 프로젝트를 멀티 모듈로 진행하다보면 필연적으로 똑같은 플러그인을 똑같이 적용하는 상황을 마주한다. 그럴 때마다 동일한 플러그인을 반복적으로 작성하는 비효율적이라고 느껴지는데 이것을 어떻게 해결할 수 있을까?

구글에 쳐보면 바로 알 수 있듯이 Convention Plugin을 통해 이 문제를 해결할 수 있다고 한다.

하지만 본인은 컨벤션 플러그인에 대해 여러 글을 보아도 이해가 잘 가지 않았다!

글마다 방식도 다르고 플러그인을 dependencies에 추가하라 하기에 따라 해도 해당 플러그인이 없다고 아래와 같이 에러가 발생했다.

또한 필자는 nowinandroid를 많이 참고하는 편인데 nowinandroid의 컨벤션 플러그인은 또 여타 레퍼런스들과는 사뭇 다르다!

그러다 보니 어떻게 해야하는지도 감도 안오고 복붙하니 되긴 되는데 어째서 되는 지 이해가 하나도 안 됐다...

그래서 아예 Gradle부터 하나씩 공부해서 싹다 뒤집어 까보기로 했고 그 과정을 기록하게 되었다.

이 글이 내가 공부하고 이해한 과정을 그대로 담았다.(그래서 틀릴 수도 있다...) 그렇기 때문에 나같은 사람이 또 있다면 이 글이 도움이 되길 바란다...

multi-project build

Convention Plugin에 대해 이야기하기 전에 먼저 Gradle의 multi-project build를 알아야 한다.

multi-project build란 무엇인가?

While some small projects and monolithic applications may contain a single build file and source tree, it is often more common for a project to have been split into smaller, interdependent modules. The word "interdependent" is vital, as you typically want to link the many modules together through a single build. Gradle supports this scenario through multi-project builds This is sometimes referred to as a multi-module project.

Gradle의 공식 문서에는 위와 같이 적혀있다. 내용은 아래와 같다.

프로젝트가 더 작고 상호의존적인 모듈로 분할되는 것이 일반적이고 Gradle은 multi-project builds로 그것을 지원한다 이것은 때때로 multi-module project라 불린다.

즉 멀티 프로젝트란 안드로이드에서의 멀티 모듈을 말한다. 아래의 예시로 좀더 살펴보자.

├── .gradle
│   └── ⋮
├── gradle
│   ├── libs.versions.toml
│   └── wrapper
├── gradlew
├── gradlew.bat
├── settings.gradle.kts 
├── sub-project-1
│   └── build.gradle.kts    
├── sub-project-2
│   └── build.gradle.kts    
└── sub-project-3
    └── build.gradle.kts

이것은 3개의 서브 프로젝트을 포함하는 멀티 프로젝트 빌드의 구조인데 어디선가 많이 본듯하다

그렇다면 이 멀티 모듈의 빌드 구조를 알아보자

Multi-Project Build Standards

Gradle community는 멀티 모듈 빌드 구조에 대해서 2가지 표준을 갖고 있다.

1. Multi-Project Builds using buildSrc - buildSrc는 모든 빌드 로직을 포함하는 Gradle 프로젝트 루트의 하위 프로젝트와 같은 디렉토리 2. Composite Builds - build-logic이 재사용 가능한 빌드 로직을 포함하는 Gradle 프로젝트 루트의 빌드 디렉토리인 다른 빌드를 포함하는 빌드.

그중 Convention Plugin은 Composite Builds이므로 BuildSrc가 뭔지만 간단히 알고 넘어가자

BuildSrc란

멀티 모듈에서 공통 빌드 로직(플러그인 등)을 한 곳에 모아두고 여러 모듈에서 쉽게 재사용하기 위한 특별한 디렉토리로, Gradle이 자동으로 인식하고 빌드 로직을 모든 모듈에 제공한다.

라고 하는데 이렇게 보면 Composite Builds랑 무슨 차이인가 싶다. 애초에 목적은 똑같다. 그렇다면 우리는 차이점을 통해 BuildSrc를 알아보자.

• BuildSrc는 단일 빌드의 일부다.
• 그렇기에 메인 프로젝트와 생명주기를 같이 하여 결합도가 높다.
• 내부의 코드 한 줄만 바뀌어도 전체 빌드 로직 캐시가 무효화되어 빌드 속도에 영향을 준다. -> 캐시 효율이 좋지 않다.

이 글에서는 이정도만 알아도 괜찮다. 용도가 같으니 Composite Builds를 이해할수록 BuildSrc도 더 이해가 갈 것이다.

Composite Builds

그렇다면 Composite Builds를 알아보자. Gradle 공식문서에서는 Composite Builds를 아래와 같이 말하고 있다.

Composite Builds, also referred to as included builds, are best for sharing logic between builds (not subprojects) or isolating access to shared build logic (i.e., convention plugins).

Composite Builds는 빌드간 로직(서브 모듈간 X)을 공유하거나 공유 빌드 로직(즉, 컨벤션 플러그인)에 대한 액세스를 격리하는 데 가장 좋다고 한다.

.
├── gradle
├── gradlew
├── settings.gradle.kts
├── build-logic
│   ├── settings.gradle.kts
│   └── conventions
│       ├── build.gradle.kts
│       └── src/main/kotlin/shared-build-conventions.gradle.kts
├── mobile-app
│   └── build.gradle.kts
├── web-app
│   └── build.gradle.kts
├── api
│   └── build.gradle.kts
├── lib
│   └── build.gradle.kts
└── documentation
    └── build.gradle.kts

BuildSrc와 달리 플러그인은 build.gradle.kts와 settings.gradle.kts와 함께 build-logic 자체 빌드로 이동한다.

일단 지금은 플러그인에 대해서는 넘어가고 빌드 구조만을 먼저 이해하자.

여기서 용어를 정리하고 가자면 빌드 != 모듈(프로젝트)이다.

• 빌드(Build) : 전체 빌드 프로세스를 의미한다. 즉, gradle 명령어를 실행할 때 발생하는 모든 작업을 포괄하는 개념으로 하나의 빌드는 하나 이상의 프로젝트(Project)로 구성된다.

• 프로젝트(Project) : 빌드의 기본 단위이다. 각 프로젝트는 자체적인 소스 코드, 리소스, 테스트 등을 가지고 있으며, build.gradle 또는 build.gradle.kts 파일로 프로젝트의 빌드 로직을 정의한다. 멀티 프로젝트 빌드에서는 여러 프로젝트가 계층적으로 구성될 수 있다.

안드로이드를 예시로 더 간단하게 생각하면 settings.gradle.kts가 있으면 빌드, 없으면 모듈이다.

그러므로 settings.gradle.kts가 루트 프로젝트에만 있는 일반적인 멀티 모듈 프로젝트들은 단일 빌드다.

my-composite
├── settings.gradle.kts
├── build.gradle.kts
├── my-app
│   ├── settings.gradle.kts
│   └── app
│       ├── build.gradle.kts
│       └── src/main/java/org/sample/my-app/Main.java
└── my-utils
    ├── settings.gradle.kts
    ├── number-utils
    │   ├── build.gradle.kts
    │   └── src/main/java/org/sample/numberutils/Numbers.java
    └── string-utils
        ├── build.gradle.kts
        └── src/main/java/org/sample/stringutils/Strings.java

이와 같이 독립적인 빌드 my-utils와 my-app이 있을 때 my-app이 저 두 라이브러리의 함수를 사용하고자 한다면 my-utils를 직접 의존하는 것이 아니라 각각을 아래와 같이 의존한다.

dependencies {
    implementation("org.sample:number-utils:1.0")
    implementation("org.sample:string-utils:1.0")
}

실제 안드로이드 환경에서도 각각의 독립적인 빌드가 다른 빌드의 모듈에 있는 함수나 클래스를 사용하려면 각 모듈을 추가해야 한다.

그 이유는 Gradle의 의존성 관리 메커니즘과 관련이 있는데 Gradle은 프로젝트 간의 의존성을 관리할 때, 프로젝트의 결과물(출력물) 을 기준으로 한다.

my-app프로젝트가 number-utils 프로젝트의 기능을 사용하고 싶을 때, my-app은 number-utils가 컴파일되어 생성된 라이브러리(JAR 파일)를 필요로 한다.

만약 빌드 자체에 의존하는 방식이라면, Gradle은 어떤 모듈의 결과물을 사용해야 할지 알 수 없다. 빌드는 여러 프로젝트(모듈)로 구성될 수 있으므로, my-utils 빌드에 의존한다는 것은 number-utils와 string-utils 중 어떤 것을 사용할지 명확하지 않기 때문이다.

그렇다면, my-utils빌드에 있는 모든 모듈(number-utils, string-utils)을 my-app에서 사용하고 싶을 때, 매번 개별적으로 의존성을 추가해야 할까? 이 문제를 해결하고, 독립된 여러 빌드를 통합적으로 관리하기 위해 등장한 것이 바로 Composite Builds다.

이 Composite Builds에 포함된 빌드를 included build라고 한다.

이러한 Composite Builds를 설정하는 방법은 간단하다. settings.gradle.kts 파일에 포함하고 싶은 빌드의 위치를 명시해주면 된다.

안드로이드를 예시로 들면 루트 프로젝트의 settings.gradle.kts에 다음과 같이 빌드를 includeBuild로 추가하면 된다.

pluginManagement {
    includeBuild("build-logic")
    repositories {
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
        gradlePluginPortal()
    }
}

지금까지 Composite Builds를 통해 컨벤션 플러그인이 어떻게 동작하는지 기본적인 지식을 알았다. 물론 이것만으로는 아직 컨벤션 플러그인을 이해하기엔 부족하다. 이번에는 플러그인에 대해 알아보자.

Plugin

일단 플러그인이 무엇인가 살펴보면 Gradle에서는 다음과 같이 정의한다.

A plugin is a reusable piece of software that provides additional functionality to the Gradle build system.

한국어로 직역하면 Gradle 빌드 시스템에 추가적인 기능을 제공하는 재사용가능한 소프트웨어 조각이라고 한다. 플러그인은 크게 3종류가 있다.

• Script Plugins
• Precompiled Script Plugins
• BinaryPlugins 각각을 알아보자

  Script Plugins

  이것은 Gradle에서도 추천하지 않는 방식이다. 그 이유는 일단 재사용성이라는 이점으로 플러그인을 사용하는데 재사용성이 그리 좋지 않기 때문이다. 하지만 동작 방식을 아는 것은 중요한데 왜냐하면 우리가 최종적으로 수행할 방식과 유사한 부분이 있기 때문이다.

예시 코드를 살펴보자.

// build.gradle.kts
// Define a plugin
class HelloWorldPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.tasks.register("helloWorld") {
            group = "Example"
            description = "Prints 'Hello, World!' to the console"
            doLast {
                println("Hello, World!")
            }
        }
    }
}

// Apply the plugin
apply<HelloWorldPlugin>()

HelloWorldPlugin라는 직접 정의한 플러그인으로 Plugin<Project>를 구현한다. 그렇기 때문에 apply를 override해주어야한다. 내부는 간단하다. 그냥 helloWorld라는 task를 register로 등록해주는 것이 전부다.

./gradlew helloWorld

로 확인해보면 Hello World가 출력된다. 하지만 이것은 빌드 스크립트에 직접 적는 inline 방식으로 적용된다.

Precompiled Script Plugins

직접 적는 거면 굳이 쓸 필요가 있을까? 그렇기에 우리는 사전에 컴파일된 플러그인을 사용해야한다. 일단 Gradle에서 어떻게 설명하는지를 보자.

Precompiled script plugins are Groovy DSL or Kotlin DSL scripts compiled and distributed as Java class files packaged in some library. They are meant to be consumed as a binary Gradle plugin, so they are applied to a project using the plugins {} block.

한국말로 번역하면 다음과 같다.

Precompiled script plugin은 .gradle.kts 또는 .gradle 확장자를 가진 Gradle 스크립트 파일을 미리 컴파일(Precompiled)하여, 다른 프로젝트에서 바이너리(binary) 라이브러리처럼 사용할 수 있도록 만든 Gradle 플러그인입니다.

예시 코드를 살펴보자

// plugin/src/main/kotlin/my-plugin.gradle.kts
// This script is automatically exposed to downstream consumers as the `my-plugin` plugin
tasks {
    register("myCopyTask", Copy::class) {
        group = "sample"
        from("build.gradle.kts")
        into("build/copy")
    }
}

위와 같이 플러그인을 정의한 후

// consumer/build.gradle.kts
plugins {
    id("my-plugin") version "1.0"
}

사용할 모듈의 build.gradle.kts의 plugins에 .gradle.kts를 뺀 이름으로 추가하면 사용할 수 있다.

이렇게 보면 감이 잘 안 올수 있다. 조금 더 익숙한 예시를 보자.

// plugin/src/main/kotlin/my-plugin.gradle.kts
// 1. 어떤 플러그인들을 기반으로 할지 먼저 적용
plugins {
    id("com.android.library")
    id("org.jetbrains.kotlin.android")
}

// 2. 안드로이드 관련 공통 설정
android {
    compileSdk = 34

    defaultConfig {
        minSdk = 26
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
}

// 3. 공통으로 사용할 라이브러리 추가
dependencies {
    implementation("androidx.core:core-ktx:1.13.1")
    implementation("androidx.appcompat:appcompat:1.7.0")
    testImplementation("junit:junit:4.13.2")
}

똑같이 자신이 사용할 플러그인을 정의한 후

// consumer/build.gradle.kts
plugins {
    id("my-plugin")
}

dependencies {
    // 이 모듈에만 필요한 특별한 라이브러리만 추가
    implementation("com.google.android.material:material:1.12.0")
}

사용할 모듈에 추가해주면 된다.

뭔가 슬슬 컨벤션 플러그인에 다가가는 게 느껴진다. 사실 이 방식으로도 컨벤션 플러그인을 구현할 수 있다. 실제로 Precompiled Plugin으로 build-logic을 구성하는 프로젝트도 쉽게 찾아볼 수 있기도 하고 말이다.

하지만 나는 신실한 nowinandroid 신봉자다. nowinandroid는 마지막으로 설명할 방식으로 구현하였다. 그럼 플러그인의 남은 한 종류를 알아보자.

Binary Plugins

Binary plugins are compiled plugins typically written in Java or Kotlin DSL that are packaged as JAR files. They are applied to a project using the plugins {} block. They offer better performance and maintainability compared to script plugins or precompiled script plugins.

간단히 설명하면 다음과 같다.

Binary Plugins는 Java나 Kotlin DSL로 작성된 컴파일된 플러그인으로 script plugins이나 precompiled plugins보다 더 나은 성능과 유지보수성을 갖는다.

예제 코드로 좀더 살펴보자.

//plugin/src/main/kotlin/plugin/MyPlugin.kta
class MyPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.run {
            tasks {
                register("myCopyTask", Copy::class) {
                    group = "sample"
                    from("build.gradle.kts")
                    into("build/copy")
                }
            }
        }
    }
}

익숙한 모양새이다. Script Plugins처럼 직접 플러그인을 정의한 후

//consumer/build.gradle.kts
plugins {
    id("my-plugin") version "1.0"
}

precompiled plugins처럼 추가해주면 된다.

그렇다면 Script Plugin과 Binary Plugin은 뭐가 다르길래 똑같이 생겨놓고 이런 차이가 생기는 걸까?

바로 build.gradle.kts에 직접 코드를 작성하는 것과, 별도의 프로젝트 폴더(src/main/kotlin)에 작성하는 것은 Gradle이 코드를 처리하는 방식 자체를 완전히 바꾸기 때문이다.

Gradle 공식문서에서는 차이점을 다음과 같이 서술한다.

• A binary plugin is compiled into bytecode, and the bytecode is shared.

• A script plugin is shared as source code, and it is compiled at the time of use.

즉, Binary Plugin은 사전에 바이트코드로 컴파일되고 그 바이트코드가 공유되며 필요한 곳에서는 바로 실행만 하면 되는 것이며 Script Plugin은 소스코드가 공유되고 사용될 때 그곳에서 즉석으로 컴파일된다는 차이가 있다.

Gradle에서도 최종적으로는 Binary Plugin을 사용하는 것을 권장한다.

지금까지 그러면 Composite Builds와 플러그인에 대해 알아보았다.

이제는 슬슬 컨벤션 플러그인을 어떻게 작성하면 될지 감이 올 것이다. 본격적으로 컨벤션 플러그인을 만들어보자.

컨벤션 플러그인

지금까지의 내용을 조합하면 컨벤션 플러그인은 Composite Build이고 사전에 만들어놓은 플러그인을 미리 컴파일한 뒤 그것을 공유함으로서 플러그인과 라이브러리 관리를 용이하게 하는 것이다.

build-logic 생성

그럼 가장 먼저 Composite Build 구조를 세팅하자. Composite Buids에서의 예시코드와 동일하게 build-logic이라는 자체 빌드를 생성해준다.

이때는 Java or Kotlin 모듈로 생성해주는데 이때는 아직 별도의 빌드가 아닌 모듈이기에 settings.gradle.kts가 없다. 그렇기에 이것을 직접 추가해준다. 내용은 루트 프로젝트의 settings.gradle.kts를 복붙해주면 된다. 여기서 만약 build-logic의 gradle.properties를 별도로 설정하고 싶다면 추가해줘도 된다.

이렇게 하면 settings.gradle.kts에 Code insight unavailable이라고 Load Script Configurations을 누르라고 하는데 막상 눌러도 해결되지 않을 것이다.

이것은 처음 모듈을 만들 때 메인 프로젝트의 settings.gradle.kts에 모듈로서 추가되었기 때문이다. 하지만 우리는 이것을 별도의 빌드로서 includeBuild로 추가해주어야 한다. 그러니 본 프로젝트의 settings.gradle.kts에서 자동으로 추가된

include(":build-logic:convention")

을 제거하고 pluginManagement에 includeBuild("build-logic")를 추가해준다.

커스텀 플러그인 생성

이제 본인이 만들고 싶은 커스텀 플러그인을 만들자. 이 글에서는 Hilt에 필요한 플러그인과 라이브러리를 한번에 관리할 수 있는 HiltConventionPlugin을 만들 것이다.

그전에 먼저 버전 카탈로그를 다른 빌드인 build-logic에서도 사용하기 위한 세팅을 해주자. build-logic의 settings.gradle.kts의 dependencyResolutionManagement에 아래와 같이 버전 카탈로그를 설정해준다.

dependencyResolutionManagement {
    repositories {
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

이후 convention모듈의 build.gradle.kts에 다음과 같이 작성해준다.

plugins {
    `kotlin-dsl`
}

group = "com.example.conventionplugin.buildlogic"

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

kotlin {
    compilerOptions {
        jvmTarget = JvmTarget.JVM_17
    }
}

dependencies {
    compileOnly("com.android.tools.build:gradle:8.12.1") 
    //AGP 버전은 stable한 것으로 하자.
    //2025-08-24 기준 최신 버전은 
    //lint와의 충돌이슈가 있어 8.10.1을 사용하는 것을 권장한다.
}

그다음에 convention 모듈에 ProjectExtensions라는 파일을 추가한다. 사실 이름이 저럴 필요는 없지만 nowinandroid는 위의 이름으로 되어있다. nowinandroid를 따라서 나쁠 건 없지 않을까 싶다ㅎㅎ;; 이 ProejctExtensions에 아래와 같이 작성해준다.

import org.gradle.api.Project
import org.gradle.api.artifacts.VersionCatalog
import org.gradle.api.artifacts.VersionCatalogsExtension
import org.gradle.kotlin.dsl.getByType

val Project.libs
    get(): VersionCatalog = extensions.getByType<VersionCatalogsExtension>().named("libs")

이러면 이제 버전 카탈로그를 libs로 간단히 사용할 수 있다. 이제 HiltConventionPlugin을 작성해보자.

class HiltConventionPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        with(target) {
            apply(plugin = "com.google.devtools.ksp")
            apply(plugin = "dagger.hilt.android.plugin")

            dependencies {
                "ksp"(libs.findLibrary("hilt.compiler").get())
                "implementation"(libs.findLibrary("hilt.android").get())
            }
        }
    }
}

이건 nowinandroid를 기반으로 간단하게 작성한 것이다. 이것에 hilt를 완전히 전담하게 하고 싶다면

"implementation"(libs.findLibrary("androidx.hilt.navigation.compose").get())

이것도 추가해주면 된다. nowinandroid는 별도의 feature용 플러그인에 추가한다. 본인의 프로젝트에 맞게 설정해주자.

플러그인 등록

이제 이렇게 작성한 플러그인을 등록해줘야 한다. convention모듈의 build.gradle.kts의 맨 아래 자신의 플러그인을 등록해준다.

dependencies {
...
}
gradlePlugin {
    plugins {
        register("hilt") {
            id = libs.plugins.custom.hilt.get().pluginId
            implementationClass = "HiltConventionPlugin"
        }
    }
}

• id : 등록할 플러그인의 아이디 설정, 버전 카탈로그에 본인이 사용할 아이디

  [plugins]
  android-application = { id = "com.android.application", version.ref = "agp" }
  kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }
  kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }
  android-library = { id = "com.android.library", version.ref = "agp" }
  jetbrains-kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "jetbrainsKotlinJvm" }
  

custom-hilt = { id = "custom.hilt" }

본인이 하고 싶은 플러그인 아이디를 설정한다.
+ `implementationClass` : 등록할 플러그인 파일 이름

이제 생성과 등록을 모두 완료하였으니 사용하고 싶은 모듈에 추가해서 사용하면 된다.
```kotlin
// app/build.gradle.kts
plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.compose)
    alias(libs.plugins.custom.hilt)
}

마무리

지금까지 컨벤션 플러그인을 만드는 방법을 알아보았다.

Project의 CommonExtension로 아예buildConfig나 compileOptions등을 관리할 수도 있다. 이 부분은 다루지 않았지만 지금까지의 내용으로 다른 코드를 보고 자신에게 필요한 build-logic을 구성할 수 있을 것이다.

하지만 단순히 작성할 줄 아는 정도로는 조금 아쉽다. 다음으로는 Project를 비롯한 빌드에 관련된 것들을 좀 더 뒤집어 까볼 예정이다.

참고자료

https://docs.gradle.org/current/userguide/plugins.html https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html https://docs.gradle.org/current/userguide/intro_multi_project_builds.html https://docs.gradle.org/current/userguide/composite_builds.html#composite_builds

안드로이드 앱을 만들다보면 @Serializable을 사용하는 경우가 굉장히 많다.

하지만 직렬화 인터페이스는 Serializable만 있는 것이 아니다.
Parcelable도 존재한다.

비교에 들어가기 전 두 인터페이스의 차이를 간단하게 설명하자면 Serializable은 리플렉션을 사용해 직렬화를 수행하고 Parcelable은 그렇지 않아 속도가 빠르다는 이점이 있다.

그렇다면 무조건 Parcelable을 사용하는 것이 좋지 않을까 싶지만 그렇지 않다.

이것은 두 인터페이스의 용도가 다르기 때문이다.

Parcelable과 Serializable

일반적으로 Serializable를 dto나 Entity에서 흔히 사용하는데 Serializable은 표준 자바 인터페이스로 서버와 안드로이드 클라이언트 간 데이터 모델을 공유하기 쉽다.

또한, Retrofit 같은 네트워크 통신 라이브러리들이 JSON 변환을 기본적으로 지원하여 서버와의 통신에 사용하기 편리하다.

즉, 두 인터페이스는 용도가 다르다.

• Serializable : 서버와의 통신, Java 표준 인터페이스라서 서버 개발자와 안드로이드 개발자가 동일한 모델을 공유 가능
• Parcelable : 안드로이드 SDK 특화, 안드로이드 컴포넌트 간에 데이터를 효율적으로 전달할 때 사용, Intent에 데이터를 추가할 때, Bundle을 사용할 때 사용

하지만 안드로이드 컴포넌트 간에 데이터 전달에도 편의상 Serializable을 사용하는 경우가 많다.

본인도 그냥 Serializable 하나만 써도 되지 않을까 싶은 의문이 들어 두 인터페이스의 성능을 비교해보고자 한다.

이미 이것을 비교한 좋은 글이 있다. 하지만 이것은 2018년에 작성되었고 코틀린, Compose환경도 아닌만큼 Parcelize가 추가된 현재는 어떤 차이가 있는지 알아보자.

Serializable

@Serializable
data class Person(
    val name: String,
    val age: Int
)
    val person = Person(SAMPLE_NAME, SAMPLE_AGE)

    val timeNs = measureNanoTime {
        val serialized = json.encodeToString(person)
        val restored = json.decodeFromString<Person>(serialized)
    }

    val timeMs = timeNs / 1_000_000.0
    Log.d("Test", "1. JSON Serializable: $timeNs ns (${String.format("%.3f", timeMs)} ms)")

위와 같이 간단한 data class를 직렬화 역직렬화를 해보자.

테스트 결과 다음과 같은 시간이 걸렸다.

Parcelize

@Parcelize
data class Person(
    val name: String,
    val age: Int
) : Parcelable

동일한 data class를 @Parcelize 어노테이션으로만 바꿔준다.

val person = Person(SAMPLE_NAME, SAMPLE_AGE)

    val timeNs = measureNanoTime {
        val parcel = Parcel.obtain()
        parcel.writeParcelable(person, 0)
        parcel.setDataPosition(0)
        val restored = parcel.readParcelable<Person>(Person::class.java.classLoader)!!
        parcel.recycle()
    }

    val timeMs = timeNs / 1_000_000.0
    Log.d("Test", "2. Parcelize Parcelable: $timeNs ns (${String.format("%.3f", timeMs)} ms)")

테스트 결과 아래와 같은 시간이 걸렸다.

유의미할 정도로 큰 속도 차이가 존재한다!

이전의 Parcelable 인터페이스는 직접 직렬화/역직렬화 코드를 작성해야했지만 Parcelize는 그것도 필요없다.

Custom Serializable

@Serializable
data class Person(
    val name: String,
    val age: Int
) {
    fun writeObject(out: ObjectOutputStream) {
        out.writeUTF(name)
        out.writeInt(age)
    }

    fun readObject(input: ObjectInputStream): Person {
        val name = input.readUTF()
        val age = input.readInt()
        return Person(name, age)
    }
}

이번에는 직접 직렬화/역직렬화를 한 Serializable이다.

val person = Person(SAMPLE_NAME, SAMPLE_AGE)

    val timeNs =  measureNanoTime {
        val byteOut = ByteArrayOutputStream()
        val objectOut = ObjectOutputStream(byteOut)
        person.writeObject(objectOut)
        objectOut.flush()
        val bytes = byteOut.toByteArray()

        val byteIn = ByteArrayInputStream(bytes)
        val objectIn = ObjectInputStream(byteIn)
        val restored = person.readObject(objectIn)
    }
    val timeMs = timeNs / 1_000_000.0
    Log.d("Test", "3. Custom JSON Serializable: $timeNs ns (${String.format("%.3f", timeMs)} ms)")

동일하게 직렬화/역직렬화를 수행해준다. 기존의 @Serializable을 사용한 것보다 훨씬 빠르다.

하지만 이 또한 @Parcelize에 비하면 느리다.

결론

현재는 Parcelable 인터페이스도 직접 로직을 구현할 필요가 없어진만큼 안드로이드 컴포넌트간의 데이터 전달에는 @Parcelize를 사용하는 것이 성능상으로 굉장한 이점을 갖기에 되도록이면 @Parcelize를 사용해보자.

안드로이드 앱을 만들다보면 이미지url을 사용하는 경우가 많다. 이미지url을 사용하는 방법도 Coil, Glide 등 굉장히 다양하다. 그렇다면 무엇을 사용하는 게 좋을까? 라는 의문이 자연스럽게 생긴다. 그래서 Coil과 Glide를 차이를 찾아보던 중 롯데ON 기술블로그에서 좋은 글을 발견했다.

그러나 위 글이 작성된 시점은 2022년이다. 현재 Coil이 보다 안정화되고 Compose가 보다 활성화된 현재 시점에서 주로 쓰는 AsyncImage()로 Compose 환경에서의 차이를 한번 확인해보고 싶어졌다.

테스트 환경

• 기기 : 삼성 갤럭시 S24
• Coil 버전 : 2.2.2
• Glide 버전(Compose) : 1.0.0-alpha.1
• 이미지는 원본이미지 사용

테스트 절차

Coil과 Glide를 사용해서 각각 이미지를 불러오고 이를 Android Studio Profiler로 확인해준다.

• 처음 앱을 실행했을 경우(앱 제거 후 재설치)
• 캐시가 저장된 후 실행했을 경우

두 경우의 상황에서 각각 Profiler를 통해 검사해준다.

시점은 앱 실행 후 15초 지점으로 몇번의 테스트 결과 이 상황에서 안정값과 이전 값의 비교를 확인하기 용이했다.

테스트 코드

1. Coil

   @Composable
   fun LoadImage(imageUrl: String) {
    AsyncImage(
        model = imageUrl,
        contentDescription = "Coil Image"
    )
   }

2. Glide

   @OptIn(ExperimentalGlideComposeApi::class)
   @Composable
   fun LoadImage(imageUrl: String) {
    GlideImage(
        model = imageUrl,
        contentDescription = "Glide Image"
    )
   }

   테스트 실행

   Coil

   처음 실행

   

   캐시가 저장된 후

   

Glide

처음 실행

캐시가 저장된 후

분석

1. Coil은 비동기로 실행되는 만큼 실제 환경에서 이미지가 순차적으로 로딩되는 것을 확인할 수 있었다. 반면에 Glide는 모든 이미지가 한번에 로딩되는 것을 확인할 수 있었다.

2. 캐시값이 없는 처음 실행하는 상황에서 Coil은 133.5MB, Glide는 141MB로 Coil이 메모리 사용량이 더 적었다.

3. 캐시값이 저장된 후에는 Coil은 129.9MB, Glide는 119.8MB로 Glide가 메모리 사용량이 더 적었다.

4. 두 상황에서 Coil은 상대적으로 메모리 사용량에 대한 편차가 작았다. Coil의 메모리 사용량 차 : 3.6MB Glide의 메모리 사용량 차 : 21.2MB

결론

✔️ Glide

• 반복되는 이미지 사용이 많아 캐시 데이터 사용이 많을 경우

✔️ Coil

• 다양한 이미지를 사용해서 캐시의 사용이 어려울 경우
• 어느 상황이던간에 일정한 성능이 필요한 경우

물론 Glide는 View기반이고 Coil이 보다 Compose 친화적으로 최근에는 Coil을 추천하는 추세이다. 그렇지만 상황에 따라 필요한 라이브러리를 적절히 사용하는 것이 좋아보인다.

기업들의 기술 스택 요구사항을 보면 늘 Hilt가 빠지지 않는다. 경험이 많지 않은 나는 아직까지 Hilt의 필요성을 느끼지 못했고 '굳이 의존성 주입을 해야하나?' 라는 생각도 했었다. 또한 Hilt를 사용해본적이 없어서 언제 어느 상황에서 Hilt를 사용해야 할지 감도 안 왔었다. 최근 NowInAndroid 클론앱을 만들며 안드로이드를 공부하면서 Hilt를 왜 쓰는 지 알아보고자 한다.

NIA는 위의 아키텍처 패턴을 따르고 있고 나도 최대한 이를 따르고자 하였다. Data Layer에 속하는 Repository가 저장소에서 값을 받아오면 UI Layer의 ViewModel에서는 Repository를 호출해 데이터를 가져오고, Compose에서 관찰할 수 있도록 상태를 관리하는 구조로 설계 후 구현을 시작했다.

Hilt 적용 이전

class UserDataRepository {
    private val firestore = FirebaseFirestore.getInstance()

    suspend fun getUser(userId: String): User? = suspendCancellableCoroutine { cont ->
        firestore.collection("users").document(userId).get()
            .addOnSuccessListener { document ->
                val user = document.toObject(User::class.java)
                cont.resume(user) { }
            }
            .addOnFailureListener { exception ->
                cont.resumeWithException(exception)
            }
    }
}

UserDataRepository에서 FirebaseFirestore를 직접 인스턴스화하여 Firestore에 저장된 user정보를 받아온다.

class UserViewModel(private val repository: UserRepository) : ViewModel() {

    private val _user = mutableStateOf<User?>(null)
    val user: State<User?> = _user

    fun fetchUser(userId: String) {
        viewModelScope.launch {
            try {
                val userData = repository.getUser(userId)
                _user.value = userData
            } catch (e: Exception) {
                // 예외 처리 로직
            }
        }
    }
}

UserViewModel은 UserRepository를 매개변수로 호출해 데이터를 가져오고, Compose에서 관찰할 수 있도록 상태를 관리한다.

@Composable
fun UserScreen(
    userId: String,
    viewModel: UserViewModel = viewModel(factory = UserViewModelFactory(UserRepository()))
) {
    val user = viewModel.user.value

    LaunchedEffect(userId) {
        viewModel.fetchUser(userId)
    }

    Scaffold(
        topBar = {
            TopAppBar(title = { Text(text = "User Profile") })
        }
    ) { paddingValues ->
        //내부로직
    }
}

View인 UserScreen은 UserViewModel을 다음과 같은 팩토리로 받아온다.

class UserViewModelFactory(private val repository: UserRepository) : ViewModelProvider.Factory {
    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom(UserViewModel::class.java)) {
            return UserViewModel(repository) as T
        }
        throw IllegalArgumentException("Unknown ViewModel class")
    }
}

ViewModelProvider.Factory는 안드로이드 MVVM 아키텍처에서 ViewModel을 생성할 때 커스텀 생성 로직(Repository 의존성 주입)을 적용할 수 있도록 해주는 인터페이스이다.

Hilt를 적용하지 않을 때의 어려움

기본적으로 안드로이드에서는 ViewModelProvider를 사용하여 ViewModel 인스턴스를 생성하는데 이것은 다음과 같은 기본 생성자로만 생성할 수 있다.

val viewModel = ViewModelProvider(this).get(UserViewModel::class.java)

그런데 만약 ViewModel에 아래처럼 Repository같은 인자를 전달하거나 특정한 초기화 로직이 필요한 경우

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    // UserRepository를 받아야 하는 ViewModel
}

ViewModelProvider(this).get(UserViewModel::class.java)를 호출하면 안드로이드 프레임워크가 기본 생성자만 호출하려고 하기 때문에 에러가 발생한다.

기본 생성자만 호출하려는 이유는 다음과 같다고 한다.

• ViewModelProvider는 내부적으로 ViewModel을 생성하고 OS가 상태를 저장하도록 관리함.

• 기본 생성자가 없는 경우, OS는 ViewModel을 어떻게 초기화해야 할지 모름.
• 만약 액티비티/프래그먼트가 재생성될 때 ViewModel을 다시 만들어야 하는데, 개발자가 직접 생성한 인자를 기억할 방법이 없음.

그렇기에 이런 경우 ViewModelProvider.Factory를 구현하여 커스텀 팩토리를 만들어야 한다.

그러나 프로젝트의 규모가 커질수록 ViewModel이 많아질 수 있고 이때마다 팩토리를 만들어줘야 한다는 어려움이 있다. 뿐만 아니라 Dao를 비롯한 아키텍처 구성 요소가 늘어나면 늘어날수록 일일이 의존성 관리를 하는 것은 너무도 어렵고 비효율적인 일이다.

여기서 Hilt의 필요성이 나온다.

Hilt 적용

가장 먼저 해주어야할 것은 Hilt dependency를 추가하는 것이다. 이것은 Android Developers의 설명을 따라주면 된다.

@HiltAndroidApp
class MyApplication : Application() {
    // 초기화 작업 등 필요한 코드 작성
}

Application 클래스를 만들어 app의 최상위에 @HiltAndroidApp 어노테이션을 추가한다.

class MainActivity : ComponentActivity() {
    // Hilt가 필요한 의존성 주입 처리
}

그리고 Activity나 Fragment에는 @AndroidEntryPoint 어노테이션을 추가해주어야 한다. 최상위에만 @HiltAndroidApp을 추가하면 되는 줄 알고 MainActivity에 추가했다가 에러가 발생했다. 반드시 Application을 상속한 클래스에 붙이자.

@Module
@InstallIn(SingletonComponent::class)
object FirebaseModule {

    @Provides
    @Singleton
    fun provideFirebaseFirestore(): FirebaseFirestore {
        return FirebaseFirestore.getInstance()
    }
}

FirebaseFirestore 인스턴스를 주입하는 모듈을 만들어준다.

class UserRepository @Inject constructor(
    private val firestore: FirebaseFirestore
) {
    suspend fun getUser(userId: String): User? = suspendCancellableCoroutine { cont ->
        firestore.collection("users").document(userId).get()
            .addOnSuccessListener { document ->
                val user = document.toObject(User::class.java)
                cont.resume(user) { }
            }
            .addOnFailureListener { exception ->
                cont.resumeWithException(exception)
            }
    }

그리고 Repository 클래스에서 생성자 주입을 활용한다. 이렇게 할 경우 이전 코드에서 직접 인스턴스화했던 FirebaseFirestore를 모듈화하여 결합도를 낮출 수 있다. 또한 기존 코드는 FirebaseFirestore를 다른 클래스에서 사용려면 다른 클래스에서도 직접 인스턴스화를 해야 했으나 Hilt는 인스턴스를 직접 생성하지 않고 생성자 또는 필드 주입을 통해 외부에서 주입받는다.

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel() {

    // Compose에서 사용할 수 있도록 상태 관리
    private val _user = mutableStateOf<User?>(null)
    val user: State<User?> = _user

    fun fetchUser(userId: String) {
        viewModelScope.launch {
            try {
                val userData = repository.getUser(userId)
                _user.value = userData
            } catch (e: Exception) {
                // 에러 처리
            }
        }
    }
}

@Composable
fun UserScreen(userViewModel: UserViewModel = hiltViewModel()) {
    //내부로직
}

이번엔 이전에 팩토리를 만들어주어야 했던 UserViewModel을 비교해보자 가장 큰 차이는 이전 코드와 달리 팩토리가 없다는 것이다. 별도로 의존성을 주입해주어야 했던 이전 코드와 다르게 Hilt를 사용하면 @Inejct 어노테이션을 통해 Hilt가 알아서 의존성을 주입해준다. 또한 @HiltViewModel 어노테이션과 생성자 주입을 사용하면 Hilt가 자동으로 ViewModel 인스턴스를 관리하고 Compose에서는 hiltViewModel()로 ViewModel을 쉽게 가져올 수 있다.

결론

Hilt는 단순히 코드 작성이 편한 것 뿐만 아니라 Hilt 자체적으로 수명 주기를 관리하고 Dagger가 제공하는 컴파일 시간 정확성, 런타임 성능, 확장성의 이점을 갖고있다. 직접 인스턴스를 생성할 때 생기는 강한 결합도를 낮추고 코드의 재사용성과 테스트 용이성, 유연성 그리고 확장성을 높이는 의존성 주입(DI)를 보다 간편하고 효율적으로 사용하고자 Hilt를 사용한다고 볼 수 있다.

S.O.L.I.D

SOLID는 5가지 원칙의 앞글자를 따서 약어로 만든 단어로 각 원칙은 다음과 같다,

• Single-Reponsibility Principle(SRP)
• Open Close Principle(OCP)
• Liskov Subsituation Principle(LSP)
• Interface Segregation Principle(ISP)
• Dependency Inversion Principle(DIP)

Single-Responsibility Principle

Single-Responsibility Principle(단일 책임 원칙)은 한 마디로 다음과 같다.

** 객체는 한 가지 책임/역할만 가져야 한다.**

즉 객체가 변경될 경우 하나의 이유로만 변경이 되어야 한다고 볼 수 있다.

왜 지켜야 하는가?

객체가 모든 일을 다하면 편하고 좋을텐데 왜 책임을 분리할까? 그 이유는 만약 객체가 너무도 많은 책임을 가지고 있을 때 객체의 크기가 굉장히 커짐 -> 해당 객체에서 문제가 발생했을 때 연쇄적인 변화, side effect가 커진다.

어떻게 적용할 수 있을까?

추상화를 통해 혼재된 책임을 각각의 책음으로 분리하여 하나의 책임만 갖도록 설계한다. SRP를 통해 다음과 같은 문제점을 해결할 수 있다.

• Divergent Change

• 떨어뜨려야 할 것을 모아둘 때 발생하는 문제로 혼재된 책임을 각각의 개별 클래스로 분할하여 하나의 책임만을 갖도록 하여 해결

• Shotgun Surgery

• 모아둬야 할 것이 산발적으로 분포되어 있을 때 발생하는 문제로** 책임을 기존의 클래스에 모으거나 새로운 크래스를 만들어 해결**

Open Close Principle

Open Close Principle(개방폐쇄원칙)은 한 마디로 다음과 같다.

객체는 확장에 열려있고 변경에는 닫혀있어야 한다.

그렇다면 확장에 열려있다는 것은 무엇이고 변경에 닫혀있다는 것은 무엇일까?

• 확장에 열려있다 : 객체의 행위가 확장될 수 있다. 행위를 추가해 객체가 하는 일을 바꿀 수 있다.
• 변경에 닫혀있다 : 객체의 확장에 기존 구성요소의 수정이 일어나지 말아야 한다.

왜 지켜야 하는가?

기능을 확장할 때마다 기존의 코드를 수정해야 한다면 비용이 너무 많이 소모된다. -> 기존 코드를 변경하지 않고 쉽게 확장할 수 있어 재사용성과 유연성과 같은 객체 지향의 장점을 극대화

어떻게 적용할 수 있을까?

다음의 단계를 통해 OCP를 적용할 수 있다.

1. 변경(확장)할 것과 변하지 않을 것을 구분한다.
2. 이 두 모듈이 만나는 지점에 인터페이스를 정의한다. (두 지점이 소통하는 부분)
3. 구현에 의존하기 보다는 정의한 인터페이스를 의존하도록 코드를 작성한다.

코드로 보면 다음과 같다.

class PaymentProcessor {
    fun processPayment(method: String) {
        when (method) {
            "CreditCard" -> println("CreditCard 결제")
            "PayPal" -> println("PayPal 결제")
            else -> println("Unknown payment method")
        }
    }
}

위처럼 PaymentProcessor가 정의되어 있을 때 애플페이와 같은 새로운 결제 수단을 추가하려면 when문에 새로운 조건을 추가해야 한다.

위 코드는 매우 간단하여 추가가 어렵지 않지만 프로그램이 거대해질수록 직접 추가하는 데에는 비용이 많이 소모된다.

그렇기에 변경할 부분인 결제수단과 변하지 않는 부분인 결제 그 자체로 구분하고 이것을 인터페이스로 정의하고 이를 의존하도록 수정해준다.

interface PaymentMethod {
    fun pay()
}

class CreditCardPayment : PaymentMethod {
    override fun pay() {
        println("CreditCard 결제")
    }
}
class PayPalPayment : PaymentMethod {
    override fun pay() {
        println("PayPal 결제")
    }
}
class ApplePayPayment : PaymentMethod {
    override fun pay() {
        println("ApplePay 결제")
    }
}

이렇게 수정하면 새로운 결제 수단을 추가하기에도 원활하고 기존의 결제처리방식을 수정할 때에도 해당 결제방식만 수정해주면 된다.

Liskov Substitution Principle

Liskov Subsititution Principle(리스코프 치환 원칙)은 한 마디로 다음과 같다.

서브 타입은 항상 기반 타입으로 교체할 수 있어야 한다.

즉 서브 타입은 언제나 기반 타입과 호환될 수 있어야 하며(하위 클래스가 상위 클래스로 바뀌어도 문제 없어야함) 서브 타입은 기반 타입이 정해둔 약속을 지켜야 한다. 여기서 말하는 약속은 기반 타입이 정의한 public 인터페이스, 예외 처리등을 말한다.

왜 지켜야 하는가?

LSP가 지켜지지 않는다는 것은 OCP가 지켜지지 않는다는 것과 같다. OCP는 상속을 통해 지켜지고 LSP는 규약이 준수된 상속 구조를 보장한다. 그렇기에 LSP에서 주장하는 기반 타입과의 호환이 보장되지 않으면 적절한 수행이 어렵다.

어떻게 적용할 수 있을까?

기반 타입과 서브 타입이 IS-A 관계를 가져야 한다. 예를 들면 "정사각형 is a 직사각형이다" -> 어색하지 않음 "정사각형의 높이 변경 is a 직사각형의 높이 변경" -> 어색함

코드로 보면 다음과 같다,

// 부모 클래스 : 직사각형
open class Rectangle(var width: Int, var height: Int) {
    open fun setWidth(newWidth: Int) {
        width = newWidth
    }

    open fun setHeight(newHeight: Int) {
        height = newHeight
    }

    fun area(): Int {
        return width * height
    }
}

// 자식 클래스 : 정사각형
class Square(side: Int) : Rectangle(side, side) {
    override fun setWidth(newWidth: Int) {
        width = newWidth
        height = newWidth // 정사각형은 너비와 높이가 항상 같아야 함
    }

    override fun setHeight(newHeight: Int) {
        height = newHeight
        width = newHeight // 정사각형은 너비와 높이가 항상 같아야 함
    }
}

fun main() {
    val rectangle: Rectangle = Square(5) // 정사각형을 직사각형으로 취급

    rectangle.setWidth(10) // 너비 변경
    println("Width: ${rectangle.width}, Height: ${rectangle.height}") // 너비와 높이가 둘 다 변경됨 -> 직사각형의 예상과 다름
}

그렇다면 이 문제를 어떻게 해결할 수 있을까?

open class Rectangle(var width: Int, var height: Int) {
    fun area(): Int {
        return width * height
    }
}

// 정사각형 클래스 정의 
class Square(side: Int) {
    private val rectangle = Rectangle(side, side) // 내부적으로 직사각형을 포함

    var side: Int
        get() = rectangle.width
        set(value) {
            rectangle.width = value
            rectangle.height = value 
        }

    fun area(): Int {
        return rectangle.area()
    }
}

다양한 방법이 있겠지만 이런 식으로 정사각형 Has-A 직사각형 관계를 갖도록 수정해볼 수 있다.

Interface Segregation Principle

Interface Segregation Principle(인터페이스 분링 원칙)은 한 마디로 다음과 같다.

인터페이스는 자신의 클라이언트가 사용할 메소드만 가지고 있어야 한다.

만약 어떤 클래스를 이용하는 클라이언트가 여러 개고 이들이 해당 클래스의 특정 부분집합만을 이용한다면 이들을 따로 인터페이스로 분리한다.

왜 지켜야 하는가?

예를 들어 인터페이스가 너무도 비대해진다면 해당 인터페이스의 일정 부분만 필요하더라도 구현이 강제되고 변경에 영향을 받는다는 문제가 발생한다.

SRP가 클래스의 단일 책임을 강조한다면 ISP는 인터페이스의 단일 책임을 강조한다.

어떻게 적용할 수 있을까?

하나의 큰 인터페이스를 여러 개의 작은 인터페이스로 나누어 각 클라이언트가 자신에게 필요한 인터페이스만 의존하도록 설계해야 한다.

코드로 보면 다음과 같다.

interface Worker {
    fun work()
    fun eat()
    fun sleep()
}

class OfficeWorker : Worker {
    override fun work() {
        println("Office worker is working.")
    }

    override fun eat() {
        println("Office worker is eating.")
    }

    override fun sleep() {
        println("Office worker is sleeping.")
    }
}

class Robot : Worker {
    override fun work() {
        println("Robot is working.")
    }

    override fun eat() {
        throw UnsupportedOperationException("Robots do not eat.")
    }

    override fun sleep() {
        throw UnsupportedOperationException("Robots do not sleep.")
    }
}

코드를 보면 Robot과 OfficeWorker는 모두 Worker 인터페이스를 구현하지만 Robot같은 경우에는 먹지도 자지도 않지만 불필요하게 구현해야 한다는 문제가 있다. 단순하게 이를 해결해보면

interface Workable {
    fun work()
}

interface Eatable {
    fun eat()
}

interface Sleepable {
    fun sleep()
}

class OfficeWorker : Workable, Eatable, Sleepable {
    override fun work() {
        println("Office worker is working.")
    }

    override fun eat() {
        println("Office worker is eating.")
    }

    override fun sleep() {
        println("Office worker is sleeping.")
    }
}

class Robot : Workable {
    override fun work() {
        println("Robot is working.")
    }
}

각각의 인터페이스를 분리하고 각 클래스가 필요한 기능만을 구현하는 방식으로 분리할 수 있다.

Dependency Inversion Principle

Dependency Inversion Principle(의존성 역전 원칙)은 한 마디로 다음과 같다.

구체적인 것이 추상적인 것에 의존해야 한다.

상위 객체가 하위 객체에 의존하지 않고 추상화된 인터페이스를 통해서 상호작용하도록 의존성을 반전시킨다.

왜 지켜야 하는가?

상위 객체가 하위 객체에 의존을 가진다면 요구사항이 변경됨에 따라 기능의 확장 및 변경, 재사용이 어렵다는 문제가 발생한다.

어떻게 적용할 수 있을까?

동일 레벨에서는 추상화에 의존하고 하위레벨이 상위 레벨의 추상화를 의존하게 만들어 관계를 역전시키는 방식으로 적용할 수 있다. 이렇게만 보면 이해가 조금 어렵다.

이해를 돕기위해 DIP가 지켜지지 않는 상황의 예시를 코드로 보면 다음과 같다.

// 저수준 : 소리 알람
class SoundAlarm {
    fun ring() {
        println("Beep! Beep! 알람이 울립니다!")
    }
}

// 고수준 : 알람 시스템
class AlarmSystem {
    private val soundAlarm = SoundAlarm() // 저수준에 직접 의존

    fun triggerAlarm() {
        soundAlarm.ring() // 소리 알람만 작동 가능
    }
}

fun main() {
    val alarmSystem = AlarmSystem()
    alarmSystem.triggerAlarm()
}

상위 개념인 알람 시스템이 하위 개념인 구체적인 소리 알람에 직접적으로 의존하여 소리 알람이 아닌 진동 알람과 같은 추가적인 확장이 어렵다. 이를 해결보면

// 추상화 : 알람 인터페이스
interface Alarm {
    fun trigger()
}

// 저수준1 : 소리 알람
class SoundAlarm : Alarm {
    override fun trigger() {
        println("Beep! Beep! 알람이 울립니다!")
    }
}

// 저수준2 : 진동 알람
class VibrationAlarm : Alarm {
    override fun trigger() {
        println("Bzzzz! 진동 알람이 울립니다!")
    }
}

// 고수준 : 알람 시스템
class AlarmSystem(private val alarm: Alarm) {
    fun triggerAlarm() {
        alarm.trigger() // 추상화된 인터페이스를 통해 호출
    }
}

fun main() {
    // 소리 알람 사용
    val soundAlarmSystem = AlarmSystem(SoundAlarm())
    soundAlarmSystem.triggerAlarm()

    // 진동 알람 사용
    val vibrationAlarmSystem = AlarmSystem(VibrationAlarm())
    vibrationAlarmSystem.triggerAlarm()
}

AlarmSystem은 Alarm 인터페이스만 의존하여 구체적인 알람에는 의존하지 않는다. 이렇게 구현할 경우 새로운 알람 방식에 대해서도 AlarmSystem코드를 수정할 필요없이 쉽게 추가할 수 있다.

참고자료

https://www.nextree.co.kr/p6960/ https://www.youtube.com/watch?v=WAufmN_ki4o&list=PLp_FpnyDwvuA9vzOImAAn4COaa9yK71hd https://www.youtube.com/watch?v=7c0tqHLfxlE https://enhancement.tistory.com/5

아키텍처 패턴은 소프트웨어 시스템의 구성 요소와 그 요소들 간의 관계를 정의하는 설계 원칙으로 소프트웨어의 구조와 동작을 정의하기 위한 고수준의 설계 청사진이다.

아키텍처 패턴 장점

• 코드 재사용성 증가
  • 이미 검증된 패턴을 사용하여 새로운 시스템을 개발할 때 시간과 비용을 절약할 수 있고 잘 정의된 컴포넌트는 재사용 가능성을 높인다.
• 코드 가독성 향상
  • 표준화된 구조를 제공하여 다른 개발자도 쉽게 이해할 수 있어 협업을 용이하게 한다.
• 개발 속도 향상
  • 설계 표준화로 인해 팀이 설계 방식을 빠르게 이해하고 개발에 착수할 수 있다.
• 확장성 향상
  • 모듈 간 결합도가 낮아 시스템의 기능을 추가하거나 변경하는 것이 용이하게 설계되어 시스템의 수명을 연장시킨다.

아키텍처 패턴의 단점

• 남용의 위험
  • 간단한 문제에 대해서도 아키텍처 패턴을 적용하려는 것은 오히려 시스템을 복잡하게 만들 수 있다.
• 특정 패턴에 너무 의존하게 되면 오히려 아키텍처 패턴의 장점인 유연성을 저하시킬 수 있다.
• 초기 비용
  • 아키텍처 설계 및 패턴 적용에 시간과 노력이 필요하고 팀원들이 해당 패턴에 대한 이해가 있어야 한다.

-> 단점이 기술적인 부분이 아닌 단순 사용자의 역량에 달려있다는 점에서 디자인 패턴의 유의미한 단점이 없다고 생각한다.

디자인 패턴과 아키텍처 패턴의 차이점

아키텍처 패턴은 시스템의 전체적인 설계를 담당하고, 디자인 패턴은 코드의 세부적인 구현을 담당한다.

MVP

MVP 패턴은 Model, View, Presenter로 구성된 아키텍처 패턴으로 MVC 패턴에서 Controller 대신 Presenter가 존재한다.

구성요소

View *: 사용자 인터페이스를 담당. 사용자와 직접 상호작용하는 부분이며, 사용자 입력을 받고 결과를 표시 *Model : 애플리케이션의 데이터를 표현하고, 데이터 처리 로직을 담당. 비즈니스 로직을 담당하는 부분 Presenter : Model과 View 사이의 중개자 역할. 사용자의 입력을 받아 Model에 전달하고, Model에서 처리된 결과를 View에 전달. View와 Model 사이의 의존성을 줄여 테스트를 용이하게 만들고, 비즈니스 로직을 View로부터 분리.

MVC와의 차이점

MVC 패턴과의 차이점은 MVC 패턴에서는 View에서 Model을 직접 control할 수 있었지만 MVP 패턴에서는 View가 직접 Model을 Control할 수 없어 View와 Model 서로 의존하지 않게 되었으나 여전히 View와 Presenter 사이의 강한 의존성이 존재한다.

작동 방식

1. 사용자 이벤트 발생: 사용자가 View에 있는 버튼을 클릭하거나 입력을 하는 등의 이벤트 발생
2. View에서 Presenter로 전달: 발생한 이벤트는 View에서 Presenter로 전달
3. Presenter에서 Model 처리: Presenter는 전달받은 이벤트에 따라 Model에 필요한 작업을 요청
4. Model 처리 결과: Model은 요청된 작업을 수행하고 결과를 Presenter에게 반환
5. Presenter에서 View 업데이트: Presenter는 Model에서 받은 결과를 바탕으로 View를 업데이트

MVP 패턴의 장점

• UI와 비즈니스 로직의 분리
  • View와 Model 간 결합도가 낮아 각 컴포넌트를 독립적으로 변경하거나 테스트 가능
• 테스트 용이성
  • Presenter가 UI와 독립적이기 때문에 View를 대체하여 비즈니스 로직을 단위 테스트하기가 쉬움.
• 유지보수성 향상
  • UI 로직(View)과 애플리케이션 로직(Model)을 명확히 분리하여 코드를 쉽게 이해하고 수정 가능
• 재사용성 증가
  • Presenter와 Model은 View와 독립적이기에 다른 View에서 동일한 Presente나 Model 재사용 가능
• 확장성
  • 새로운 기능을 추가할 때 기존 코드를 최소한으로 수정하며 확장 가능

MVP 패턴이 적합한 경우

• UI 로직이 복잡하고, 유지보수성이 중요한 프로젝트
• 다양한 UI와 복잡한 사용자 상호작용을 처리해야 하는 경우
• 단위 테스트를 통해 비즈니스 로직의 안정성을 보장하려는 경우

MVVM

MVVM 패턴은 UI와 비즈니스 로직을 분리하여 애플리케이션의 유지보수성, 테스트 용이성, 확장성을 높이는 높이기 위해 설계된 아키텍처 패턴이다. 특히, 데이터 바인딩을 활용하여 UI와 데이터를 연결하는 방식으로 사용자 인터페이스 개발 생산성을 향상시키는 데 중점을 두고 있다.

구성요소

View *: 사용자 인터페이스를 담당. 사용자와 직접 상호작용하는 부분이며, 사용자 입력을 받고 결과를 표시 *Model : 애플리케이션의 데이터를 표현하고, 데이터 처리 로직을 담당. 비즈니스 로직을 담당하는 부분 ViewModel : View와 Model 사이의 중개자 역할. View에 노출될 데이터 관리. 사용자의 입력을 Model에 전달. Model에서 처리된 결과를 View에 반영. 데이터 바인딩을 통해 View와 ViewModel 사이의 데이터를 자동으로 동기화.

MVP와의 차이점

MVP 패턴은 View와 Presenter가 일대일 관계라면 MVVM은 View와 ViewModel간의 관계가 1대 N으로 하나의 ViewModel을 다양한 View에 사용할 수 있다. 또한 ViewModel은 Presenter에 비해 상대적으로 View와 느슨하게 결합되어 있다.

ViewModel은 View에 표시될 데이터를 준비하고 사용자 입력을 처리하여 Model에 전달하는 역할을 수행하고 View의 구체적인 구현에 대한 지식이 필요하지 않다. 그에 비해 Presenter는 View의 상태를 관리하고 사용자 입력을 처리하는 등 다양한 책임을 수행하여 View에 대한 의존도가 높다.

작동방식

1. 사용자 이벤트 발생: 사용자가 View에 있는 버튼을 클릭하거나 입력하는 등의 이벤트가 발생
2. View에서 ViewModel로 전달: 발생한 이벤트는 View에서ViewModel로 전달
3. ViewModel에서 Model 처리: ViewModel은 전달받은 이벤트에 따라 Model에 필요한 작업 요청
4. Model 처리 결과: Model은 요청된 작업을 수행하고 결과를 ViewModel에게 반환
5. ViewModel에서 View 업데이트: ViewModel은 Model에서 받은 결과를 바탕으로 ViewModel의 속성을 업데이트하고 데이터 바인딩을 통해 View가 자동으로 업데이트됨

MVVM 패턴의 장점

• 데이터 바인딩
  • 데이터 바인딩을 통해 UI와 데이터를 자동으로 동기화하여 개발 생산성을 높임
• 테스트 용이성
  • ViewModel을 독립적으로 테스트할 수 있어 테스트 커버리지를 높이고 버그 조기 발견 가능
• 유지보수성
  • 각 구성 요소의 역할이 명확하게 분리되어 있어 코드의 변경 용이. 시스템의 유지보수 쉬움
• 확장성
  • 새로운 기능을 추가하거나 기존 기능을 변경할 때 다른 구성 요소에 미치는 영향 최소화 가능
• UI와 비즈니스 로직 분리
  • UI와 비즈니스 로직을 분리하여 각각 독립적으로 개발하고 테스트 가능

MVVM 패턴이 적합한 경우

• 복잡한 UI와 상태 관리를 요구하는 애플리케이션
• ViewModel과 데이터 바인딩 라이브러리를 활용하여 실시간 데이터 업데이트가 필요한 경우
• 테스트 가능하고 유지보수하기 쉬운 아키텍처가 중요한 프로젝트
• 확장성과 재사용성이 중요한 중대형 프로젝트

클린 아키텍처

클린 아키텍처는 외부 프레임워크나 UI, 데이터베이스 등의 변화에 유연하게 대응할 수 있도록 시스템의 내부와 외부를 명확하게 분리하는 것을 목표로 하는 아키텍처 패턴이다.

클린 아키텍처는 시스템의 구성을 4가지로 나눈다. 먼저 각 구성에 대해 알아보면

시스템의 구성

• 엔티티(Entities)
  • 핵심 비즈니스 로직을 캡슐화
  • 메서드를 가지는 객체, 일련의 데이터 구조와 함수의 집합
  • 가장 변하지 않으며 외부로부터 영향을 받지 않는 영역 ex) 사용자, 상품, 주문 등 실제 세계의 개념을 모델링한 객체
• 유즈 케이스(Use Cases)
  • 애플리케이션의 특화된 비즈니스 로직을 포함한다.
  • 시스템의 모든 유즈 케이스를 캡슐화하고 구현한다.
  • 엔티티로 들어오고 나가는 데이터 흐름을 조정하고 조작한다.
    • 사용자가 시스템에 요구하는 기능을 구현하는 부분 ex) 사용자 등록, 상품 조회, 주문 생성 등
• 인터페이스 어댑터(Interface Adapter)
  • 일련의 어댑터들로 구성한다.
  • 외부 인터페이스에서 들어오는 데이터를 유즈 케이스와 엔티티에서 처리하기 편한 방식으로 변환하며, 유즈 케이스와 엔티티에서 나가는 데이터를 외부 인터페이스에서 처리하기 편한 방식으로 변환 ex) 컨트롤러, 프레젠터, 게이트웨이 등
• 프레임워크와 드라이버(Frameworks & Drivers)
  • 시스템을 실행하기 위한 환경을 제공
  • 시스템의 핵심 업무와는 관련 없는 세부 사항 ex) 프레임워크나, 데이터베이스, 웹 서버 등

소프트웨어 아키텍처는 선을 긋는 기술이며, 나는 이러한 선을 경계(boundary)라고 부른다. 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소을 알지 못하도록 막는다. - Robert C. Martin, Clean Architecture

Android에서의 적용

프리젠테이션 계층(Presentation Layer)

• 사용자와 직접 상호작용하는 계층으로 UI를 구성하고, 사용자의 입력을 받아 도메인 계층으로 전달

View, UI: 직접적으로 플랫폼 의존적인 구현으로 UI 화면 표시와 사용자 입력 담당 Presenter가 명령하는 일만 수행 Presenter: ViewModel과 유사한 역할, 사용자 입력이 왔을 때 어떤 반응을 해야 하는지에 대한 판단을 하는 영역으로 View가 단순히 명령만 수행하도록 함

도메인 계층(Domain Layer)

• 앱의 핵심 비즈니스 로직과 규칙이 포함된 계층으로 프레젠테이션 계층이나 데이터 계층과 독립적

Use Case: 비즈니스 로직이 들어 있는 영역 Entity: 앱의 실질적인 데이터

데이터 계층(Data Layer)

• 애플리케이션의 데이터 관리 및 영속성을 담당
• 외부 데이터 소스(API, 데이터베이스 등)와 상호작용하며, 도메인 계층에서 요구하는 데이터를 제공

Repository: 유즈 케이스가 필요로 하는 데이터의 저장 및 수정 등의 기능을 제공하는 영역으로 데이터 소스를 인터페이스로 참조하여, 로컬 DB와 네트워크 통신을 자유롭게 가능 Data Source: 실제 데이터의 입출력이 실행되는 영역

상위 계층은 기본적으로 하위 계층을 참고하지만 실제로 도메인 계층은 데이터 계층을 참고하고 있지 않다. -> 리포지터리에서 이루어지는 의존성 역전 법칙 때문

의존성 역전이란? 객체 지향 프로그래밍에서 의존 관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다. 이 원칙을 따르면, 상위 계층(정책 결정)이 하위 계층(세부 사항)에 의존하는 전통적인 의존 관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. https://meetup.nhncloud.com/posts/345

클린 아키텍처의 장점

• 유지보수성 증가 -비즈니스 로직과 구현 세부사항이 분리되어, 한 계층의 변경이 다른 계층에 영향을 최소화 -> 데이터베이스를 변경해도 유스케이스와 엔티티는 영향을 받지 않음.
• 확장성 향상
  • 새로운 기능이나 기술 스택을 추가하거나 교체하는 것이 용이
• 테스트 용이성
  • 비즈니스 로직이 UI나 데이터베이스와 독립적이므로, 테스트가 쉽고 빠름
  • 단위 테스트 작성 시 Mocking을 통해 외부 의존성을 최소화
• 재사용성 증가
  • 엔티티와 유스케이스는 특정 애플리케이션에 종속되지 않으므로, 여러 프로젝트에서 재사용 가능
• 기술 독립성
  • 특정 프레임워크나 도구에 종속되지 않으므로, 기술 스택 변경이 자유로움

클린 아키텍처의 단점

• 초기 설계 비용이 높고 숙련된 개발자가 아니라면 구조를 이해하고 적용하는 데 시간이 필요하다.

참고자료

https://doosicee.tistory.com/entry/Architecture-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80 https://velog.io/@kyeun95/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-MVP-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80 https://velog.io/@kyeun95/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-MVVM-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80 https://velog.io/@toma/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%B0%A8%EC%9D%B4%EC%A0%90 https://meetup.nhncloud.com/posts/345 https://medium.com/@justfaceit/clean-architecture%EB%8A%94-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EA%B0%9C%EB%B0%9C%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%84%EC%99%80%EC%A3%BC%EB%8A%94%EA%B0%80-1-%EA%B2%BD%EA%B3%84%EC%84%A0-%EA%B3%84%EC%B8%B5%EC%9D%84-%EC%A0%95%EC%9D%98%ED%95%B4%EC%A4%80%EB%8B%A4-b77496744616

용어 정리

• 비즈니스 로직 : 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성·표시·저장·변경하는 부분
• ViewModel에서의 데이터바인딩 : ViewModel에 있는 데이터가 변경되면 이 변경 사항이 자동으로 View에 반영되고, 반대로 View에서 사용자가 입력한 데이터가 ViewModel에 자동으로 반영되는 것
• 테스트 커버리지 : 시스템 및 소프트웨어에 대해 충분히 테스트가 되었는지를 나타내는 정도
• DTO(Data Transfer Object, 데이터 전송 객체) : 프로세스 간에 데이터를 전달하는 객체
• 의존성 역전
  • 의존성 역전 원칙은 객체지향 프로그래밍에서 고수준 모듈이 저수준 모듈의 구체적인 구현에 의존하지 않고, 추상적인 인터페이스에 의존하도록 설계하는 원칙입니다. 쉽게 말해, 상위 계층이 하위 계층에 의존하는 것이 아니라, 둘 다 추상적인 개념에 의존하도록 만드는 것입니다.
• 왜 의존성 역전을 하는가?
• 유연성 증가*: 시스템의 특정 부분을 변경해야 할 때, 다른 부분에 미치는 영향을 최소화할 수 있습니다.
• 테스트 용이성 향상*: 의존성이 적은 모듈은 독립적으로 테스트하기 쉽습니다.
• 재사용성 증가*: 추상적인 인터페이스에 의존하기 때문에, 다양한 구체적인 구현체와 함께 사용할 수 있습니다.
• 확장성 증가*: 새로운 기능을 추가하거나 기존 기능을 변경하기 쉽습니다.

The singleton pattern is one of the creational design patterns that is used to limit the instances of a class to one. That means with the Singleton pattern, only one instance of a class exists in the whole project with global access. Singleton is a creational design pattern that lets you ensure that a class has only one instance while providing a global access point to this instance.

Singleton Pattern은 객체의 인스턴스가 오직 1개만 생성되는 패턴으로 생성자가 여러 차례 호출되어도 실제로 생성되는 객체는 하나이고 맨 처음에 생성된 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 return한다.

Kotlin에서 구현하기

public class Singleton {

    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }

    public void say() {
        System.out.println("hi, there");
    }
}

Singleton Pattern의 기본적인 구현 방법으로 유의해야할 점은 다음과 같다.

• 외부에서 추가적인 객체 생성을 막기 위해 해당 클래스 생성자가 private인지 확인해야한다.
• 클래스 내부에 getInstance() 함수를 선언하여 외부로 객체를 반환할 때 이미 생성된 instance를 반환한다.

다른 방법으로는 companion object를 사용하는 방법이 있다.

class EventManager private constructor() {
    companion object{
        private val instance = EventManager()

        fun sharedInstance(): EventManager {
            return instance
        }
    }
}

먼저 companion object는 클래스 내부의 자바의 static과 비슷한 역할을 수행한다고 볼 수 있다. (물론 정확하게 분류하면 companion object는 객체이며 하나의 클래스에는 오직 하나의 companion object만 존재할 수 있는 등 엄연히 다르다.)

• private constructor()를 통해 외부에서 직접 인스턴스를 생성할 수 없다.
• EventManager 클래스 내부에 companion object가 있기 때문에, sharedInstance() 메서드에 EventManager.sharedInstance()와 같이 직접 접근할 수 있다.
• EventManage의 유일한 인스턴스가 companion object 내부에서 생성되어 이 변수는 private이므로 외부에서는 접근할 수 없다.

여기서 보다 더 안전하게 Singleton Pattern을 구현하고자 한다면 Singleton 인스턴스를 @Votaile로 표시하면 된다.

Volatile

@Volatile은 변수에 대한 스레드 간 일관성을 보장하기 위해 사용되는 키워드로 주로 멀티스레드 환경에서 특정 변수에 여러 스레드가 동시에 접근할 때, 각 스레드가 항상 최신의 값을 읽도록 강제하는 역할을 한다.

class Singleton private constructor() {

    companion object {

        @Volatile private var instance: Singleton? = null

        fun getInstance() =
            instance ?: synchronized(this) { 
                instance ?: Singleton().also { instance = it }
            }
    }
}

이 코드에서는 instance가 null일 경우 synchronized 블록에 진입하여 인스턴스를 생성한다. 이 블록은 한 번에 하나의 스레드만 진입할 수 있어, 여러 스레드가 동시에 인스턴스를 생성하는 것을 방지한다.

@Volotile로 표시했을 때는 다음과 같은 이점이 존재한다.

• 인스턴스에 대한 읽기 및 쓰기가 컴파일러나 프로세서에 의해 재정렬되지 않는다.
• 한 스레드에서 변경한 내용은 다른 스레드에서 즉시 볼 수 있다.

그렇다면 왜 Singleton Pattern을 사용할까?

1. 메모리 측면

• 한 개의 인스턴스만을 고정 메모리 영역에 생성하고 이후 외부에서 해당 객체에 접근할 때 메모리 낭비를 방지할 수 있다. 또한 이미 생성된 인스턴스를 활용하니 속도 측면에서도 이점이 있다고 볼 수 있다.

2. 데이터 공유가 쉽다

• Singleton 인스턴스는 전역으로 사용되는 인스턴스이기에 다른 클래스의 인스턴스들이 접근해서 사용할 수 있다. * 이떄 동시 접근 문제가 발생할 수 있어 @Volatile을 사용하거나 설계에 유념

Singleton Pattern의 단점

*1. 확장성 및 테스트 가능성 감소 *

• 글로벌 상태를 만들면 애플리케이션의 여러 구성 요소 간에 종속성과 결합을 도입하여 수정 또는 확장하기 어렵게 만들 수 있다. 또한 싱글톤 인스턴스는 자원을 공유하고 있기 때문에 테스트가 결정적으로 격리된 환경에서 수행되려면 매번 인스턴스의 상태를 초기화시켜주어 한다.

*2.복잡성 및 위험 증가 *

• 동시성 문제, private 생성자로 인한 자식 클래스 생성의 어려움 등 Singleton 클래스의 설계 및 구현에 주의가 필요하다. 제대로 수행하지 않으면 버그, 장기생존으로 인한 메모리 누수 또는 성능 병목 현상의 원인이 될 수 있다.

Adapter Pattern이란

Adapter Pattern은 기존 클래스의 인터페이스를 사용하고자 하는 다른 인터페이스로 변환해주어 호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 어댑터로서 사용되는 구조 패턴이다.

Adapter Pattern의 구성요소는

• Target : Client가 사용하고자 하는 인터페이스
• Adaptee : Client가 갖고 있는 인터페이스
• Adapter : Target 인터페이스를 구현하는 클래스
• Client : Target 인터페이스를 사용하고자 하는 주체

// A 인터페이스
interface AInterface {
    fun methodA()
}

// B 인터페이스
interface BInterface {
    fun methodB()
}

// A 인터페이스 구현 클래스
class AClass : AInterface {
    override fun methodA() {
        println("A 클래스의 methodA 호출")
    }
}

// 어댑터 클래스: B 인터페이스를 구현하면서 내부적으로 A 클래스를 사용
class AtoBAdapter(private val aClass: AClass) : BInterface {
    override fun methodB() {
        println("어댑터가 B 인터페이스의 methodB를 호출함.")
        aClass.methodA()  // A 클래스의 methodA를 호출하여 B 인터페이스에 맞게 동작
    }
}

// 클라이언트 코드: B 인터페이스를 기대
fun clientCode(bInterface: BInterface) {
    bInterface.methodB()
}

// 사용 예시
fun main() {
    val aClass = AClass()               // A 인터페이스를 구현하는 클래스
    val adapter = AtoBAdapter(aClass)    // AtoBAdapter로 AClass를 B 인터페이스에 맞게 변환

    clientCode(adapter)  // 클라이언트 코드는 B 인터페이스를 사용하는 것처럼 작동
}

AClass 객체를 AtoBAdapter로 감싸서 clientCode()에 전달함으로써 AClass를 BInterface처럼 사용할 수 있다.

Adapter Pattern은 호환 작업 방식에 따라 두 종류로 나뉜다.

• 객체 어댑터(Object Adatper)

• 클래스 어댑터(Class Adatper)

객체 어댑터(Object Adapter)

객체 어댑터는 Composition(합성)을 통해 구현한다.

객체 어댑터 방식은 기존 클래스(Adaptee)의 인스턴스를 Adapter 클래스 내부에 포함시켜 필요한 인터페이스(Target)를 변환해주는 방식으로 Adatper 클래스가 원래 클래스의 인스턴스를 포함하고, 해당 인스턴스의 메서드를 호출하여 인터페이스 간의 호환성을 제공하는 방식이다.

코드로 보면 이와 같은 형태이다.

interface TargetInterface {
    fun request() // 클라이언트가 호출하는 메서드
}

class AdapteeClass {
    fun specificRequest() {
        println("기존 클래스의 specificRequest 메서드 호출")
    }
}

class ObjectAdapter(private val adaptee: AdapteeClass) : TargetInterface {
    override fun request() {
        println("어댑터에서 request를 호출하여 specificRequest로 변환")
        adaptee.specificRequest() 
    }
}

fun clientCode(target: TargetInterface) {
    target.request()
}

fun main() {
    val adaptee = AdapteeClass()                
    val adapter = ObjectAdapter(adaptee)        

    clientCode(adapter) 
}

Client는 TargetInterface의 request()를 호출하지만 ObjectAdapter를 통해 AdapteeClass의 speicifcRequest()가 호출된다.

객체 어댑터(Object Adapter)의 장단점

장점

• 객체 어댑터는 합성을 통해 구현되는데 합성은 두 객체 사이의 의존성은 런타임에 해결하므로 런타임 중에 Adaptee가 결정되어 유연하다.

단점

• 어댑터마다 추가적인 객체가 생성되기 때문에, 빈번한 어댑터 사용이 필요한 경우 성능이 저하될 수 있다.

클래스 어댑터(Class Adapter)

클래스 어댑터는 상속(Inheritance)를 통해 구현된다. Adapter 클래스가 두 인터페이스를 모두 구현하고 기존 클래스의 기능을 상속하여 원하는 인터페이스로 변환하는 방식의 Adapter이다.

객체 어댑터와 다른 점은 Adaptee(Service)를 상속했기 때문에 따로 객체 구현없이 바로 코드 재사용이 가능하다는 것이다. 즉 클래스 어댑터는 클라이언트와 서비스 양쪽에서 행동들을 상속받기에 객체를 래핑할 필요가 없다. 그러나 클래스 어댑터는 다중 상속을 통해 구현되므로 다중 상속을 지원하지 않는 언어에서는 구현하기 용이하지 않다.

코드로 보면 이와같은 형태이다

interface BInterface {
    fun methodB()
}

open class AClass {
    fun methodA() {
        println("A 클래스의 methodA 호출")
    }
}

class ClassAdapter : AClass(), BInterface {
    override fun methodB() {
        println("어댑터에서 B 인터페이스의 methodB를 호출함")
        methodA()  
    }
}

fun clientCode(bInterface: BInterface) {
    bInterface.methodB()
}

fun main() {
    val adapter = ClassAdapter()  
    clientCode(adapter)           
}

Client는 ClassAdpater는 BInterface를 구현하고, AClass를 상속하여 methodB()를 override하여 상속받은 methodA()를 호출한다.

클래스 어댑터(Class Adapter)의 장단점

장점

• 어댑터가 Adaptee를 상속받기 때문에, 추가 객체 생성 없이 Adaptee의 메서드를 바로 호출할 수 있다.

단점

• Adaptee의 서브클래스이기 때문에 Adaptee의 서브클래스로서의 제한을 받는다.

Adapter Pattern의 장점

1.호환성 제공

• 기존 코드를 수정하지 않고도 클라이언트가 원하는 인터페이스로 변환하여 호환성을 제공한다.

2.재사용성 증가

• 외부 라이브러리나 기존 클래스 등 수정이 불가능한 코드도 클라이언트 요구에 맞게 변환하여 재사용할 수 잇다.

3.유연성 제공

• 어댑터를 이용해 여러 인터페이스를 서로 호환할 수 있으므로 코드의 유연성이 높아진다.

어댑터 패턴의 단점

복잡도 증가

• 간단한 경우에도 새로운 클래스를 추가하게 되어 코드의 복잡도가 증가할 수 있고 이에 따라 코드가 다소 난잡해질 경우 유지보수가 어려워진다.

Observer Pattern이란

옵서버 패턴(observer pattern)은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다. 발행/구독 모델로 알려져 있기도 하다.

• 위키피디아

즉 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 알림을 보내는 방식으로 상태 변화가 여러 객체에 전파되어야 하는 경우에 다른 객체의 상태 변화를 별도의 함수 호출 없이 즉각적으로 알 수 있어 이벤트에 대한 처리를 자주해야 하는 프로그램에서 매우 유용하다.

Observer Pattern의 구성

Observer Pattern의 구성요소는 패턴의 이름대로 객체를 Observe하는 Observer와 Observe되는 Subject로 이루어져있다. (Subject는 Publisher, Observable라고도 하고 Observer는 Subscriber라고도 한다.)

Subject

• Observe 되는 객체

Subject는 기본적으로 3개의 기능을 갖는다. 각각 attach, detach, notify로

• Observe하는 객체들을 등록하는 attach
• Observe하는 객체를 제거하는 detach
• Observe하는 객체들에게 상태변화를 알려주는 notify

의 기능을 수행한다.

코드로 보면

class Subject {
    private val observers = mutableListOf<Observer>()

    fun move() {
        println("Subject 이동")
           notify("Subject가 이동함")
    }

    fun stop() {
        println("Subject 정지")
        notify("Subject가 멈춤")
    }

    fun attach(observer: Observer) {
        observers.add(observer)
    }

    fun detach(observer: Observer) {
        observers.remove(observer)
    }

    fun notify(message: String) {
        observers.forEach { it.update(message) }
    }
}

중요한 점은 Subject의 상태가 변하면 notify()를 호출하여 Observer를 update해준다.

Observer

• Observe 하는 객체

Observer는 Subject가 notify한 내용을 통해 update하는 기능이 필요하다.

코드로 보면

interface Observer {
    fun update(message: String)
}

class ConcreteObserver(private val name: String) : Observer {
    override fun update(message: String) {
        println("$name received message: $message")
    }
}

Subject로 부터 notify된 내용을 토대로 update 메소드를 통해 상태 변화를 자동으로 수행할 수 있다.

참고로 Java에서는 Observer 클래스를 지원했었으나 멀티스레딩 환경에서의 비효율성과 유연성 문제로 Java 9부터 Deprecated 되었다.

발생할 수 있는 문제

그러나 여기서도 동시성에 대한 문제가 발생할 수 있다. 예를 들어 notify가 실행되는 동안 다른 스레드에서 새로운 Observer가 attach를 통해 등록되면, 이 새로운 Observer는 현재 진행 중인 알림 과정에 포함되지 않는 문제가 발생할 수 있다.

이것을 해결하는 다양한 방법들 중 하나는 lock을 이용하는 것이다.

Lock은 스레드가 공유 자원에 접근할 때, 하나의 스레드만 접근하도록 잠금(lock)을 걸어 데이터 일관성을 보장하는 도구

어느 한 메소드가 실행중이라면 다른 메소드를 실행하지 못하도록 lock을 걸어주는 것이다.

import java.util.concurrent.locks.ReentrantLock

class Subject {
    private val observers = mutableListOf<Observer>()
    private val lock = ReentrantLock()

    fun attach(observer: Observer) {
        lock.lock()
        try {
            observers.add(observer)
        } finally {
            lock.unlock()
        }
    }

    fun detach(observer: Observer) {
        lock.lock()
        try {
            observers.remove(observer)
        } finally {
            lock.unlock()
        }
    }

    fun notify(message: String) {
        val snapshot = lock.withLock { observers.toList() }
        for (observer in snapshot) {
            observer.update(message)
        }
    }
}

interface Observer {
    fun update(message: String)
}

class ConcreteObserver(private val name: String) : Observer {
    override fun update(message: String) {
        println("$name received message: $message")
    }
}

fun main() {
    val subject = Subject()
    val observer1 = ConcreteObserver("Observer 1")
    val observer2 = ConcreteObserver("Observer 2")

    subject.attach(observer1)
    subject.attach(observer2)
    subject.notify("New Update!")
}

위 코드에서는 notify, attach, detach 메소드에서 lock을 사용하여 동시에 Observer가 추가되거나 제거되는 상황을 방지하고 notify 메소드에서는 Observer 목록을 스냅샷으로 복사하여, 알림을 보내는 도중에 목록이 변경되는 문제를 방지한다.

그 외에는 @Synchronized 블록을 사용하는 방법도 있다.

class Subject {
    private val observers = mutableListOf<Observer>()

    @Synchronized
    fun attach(observer: Observer) {
        observers.add(observer)
    }

    @Synchronized
    fun detach(observer: Observer) {
        observers.remove(observer)
    }

    @Synchronized
    fun notify(message: String) {
        // Snapshot을 만들어 동시성 문제 방지
        val snapshot = observers.toList()
        for (observer in snapshot) {
            observer.update(message)
        }
    }
}

Observer Pattern의 장점

1.느슨한 결합

• Subject와 Observer 간의 의존성을 줄여준다. Subject가 변경되더라도 Observer를 직접 수정할 필요가 없다.

2.확장성

• 새로운 Observer를 쉽게 추가할 수 있다. 즉, 발행자의 코드를 변경하지 않고도 새 구독자 클래스를 도입할 수 있어 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계할 수 있는 개방 폐쇄 원칙을 준수한다.

Observer Pattern의 단점

1.메모리 누수 가능성

• Observer 등록 해제(Detach)를 제대로 관리하지 않으면 메모리 누수가 발생할 수 있다.

2.알림 순서 보장 어려움

• 다수의 Observeer가 있을 경우 알림의 순서를 보장하기 어려워 이에 따른 추가 구현이 필요하다.

참고자료

Singleton

https://medium.com/@ZahraHeydari/singleton-pattern-in-kotlin-b09380c53b14 https://velog.io/@seongwon97/%EC%8B%B1%EA%B8%80%ED%86%A4Singleton-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80 https://tecoble.techcourse.co.kr/post/2020-11-07-singleton/ https://onlyfor-me-blog.tistory.com/441

Adatper

https://jusungpark.tistory.com/22 https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%96%B4%EB%8C%91%ED%84%B0Adaptor-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90 https://refactoring.guru/ko/design-patterns/adapter https://velog.io/@haero_kim/%EC%9A%B0%EB%A6%AC%EB%8A%94-%EC%9D%B4%EB%AF%B8-%EC%96%B4%EB%8C%91%ED%84%B0-%ED%8C%A8%ED%84%B4%EC%9D%84-%EC%95%8C%EA%B3%A0-%EC%9E%88%EB%8B%A4

Observer

https://pjh3749.tistory.com/266 https://ko.wikipedia.org/wiki/%EC%98%B5%EC%84%9C%EB%B2%84_%ED%8C%A8%ED%84%B4 https://velog.io/@hanna2100/%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-2.-%EC%98%B5%EC%A0%80%EB%B2%84-%ED%8C%A8%ED%84%B4-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%98%88%EC%A0%9C-observer-pattern https://refactoring.guru/design-patterns/observer

추상 클래스와 인터페이스에 대해 알아보기 전에 먼저 상속에 대해 알아보자

상속

상속은 기존 클래스의 특성과 기능을 새로운 클래스가 물려받는 것으로 코드의 재사용성을 높이고, 유사한 기능을 가진 클래스들을 효과적으로 관리할 수 있다는 장점이 있다.

그중 기존 클래스를 슈퍼클래스, 기존 클래스를 상속받는 클래스를 서브클래스라고 한다.

코틀린에서 클래스는 기본적으로 final으로 만약 해당 클래스를 상속받고 싶다면 open을 붙여줘야 햔다.

open X	open O

마찬가지로 코틀린의 메소드도 final이 기본값이어서 서브클래스에서 메소드를 재정의하는 override를 하고 싶다면 open을 붙여줘야 한다.

매개변수화된 생성자를 사용한 상속

open class Person(val name : String){
    open fun eat(){
        println("$name eat rice")
    }
}

class Student : Person("Kim")

서브클래스를 생성할 때 슈퍼클래스의 매개변수화된 생성자를 사용하려면 서브클래스 정의할 때 입력한다. 만약 미리 정의하지 않고 서브클래스를 생성할 때 서브클래스에서 매개변수로 받고 그것을 슈퍼클래스로 넘겨주고자 한다면

open class Person(val name : String){
    open fun eat(){
        println("$name eat rice")
    }
}

class Student(name : String) : Person(name)

fun main(){
    val man = Student("Kim")
    man.eat()
}

위와 같이 서브클래스의 파라미터로 받은 값을 다시 슈퍼클래스로 넘겨주면 된다.

여기서 알아야할 것은 오직 한 개의 클래스만을 상속할 수 있다는 것이다.

그렇다면 언제 어떻게 사용될지 몰라 메소드 내부를 미리 정의하지 않거나 여러 개의 클래스를 상속받고 싶다면 어떻게 해야할까?

그 해답이 바로 추상 클래스 와 인터페이스 이다.

추상 클래스(Abstract Class)

추상 클래스는 말 그대로 추상적인 클래스로 아직 명확하게 정의되지 않은 클래스이다.

추상클래스는 일반 클래스와 달리 open을 사용하지 않아도 되지만 abstract를 클래스와 메소드에 붙여주어야 한다.

앞서 말했듯 아직 명확하게 정의되지 않은 클래스이기 때문에 추상 클래스를 직접 선언하여 인스턴스를 생성할 수 없다. 또한 추상 클래스 내부의 abstract가 붙은 추상 메소드들은 반드시 상속받은 서브클래스에서 정의가 되어야 한다. (그렇지 않다면 위처럼 에러가 발생한다)

그러나 서브클래스에서 추상 클래스의 추상 메소드를 정의하지 않고도 사용할 수 있는 방법이 있다! 바로 object를 사용하는 것이다. 이번에 공부하면서 처음 알게된 것인데 object를 사용하면 추상메소드를 정의하지 않고도 바로 사용할 수 있다. 이렇게

abstract class Person{
    abstract fun eat()
}

fun main(){
    val man = object : Person(){
        override fun eat() {
            println("쿰척쿰척")
        }
    }
}

추상 클래스는 일정한 기본 특성을 공유하지만, 일부 기능을 명시적으로 정의하도록 강제하고 싶을 때 유용하게 사용할 수 있다.

인터페이스(Interface)

인터페이스는 추상클래스처럼 인터페이스를 직접 선언하여 인스턴스를 생성할 수 없다.

interface Human {
    fun walk()
    fun eat(){println("GOOD")}
}

class Male : Human{
    override fun walk(){
        println("저벅저벅")
    }
}

그러나 추상 클래스와는 다르게 abstract를 사용하지 않고 일반 클래스와도 다르게 open을 사용하지 않고도 override할 수 있다.

또한 클래스와 다르게 다중 상속이 가능하다는 장점이 있다

interface A {
    fun foo() { print("A") }
    fun bar()
}

interface B {
    fun foo() { print("B") }
    fun bar() { print("bar") }
}

class C : A {
    override fun bar() { print("bar") }
}

class D : A, B {
    override fun foo() {
        super<A>.foo()
        super<B>.foo()
    }

    override fun bar() {
        super<B>.bar()
    }
}

하지만 인터페이스는 추상 클래스와 비슷하지만 차이점은 상태를 저장할 수 없다. 위와 같이 값을 저장하면 에러가 발생한다. 이것도 이번에 공부하며 새롭게 알게된 것인데 여기서 또다시 인터페이스에 값을 저장할 수 있는 방법이 있다!

interface Person {
    val name: String get() = "Kim"
}

class Male:Person{

}

fun main(){
    val man = Male()
    println(man.name)
}

이때는 무조건 val로 선언해야한다는 제약이 있긴하지만 위와 같이 get(), 게터로 구현이 가능하다!

일반 상속 대신 추상 클래스와 인터페이스를 사용하는 이유

1.유연성 -인터페이스를 통해 다중 상속이 가능하므로, 특정 클래스가 여러 동작을 가질 수 있게 할 수 있다.

2.강제성 -추상 클래스와 인터페이스는 구현을 강제할 수 있어, 특정 메소드가 반드시 필요하다는 것을 보장한다.

3.유지보수성 -추상 클래스와 인터페이스를 사용하면 코드가 더 명확해지고 유지보수가 쉬워지고 코드의 재사용성이 높아진다.

참고자료

https://play.kotlinlang.org/byExample/01_introduction/07_Inheritance https://kotlinlang.org/docs/interfaces.html#resolving-overriding-conflicts https://velog.io/@k906506/Kotlin-%EC%B6%94%EC%83%81-%ED%81%B4%EB%9E%98%EC%8A%A4-VS-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4

실력을 기르자는 생각으로 지원했던 네이버 부스트캠프의 챌린지 과정이 끝났다.

지원 동기

3학년이 될 때까지 별다른 프로젝트 경험도 없고 그렇다고 기본기가 탄탄하지도 않았었기에 방학 동안 실력을 기르자는 생각으로 냅다 지원하게 되었고 커리큘럼을 보았을 때 내가 부족한 부분을 채울 수 있겠다 생각해서 지원하게 되었다.

이번 부스트캠프 챌린지 과정은 전공 수업에서 배웠으나 내 것을 온전히 만들지 못 했던 것들을 소화하는 기간이었다고 생각한다.

챌린지 과정

챌린지는 매일 다른 CS 지식을 기반으로 하는 미션이 나오고 그 다음 날 피어 세션에서 서로의 코드를 리뷰하고 피드백을 하는 시간을 가졌는데 다른 사람과 개발에 대해서 대화를 나눠본 적도 없고 누군가의 앞에서 내 코드를 발표한 적도 없어서 굉장히 새로운 경험이었다.

첫째날 미션을 했을 때 굉장히 쉬웠어서 "아 챌린지도 할만 하겠구나"라는 생각을 했었는데 바로 다음 날부터 그 주의 미션을 1개도 성공하지 못 했었다....

부스트캠프에서 강조한 부분은 성장이었다. 미션을 얼마나 구현하기 보다는 그날의 미션에서 제시하는 CS지식을 학습하고 온전히 자신의 언어로 정리하는 것을 중요시했고 다른 캠퍼들과 정보 공유를 굉장히 장려하였다.

문제는 나는 매일 미션 하는 것도 겨우겨우 했고 못한 날도 굉장히 많았다. 그러다보니 학습한 내용을 바로바로 써먹고 다시 코드를 짜는 것을 반복하여 정작 내가 배운 내용을 정리하지 않았고 정보 공유에도 소홀히하게 되었다.

아는 게 없다보니 알려줄 정보도 없고 또한 내 미션하기 바빠서 다른 거 할 여유가 없었다...ㅋㅋ 내가 더 열심히 했었다면이라는 생각이 조금 남는다.

3차 코딩 테스트

3차 코딩 테스트는 기존 챌린지 과정에서 배웠던 내용을 기반으로 나왔고 시간이 빠듯했지만 어떻게든 전부 풀 수 있었다. 이때까지만 해도 멤버십 가능성이 있겠다고 생각했는데....

수료 후기

멤버십에서는 아쉽게도 선정되지 못 했다.. 어떻게 보면 당연한 결과같기도 하다. 부스트캠프에서 강조한 학습이 내가 학습이 했다 하더라도 그것을 보여줄 그리고 내가 얼만큼 이해했는지를 알 수 있는 학습 정리가 미흡했는데 어떻게 알겠나 변명아닌 변명은 챌린지 과정 기간이 공모전 기간과 겹쳐서 3주차에는 거의 제대로 한 날도 드물었던 것... 또한 다른 캠퍼들과의 정보 공유 참여도 거의 안 했었어서 이러한 소극적인 참여가 아쉬웠던 것 같다.

그래도 나에게 굉장히 도움이 많이된 과정이었다. 알기만 했던 개념들을 실제로 구현해보면서 보다 이해할 수 있었고 몰랐던 개념들도 알게 되면서 기본기가 보다 탄탄해진 것 같다.

앞으로..

이렇게 배운 CS 지식으로 이를 온전히 내것으로 만들기 위해 개인 프로젝트를 통해 안드로이드에 적용해보는 시간을 가져야 할 것 같다. MVVM, Hilt.. 배울 게 너무도 많다

냅다 실력을 기르고자 공모전과 네부캠을 같이 해봤는데 내 실력으로 두 가지를 모두 잡기에는 무리였나보다 멤버십이 되지 않았으니 얌전히 학교를 다니라는 뜻으로 알고 학교나 열심히 다녀야겠다.

안드로이드 아키텍쳐는 크게 4가지로 분류할 수 있다

• MVC
• MVP
• MVVM
• MVI

MVC

Model View Controller로 구성되는 아키텍쳐 패턴으로 웹에서 주로 사용되던 패턴이었다. 문제점은 안드로이드에서는 Activity나 Fragment가 View와 Controller 역할을 동시에 수행하는 경우가 많다. 즉 의존성이 강하여 테스트에 용이하지 않고 유지보수가 어렵다 또한 UI 로직이 Controller에 집중되어 복잡한 UI 환경에서는 Controller가 지나치게 비대해지는 문제가 존재했다. 이를 개선하고자 MVP 패턴이 등장하였다.

MVP

Model View Presenter로 구성되는 아키텍쳐 패턴으로 MVC의 문제점을 보완하고자 View와 Model사이에 Presenter라는 중재자를 두어서 사용자의 입력을 View에서 처리하고 그에 따라 Model을 업데이트하며 Model의 데이터를 View에 전달하여 UI를 업데이트한다. View와 Model이 서로 의존하지 않게 되었으나 여전히 View와 Presenter 사이의 강한 의존성이 존재하였다.

이 의존성을 보다 줄이기 위해 등장한 패턴이 MVVM이다.

MVI 패턴은 별도의 글로 공부해보거나 이후 추가해야겠다.

MVVM이란?

Model View ViewModel로 구성되는 아키첵텍쳐 패턴으로 UI 및 비 UI 코드를 분리하기 위한 UI 아키텍처 디자인 패턴이다.

왜 MVVM을 사용할까?

• 팀 단위의 큰 프로젝트에서의 작업 용이
• 의존성을 낮추어 테스트 용이
• 유지보수 용이

또한 MVVM은 상태의 유지를 도와준다는 이점이 존재한다.

View에 해당하는 MainActivity에서 Model을 다룬다면 화면 회전 등과 같은 과정에서 데이터의 온전함을 보장할 수 없지만 MVVM은 상태가 유지될 수 있도록 해준다.

ViewModel은 View의 존재를 모른다, 즉 MVVM에서는 ViewModel에서 UI를 조작하지 않는다. 그렇기에 ViewModel은 유지하면서 View만 교체하여 테스트해볼 수도 있고 다른 View에서도 사용하여 코드 재사용성을 높일 수 있다.

val 변수명 =  remember { mutableStateOf()}

를 사용하지만 by를 사용하면

var 변수명 by remember { mutableStateOf()}

로 사용할 수 있고 이렇게 by를 사용하면 state의 value를 가져와서 사용하는 것이 아닌 state 그 자체가 값이기에 변수명.value가 아닌 변수명을 바로 사용함으로써 값을 가져올 수 있다.

그러나 이 경우에는 val로 선언하는 것이 아닌 var로 선언해야 값을 변경해줄 수 있다.

장점 반응성이 좋아 속도가 더 빠름, 더 편리 Kotlin에 직접 코드 작성 가능

Flutter도 위젯(Widget)으로 똑같은 개념 사용

Remember와 Mutable State

Composable의 state를 유지하고 업데이트하는 데에는 2가지 개념이 필요하다. 1.Remember funcion 2.Mutable state property delegate

Remember function

Jetpack compose에서 지속적이고 기억되는 state를 만들기 위해 사용 Composable이 recomposition되었을 때에도 state를 유지할 수 있도록 해줌 매초 여러번 일어나는 화면의 새로고침인 composable의 재생산에도 작동

Mutable state

1.Composable이 새로 렌더링되었을 때에도 데이터가 보존되는 recompostion을 통과할 때에도 변하지 않는 state를 만드는 경우 2.값을 바꿨을 때 state값을 업데이트하는 경우