네이버 부스트캠프에서 그룹 프로젝트로 진행했던 포링(Porring)은 익명으로 사진을 공유하는 일종의 SNS 형태의 서비스다. 이 프로젝트를 디벨롭하면서 Room을 이용한 캐싱과 RemoteMediator 기반의 페이징 구조를 적용했다.

그 과정에서 HorizontalPager와 RemoteMediator를 함께 쓸 때 무한 스크롤 기능에서 데이터 요청이 반복되는 문제가 발생했고, 이를 해결하기 위해 Paging3의 동작 방식을 깊이 있게 살펴보았다.

💡 왜 Room캐싱을 선택했는가?

포링은 하나의 게시글이 여러 화면에서 동시에 보여질 수 있고, 사용자의 인터랙션(좋아요, 팔로우 등) 역시 모든 화면에 바로 반영되어야 한다.

처음에는 MainViewModel에서 데이터를 공유하고 필요한 곳에 파라미터로 넘겨주는 방식으로 구현했다. 하지만 화면이 늘어날수록 데이터 흐름 추적이 어려워지고, 로직 추가 될 때마다 연결된 모든 컴포넌트를 수정해야 하는 상황이 반복됐다.

그래서 공통 데이터를 캐싱하고 Repository를 통해 독립적으로 접근하는 구조로 바꾸기로 했다. 이미 Paging3를 사용 중이었기 때문에 RemoteMediator를 활용해 데이터를 Room에 캐싱하고 변경된 내용을 UI에 즉시 반영할 수 있는 안정적인 페이징 흐름을 만들어보고자 했다.

💡 Paging3의 기본 동작 방식 이해하기

일반적으로 Paging3는 다음과 같이 구성한다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
                
// PagingSource
class MyPagingSource() : PagingSource<String, PostContentModel>() {
	override suspend fun load(params: LoadParams<String>): LoadResult<String, PostContentModel> {
    	// 페이지에 따라서 데이터를 로드하는 로직 작성
    }
    
    override fun getRefreshKey(state: PagingState<String, PostContentModel>): String? {
    	// 기존 PagingState 기반으로 position 고정
    }
}


val pager = Pager(
    config = PagingConfig(pageSize = 20),
    pagingSourceFactory = { MyPagingSource() }
)

PagingSource인터페이스를 상속받아 페이지 상태에 따라 데이터를 로드하는 구현체를 작성한 뒤 해당 PagingSource를 생성하는 람다를 Pager에 전달한다.

▪ Pager → PageFetcher

                    kotlin
                    
                

                    1
2
3
4
5
6
7
                
public class Pager<Key : Any, Value : Any>(
    pagingSourceFactory: () -> PagingSource<Key, Value> // PagingSource생성을 람다로 전달받음
) {
    public val flow: Flow<PagingData<Value>> = PageFetcher(
        pagingSourceFactory = { pagingSourceFactory() } // 전달받은 람다를 PageFetcher에 그대로 전달
    ).flow
}

▪ PageFetcher 내부 PagingSource 생성

                    kotlin
                    
                

                    1
2
3
4
5
6
7
                
private suspend fun generateNewPagingSource(
    previousPagingSource: PagingSource<Key, Value>?
): PagingSource<Key, Value> {
    val pagingSource = pagingSourceFactory() // ← 여기서 생성됨
    ...
    return pagingSource
}

Pager는 전달받은 람다를 내부에서 PageFetcher에게 전달하고, PageFetcher는 이 람다를 호출하여 실제로 PagingSource를 생성한다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
                
// PagerFetcher.kt
	...
	GenerationInfo(
    	snapshot = PageFetcherSnapshot(
    	    initialKey = initialKey,
        	pagingSource = pagingSource, // 페이징 소스 전달.
        	config = config,
	        retryFlow = retryEvents.flow,
			remoteMediatorConnection = remoteMediatorAccessor,
        	jumpCallback = this@PageFetcher::refresh,
        	previousPagingState = previousPagingState,
		),
    	state = previousPagingState,
    	job = Job(),
    )
    ...
    
    
// PageFetcherSnapshot.kt
	...
	private suspend fun doInitialLoad() {
        stateHolder.withLock { state -> state.setLoading(REFRESH) }

        val params = loadParams(REFRESH, initialKey)

        log(DEBUG) { "Start REFRESH with loadKey $initialKey on $pagingSource" }

        when (val result = pagingSource.load(params)) { // 여기서 load()실행
        	...
        }
        ...
	}
    ...

이렇게 생성된 PagingSource는 다시 한 번 PageFetcherSnapshot으로 전달되어 페이징 상태에 맞는 요청을 수행하게 된다.

💡 Paging3 + Room 연동 시의 구조 변화

Room을 사용해서 페이징을 구성할 때도 기본 구조는 크게 다르지 않다. 다만 가장 큰 차이는 이전처럼 PagingSource를 직접 구현해서 넘기는 것이 아니라 Room DAO에서 제공하는 @Query 메서드가 내부적으로 PagingSource를 생성해준다는 점이다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
                
@Dao
interface PostDao {
    @Query("SELECT * FROM post ORDER BY createdAt DESC")
    fun getPosts(): PagingSource<Int, PostEntity>
}


val pager = Pager(
    config = PagingConfig(pageSize = 20),
    pagingSourceFactory = { postDao.getPosts() }
)

위와 같이 Dao를 구성하게 되면 getPosts() 함수를 실행할 때 Room이 자동으로 PagingSource를 생성해 준다. 이렇게 생성된 PagingSource를 직접 구현할때 처럼 Pager에 전달해 주면 된다.

❓ RemoteMediator가 필요한 이유

하지만 Room 기반 PagingSource는 서버에서 데이터를 불러오지 않고, 오로지 RoomDB에 저장된 로컬 데이터만을 기준으로 페이징을 수행한다. 이전처럼 서버와 연동할 로직을 작성한 곳이 없으니 당연하다.

Room으로 생성한 PagingSource에서 서버와 연동하기 위해서 RemoteMediator를 사용한다. RemoteMediator는 Room에서 생성된 PagingSource와 연동되어 네트워크에서 데이터를 받아오고 이를 Room에 저장해주는 중재자 역할을 한다.

▪ RemoteMediator

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
                
@OptIn(ExperimentalPagingApi::class)
class PostRemoteMediator(
    private val api: PostApi,           // 서버 API
    private val db: AppDatabase         // Room DB
) : RemoteMediator<Int, PostEntity>() {

    override suspend fun load(
        loadType: LoadType,
        state: PagingState<Int, PostEntity>
    ): MediatorResult {
    	return try {
        	// 데이터를 요청하고 Room에 저장하는 로직을 작성한다.
            
            // 마지막에는 페이징 종료 여부를 반환한다.
            MediatorResult.Success(endOfPaginationReached = ...)
        } catch (e: Exception) {
        	MediatorResult.Error(e) // 로드 실패시 에러를 반환.
        }
    }
}


val pager = Pager(
    config = PagingConfig(pageSize = 20),
    remoteMediator = PostRemoteMediator(), // RemoteMediator를 전달한다.
    pagingSourceFactory = { postDao.getPosts() }
)

기본적으로 PagingSource처럼 load() 함수를 오버라이드해 구현하지만 서버 데이터를 직접 반환하지 않고, 이를 Room에 저장한다. Paging3는 Room PagingSource를 통해 화면에 변경 된 데이터를 알아서 표시한다.

💡 HorizontalPager에서 발생한 문제

기존에 프로젝트 내부에서 페이징이 사용되고 있는 부분은 크게 2가지로 나눌 수 있다.

이미지들을 썸네일로 표시하는 화면에서 LazyVerticalStaggeredGrid

랜덤피드를 무한하게 제공하는 화면에서 HorizontalPager

LazyVerticalStaggeredGrid를 사용하는 화면에서는 별다른 문제가 없었지만,HorizontalPager를 사용하는 화면에서는 페이지가 앞뒤로 왔다 갔다 하거나, 스크롤 위치가 리셋되는 등 전체적인 상태가 매우 불안정했다.

로그를 하나하나 찍어보며 확인한 결과, RemoteMediator가 계속해서 데이터를 로드하고 있다는 사실을 알게 되었다.

❓ Paging3는 언제 데이터를 로드할까?

무한 로딩 현상의 원인을 파악하려면, 먼저 Paging3가 어떤 시점에 데이터를 로드하는지부터 이해할 필요가 있었다.

Pager는 config 파라미터로 PagingConfig 객체를 전달받는다. 이 PagingConfig를 통해 페이지 크기, 플레이스홀더 사용 여부, 초기 로딩 크기 등 여러 가지 옵션을 설정할 수 있다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
                
val pager = Pager(
    config = PagingConfig(
    	pageSize = 20,
        prefetchDistance = 10,
        enablePlaceholders = false,
		initialLoadSize = 60,
	),
    pagingSourceFactory = { MyPagingSource() }
)

이 중에서도 prefetchDistance는 현재 페이지에서 남은 아이템 수를 기준으로 다음 데이터를 언제 미리 로드할지를 결정하는 속성이다. 사용자가 페이지를 넘길 때 남은 아이템 수가 prefetchDistance 이하가 되면 Paging3는 이를 감지하고 다음 페이지 데이터를 미리 로드하게 된다.

❓ 왜 계속해서 로드를 할까?

Paging3가 언제 데이터를 로드하는지에 대해 이해했다면 이제 무한 로딩이 발생하는 직접적인 원인도 어느 정도 추측할 수 있다. 항상 남은 아이템 수가 prefetchDistance 이하가 되어 버려서, load()를 끊임없이 호출하고 있다는 것!

그렇다면 prefetchDistance는 어떻게 계산되는 걸까? PagingConfig를 추적해보자.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
                
// Pager.kt
	...
    public val flow: Flow<PagingData<Value>> = PageFetcher(
        pagingSourceFactory = if (
            pagingSourceFactory is SuspendingPagingSourceFactory<Key, Value>
        ) {
            pagingSourceFactory::create
        } else {
            {
                pagingSourceFactory()
            }
        },
        initialKey = initialKey,
        config = config, // PageFetcher로 전달!!
        remoteMediator = remoteMediator
    ).flow
    ...


// PageFetcher.kt
val flow: Flow<PagingData<Value>> = simpleChannelFlow {
				...
                GenerationInfo(
                    snapshot = PageFetcherSnapshot(
                        initialKey = initialKey,
                        pagingSource = pagingSource,
                        config = config, // PageFetcherSnapShot으로 전달!!
                        retryFlow = retryEvents.flow,
                        remoteMediatorConnection = remoteMediatorAccessor,
                        jumpCallback = this@PageFetcher::refresh,
                        previousPagingState = previousPagingState,
                    ),
                    state = previousPagingState,
                    job = Job(),
                )
                ...
}


// PagerFetcherSnapShot.kt
	...
    private fun PageFetcherSnapshotState<Key, Value>.nextLoadKeyOrNull(
        loadType: LoadType,
        generationId: Int,
        presentedItemsBeyondAnchor: Int
    ): Key? {
        if (generationId != generationId(loadType)) return null
        if (sourceLoadStates.get(loadType) is Error) return null

        if (presentedItemsBeyondAnchor >= config.prefetchDistance) return null // 여기서 사용된다.

        return if (loadType == PREPEND) {
            pages.first().prevKey
        } else {
            pages.last().nextKey
        }
    }
    ...

결과적으로 prefetchDistance는 데이터를 로드하는 PagerFetcherSnapShot내부까지 전달되어 presentedItemsBeyondAnchor값과 비교해 작거나 같아질 때 다음 데이터의 key값을 null로 반환시켜 로드를 중단하게 한다.

그렇다면 presentedItemsBeyondAnchor이 값이 데이터를 로드하기 위해 설정된 값보다 항상 작기 때문에 무한하게 로딩이 되고 있다는 것을 알 수 있다. 이제 presentedItemsBeyondAnchor의 값이 어떻게 계산되는지만 알면 문제를 해결할 수 있게 됐다.

nextLoadKeyOrNull()을 호출하고 있는 부분을 확인해 보면 presentedItemsBeyondAnchor로 어떤 값이 전달되고 있는지 확인이 가능하다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
                
// PagerFetcherSnapShot.kt
	...
    var loadKey: Key? = stateHolder.withLock { state ->
    	state.nextLoadKeyOrNull(
        	loadType,
            generationalHint.generationId,
            generationalHint.hint.presentedItemsBeyondAnchor(loadType) + itemsLoaded,
		)?.also { state.setLoading(loadType) }
	}
    ...
   
   
// ViewportHint.kt
	...
    
    /*
        Returns:
        Count of presented items between this hint, and either:
        the beginning of the list if loadType == PREPEND
        the end of the list if loadType == APPEND
    */
    
     internal fun presentedItemsBeyondAnchor(loadType: LoadType): Int = when (loadType) {
        LoadType.REFRESH -> throw IllegalArgumentException(
            "Cannot get presentedItems for loadType: REFRESH"
        )
        LoadType.PREPEND -> presentedItemsBefore
        LoadType.APPEND -> presentedItemsAfter
    }
	...

뭔지는 모르겠지만 일단 ViewportHint라는 클래스에 선언된 함수를 통해 loadType별로 아이템과 연관된 Int값을 가져오고 있다는 것을 알 수 있다. 그럼 itemsLoaded와 이 값이 합산되어 prefetchDistance와 비교 된다는 것이다.

presentedItemsBeyondAnchor함수 상단의 주석을 해석해보면 다음과 같다.

반환값:
이 힌트와 다음 중 하나 사이에 표시된(presented) 아이템의 개수:

loadType이 PREPEND인 경우, 리스트의 시작 지점

loadType이 APPEND인 경우, 리스트의 끝 지점

그리고 ViewportHint의 생성자 선언부를 보면 presentedItemsAfter에 대해 다음과 같은 설명이 적혀있다.

이 힌트 이후에 표시된 로드된 아이템의 개수. 이 힌트 부터 마지막으로 로드된 아이템까지의 거리로 계산됨.: presenterSize - anchorPosition - placeholdersAfter - 1

결과적으로 Paging3는 내부적으로 anchorPosition과 현재 로드된 아이템의 개수를 끝이 얼마나 남았는지 계산한 뒤 이를 prefetchDistance와 비교해 더 작을경우 계속해 데이터를 로드하게 되는것이다.

이를 통해 우리는 anchorPosition이 계속해 prefetchDistance보다 아이템의 마지막으로 설정되어 있어 로드가 발생한다고 의심할 수 있다.

💡 anchorPosition을 찾아서

그렇다면 대체 anchorPositon이 뭐길래 이런 문제를 발생시키는 걸까? anchorPosition은 생각보다 쉽게 찾을 수 있는데, RemoteMediator나 PagingSource를 구현하며 전달되는 파라미터를 잘 살펴보면 PagingState라는 값을 확인할 수 있다.

anchorPosition은 바로 이 PagingState내부에 존재하는 값이다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
                
public class PagingState<Key : Any, Value : Any> constructor(
	...
    /**
     * Most recently accessed index in the list, including placeholders.
     *
     * `null` if no access in the [PagingData] has been made yet. E.g., if this snapshot was
     * generated before or during the first load.
     */
    public val anchorPosition: Int?,
    ...

anchorPosition의 설명은 다음과 같다.

플레이스홀더를 포함하여, 리스트에서 가장 최근에 접근된 인덱스.
아직 PagingData에서 접근이 이루어진 적이 없다면 null.

결국 Paging3는 리스트에서 가장 최근에 접근된 인덱스를 기준으로 페이지의 마지막(혹은 가장 처음)까지의 카운트를 prefetchDistance와 비교해 데이터를 로드한 다는 것을 알 수 있다.

그럼 여기서 문제상황이 일어난 HorizontalPager와 문제가 없는 LazyVerticalStaggeredGrid는 아이템에 접근하는 시점이 달라 anchorPosition이 달라진다는 것이 된다.

❓ 접근 시점을 알아보자

그렇다면 다시 역추적을 위해 UI에서 페이징 아이템에 접근하는 시점을 알아보자.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
                
val pagingItems = viewModel.posts.collectAsLazyPagingItems()

...

LazyVerticalStaggeredGrid(...) {
	items(pagingItems.itemCount) { index ->
    	val pagingItem = pagingItems[index] // 여기서 get()으로 아이템에 접근!
        ...
	}
}

컴포즈에서는 Flow로 반환되는 PagingData를 collect해 LazyPagingItems로 변환한 뒤 각 아이템에 접근한다. 아이템을 get()하는 순간 해당 위치를 anchorPosition으로 전달한다고 의심해 볼 수 있다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
                
// LazyPagingItems.kt
    var itemSnapshotList by mutableStateOf(
        pagingDataPresenter.snapshot()
    )
    
    ...
    
    operator fun get(index: Int): T? {
        pagingDataPresenter[index] // this registers the value load
        return itemSnapshotList[index]
    }


// PagingDataPresenter.kt
	...
    @MainThread
    public operator fun get(@IntRange(from = 0) index: Int): T? {
        inGetItem.update { true }
        lastAccessedIndexUnfulfilled = true
        lastAccessedIndex = index

        log(VERBOSE) { "Accessing item index[$index]" }
        hintReceiver?.accessHint(pageStore.accessHintForPresenterIndex(index))
        return pageStore.get(index).also { inGetItem.update { false } }
    }
    ...

우리가 LazyPagingItems의 아이템을 get()하게 되면 pagingDataPresenter의 스냅샷에서 아이템을 반환하며, 호출된 값을 등록하게 된다.

PagingDataPresenter의 get()함수를 확인해보면 마지막 접근 인덱스가 등록되며 hintReciver의 accessHint라는 함수를 통해 어딘가로 인덱스 값이 전달 되고 있는 것을 확인 할 수 있다.

Hint

익숙한 단어가 보인다. 이전에 PagerFetcherSnapShot를 확인하며 hint에서부터 아이템 끝과의 거리를 prefetchDistance와 비교한다는 것을 확인했다. 이제 acessHint로 전달된 인덱스가 과연 PagerFetcherSnapShot로 전달되고 있는지 확인만 해보면 연결이 완성된다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
                
// PageFetcher.kt
	...
    inner class PagerHintReceiver<Key : Any, Value : Any> constructor(
        @get:VisibleForTesting
        internal val pageFetcherSnapshot: PageFetcherSnapshot<Key, Value>,
    ) : HintReceiver {

        override fun accessHint(viewportHint: ViewportHint) {
            pageFetcherSnapshot.accessHint(viewportHint)
        }
    }
	...
    
    
// PageFetcherSnapshot.kt
	...
    fun accessHint(viewportHint: ViewportHint) {
        hintHandler.processHint(viewportHint)
    }
    
	suspend fun currentPagingState(): PagingState<Key, Value> {
        return stateHolder.withLock { state ->
            state.currentPagingState(hintHandler.lastAccessHint)
        }
    }
    ...

LazyPagingItems의 HintReciver는 Pager내부에서 생성된 PageFetcher와 연결되고, PageFetchr에서는 다시 전달받은 인덱스를 PageFetcherSnapshot에 전달한다.

PageFetcherSnapshot에서는 전달받은 인덱스를 HintHandler에 저장하고 이후 현재 페이징 상태를 불러올때 이 값을 사용하게 된다.

LazyVerticalStaggeredGrid는 LazyList계열의 컴포저블이고, HorizontalPager는 Pager계열의 컴포저블이다. 두 컴포저블의 동작이 어떻게 다르길래 HorizontalPager에서만 문제가 발생하는 걸까?

우선 LazyVerticalStaggeredGrid의 내부를 살펴보자.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
                
// LazyVerticalStaggeredGrid.kt
@Composable
fun LazyVerticalStaggeredGrid(...) {
    LazyStaggeredGrid(...)
}


// LazyStaggeredGrid.kt
@OptIn(ExperimentalFoundationApi::class)
@Composable
internal fun LazyStaggeredGrid(...) {
    LazyLayout(
    	...
        measurePolicy = measurePolicy
    )
}


// LazyLayout.kt
@ExperimentalFoundationApi
@Composable
fun LazyLayout(
	...	
    measurePolicy: LazyLayoutMeasureScope.(Constraints) -> MeasureResult
) {
    	...
        SubcomposeLayout(
        	...
            remember(itemContentFactory, measurePolicy) {
                { constraints ->
                    with(
                        LazyLayoutMeasureScopeImpl(
                            itemContentFactory,
                            this
                        )
                    ) {
                        measurePolicy(constraints)
                    }
                }
            }
        )
    	...
}

Lazy계열의 컴포저블은 모두 내부적으로 LazyLaout을 사용해 데이터를 화면에 표시한다. 이때 measurePolicy라는 값을 사용해 화면에 표시할 컴포저블의 개수를 계산하게 되고, 각 컴포저블이 전달받은 아이템에 접근해 화면을 그리게 된다.

보통 LazyList를 사용할때 item()이나 items()를 사용해 아이템을 선언하는 게 바로 이런 이유 때문이다. 선언된 아이템들은 itemProvider로 전달되어 화면에 접근하는 아이템의 인덱스를 각각 관리하게 해준다.

따라서 마지막에 표시된 아이템의 인덱스가 Hint로 전달되어 anchorPosition이 되게 된다.

이제 HorizontalPager를 살펴보자

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
                
// Pager.kt
@Composable
fun HorizontalPager(...) {
    Pager(...)
}


// LazyLaoutPager.kt
@OptIn(ExperimentalFoundationApi::class)
@Composable
internal fun Pager(...) {
    LazyLayout(...)
}

Pager계열의 컴포저블은 내부적으로 모두 Pager컴포저블을 사용하는데, 이 Pager는 Lazy계열의 컴포저블과 같이 LazyLayout을 사용하고 있다. 근데 왜 HorizontalPager는 LazyVerticalStaggeredGrid와 동작이 달랐던 걸까?

이유는 전달되는 measurePolicy를 추적해 보면 알 수있다. LazyVerticalStaggeredGrid에서는 화면에 표시되는 뷰포트가 items()로 공급되어 measurePolicy에 데이터에 접근할 아이템의 카운트를 계산해줬다.

                    kotlin
                    
                

                    1
2
3
4
5
                

HorizontalPager(...) { page: Int ->
	val post = posts[page] ?: return@HorizontalPager
    ...
}

하지만 Pager계열의 컴포저블에서는 item()이나 items()메서드 없이 바로 데이터에 접근한다.

그렇다면 HorizontalPager는 화면에 아이템이 표시되는 개수가 따로 공급되지 않는데 어떻게 접근을 감지하는걸까? 내부를 살펴보자.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
                
// LazyLaoutPager.kt
@OptIn(ExperimentalFoundationApi::class)
@Composable
internal fun Pager(...) {
    val pagerItemProvider = rememberPagerItemProviderLambda(
        state = state,
        pageContent = pageContent,
        key = key
    ) { state.pageCount }
    
	val measurePolicy = rememberPagerMeasurePolicy(
    	...
        itemProviderLambda = pagerItemProvider,
        pageCount = { state.pageCount },
     	...
    )
}

// PagerMeasurePolicy.kt
@OptIn(ExperimentalFoundationApi::class)
@Composable
internal fun rememberPagerMeasurePolicy(...) {
	...
    val measureResult =
            measurePager(
            	...
                pageCount = pageCount(),
                pagerItemProvider = itemProvider,
                ...
            )
}

Pager에서는 사용자가 직접 아이템을 공급하지 않고 내부에서 알아서 아이템을 공급하며, 공급되는 페이지의 아이템의 카운트 만큼 measure를 진행한다.

즉, 전달받은 페이지의 모든 아이템에 접근이 발생하는 것이다. 그러니 초기화 시 HorizontalPager의 anchorPosition은 전달받은 아이템의 마지막 인덱스가 되게 된다.

💡 RemoteMediator 연동 시에만 문제가 발생하는 이유

이제 우리는 LazyList컴포저블과 Pager컴포저블이 초기화 될 때 아이템에 접근하는 범위가 다르고, 그래서 anchorPosition이 다르게 지정된다는 것을 알게 되었다. 렇다면 이전에 PagingSource를 직접 구현했을때는 왜 아무런 문제가 없었는데, RemoteMediator를 연동하니 문제가 발생했을까?

이 문제를 해결하기 위해서는 PagingData의 특성에 대해 알 필요가 있다. 기본적으로 PagingData는 현재 페이지의 데이터에 대한 State(상태)를 나타낸다. 따라서 현재 페이지의 상태가 바뀌게 된다면 새로운 데이터를 전달해 상태를 업데이트해야한다.

                    kotlin
                    
                

                    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
                
// PageFetcher.kt
	private suspend fun generateNewPagingSource(
        previousPagingSource: PagingSource<Key, Value>?
    ): PagingSource<Key, Value> {
        val pagingSource = pagingSourceFactory()
        
        ...
        
        check(pagingSource !== previousPagingSource) {...}
		
        ...
        
        pagingSource.registerInvalidatedCallback(::invalidate)
        previousPagingSource?.unregisterInvalidatedCallback(::invalidate)
        previousPagingSource?.invalidate() // Note: Invalidate is idempotent.

		return pagingSource
    }

PageFetcher의 내부를 확인해보면 이전과 페이징 소스의 값이 달라지게 되면, invalidate()를
호출하며 새로운 페이징 데이터를 반환하는 것을 확인 할 수 있다. 한마디로 데이터의 변동이 생기면 새로운 PagingData가 emit된다는 것이다.

이제 모든 퍼즐 조각이 완성되었다. 우리가 PagingSource를 사용할 경우 서버에서 데이터를 요청해 받아와 이를 PagingData에 반영한다. 직접 서버 데이터를 요청하지 않는 한, 기존 PagingData는 변하지 않기 때문에 invalidate되지 않는다.

즉, 초기화 없이 데이터가 유지된다.

하지만 RemoteMediator를 사용하는 경우에는 PagingSource를 Room에서 관리한다. 로컬DB의 데이터가 추가되고, 변경되는게 얼마든지 가능해진다.

실제로 RemoteMediator에서 prefechDitance가 다가오면 데이터를 받아 로컬DB에 추가한다. 그렇게되면 로컬DB의 데이터의 상태가 변하게 되고, invalidate()가 호출되며 새로운 PagingData가 반환된다.

💡 그래서 HorizontalPager에서는 오류가 발생한다.

앞서 알아보았듯 초기화시점에서 Pager 컴포저블은 초기화 시점에 모든 아이템에 접근하기 때문에 가장 마지막 아이템이 anchorPosition으로 지정된다.

그리고 anchorPosition이 마지막 아이템으로 지정되기 때문에 prefetchDistance가 아무리 작아도 RemoteMediator에는 APPEND 요청이 전달되게 된다.

그러면 로컬DB에는 새로운 아이템이 추가되고 다시 새로운 PagingData가 반환된다....

이렇게 무한 반복의 사이클이 완성된다!

💡 마치며

현재 해당 기능은 StateFlow를 사용해 UI레벨에서 HorizontalPager의 현재 페이지를 직접 RemoteMediator에 전달해 해당 페이지를 기준으로 설정한 prefectchDistance와 비교해 페이징을 하는 방식을 사용해 동작을 구현해 놓은 상태다.

하지만 그렇다보니 load()함수의 진행자체를 막고 직접 컨트롤 하는 상태가 되어서 근본적으로 RemoteMediator를 사용하는 것에 대한 의문점이 생겼다.

추후에 한번 더 로직을 확인하며 Paging3라이브러리 기능을 활용해 Pager컴포저블에서 무한 스크롤 기능을 구현해 볼 필요가 있을 것 같다.

[Paging3] RemoteMediator와 HorizontalPager를 함께 사용하기

박봉팔