Android Paging3库触发java.util.NoSuchElementException崩溃问题排查求助

这个NoSuchElementException是因为AndroidX Paging库的PageFetcherSnapshot.nextLoadKeyOrNull方法内部调用了Kotlin标准库的first()方法，但此时分页数据列表为空导致的。因为异常发生在Paging库内部的非主线程流处理环节，而不是你Adapter调用getItem(position)的时候，所以你在Adapter里加的try-catch根本捕获不到这个异常。

针对这个问题，我推荐从几个层面入手解决，按优先级排序：

1. 在PagingSource源头阻断空列表触发的加载逻辑 #

PagingSource是分页数据的源头，我们可以在这里控制分页加载的开关，避免空列表进入后续的加载键计算逻辑。修改你的PagingSource的load方法，当返回的数据为空时，把nextKey设为null，这样Paging库就不会尝试去获取下一页的加载键，自然也就不会走到调用first()的代码分支：

override suspend fun load(params: LoadParams<Int>): LoadResult<Int, YourDataModel> {
    return try {
        val currentPage = params.key ?: 1
        val apiResponse = yourApiService.fetchPageData(currentPage)
        val pageData = apiResponse.data ?: emptyList()

        // 核心判断：如果当前页数据为空，停止后续加载
        val nextPageKey = if (pageData.isNotEmpty() && pageData.size >= params.loadSize) {
            currentPage + 1
        } else {
            null // 空数据时不生成下一页键
        }

        LoadResult.Page(
            data = pageData,
            prevKey = if (currentPage > 1) currentPage - 1 else null,
            nextKey = nextPageKey
        )
    } catch (e: Exception) {
        LoadResult.Error(e)
    }
}

2. 在Pager.flow的流处理环节捕获异常 #

因为异常是在Flow的处理链路上抛出的，我们可以用Kotlin Flow的catch操作符直接拦截这个异常，避免它扩散导致崩溃，同时还能记录日志定位问题：

// 针对每个分页场景的Flow添加catch处理
Pager(
    config = PagingConfig(pageSize = 20),
    pagingSourceFactory = { YourPagingSource() }
).flow
    .catch { exception ->
        if (exception is NoSuchElementException) {
            // 记录异常日志，建议标记当前分页场景（比如"商品列表分页"）
            Timber.e(exception, "Paging crash: [商品列表场景] 空列表触发first()调用")
            // 发送空的PagingData，让Adapter正常接收，避免崩溃
            emit(PagingData.empty())
        } else {
            // 其他异常正常抛出
            throw exception
        }
    }
    .cachedIn(viewModelScope)
    .collect { pagingData ->
        yourAdapter.submitData(pagingData)
    }

这里建议给每个分页场景添加独特的日志标记，这样后续通过Crashlytics的日志就能快速定位是哪个场景出了问题。

3. 升级Paging库到最新稳定版 #

这个异常大概率是Paging库的一个已知bug，你可以检查一下当前使用的androidx.paging:paging-runtime版本，升级到最新的稳定版（比如3.2.1及以上），看看官方是否已经修复了这个空列表处理的问题。

4. 全局异常兜底（最后防线） #

如果上面的方法都无法彻底解决，可以在Application类中添加全局的非捕获异常处理器，作为最后一道防线，避免APP崩溃：

class YourApp : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread.setDefaultUncaughtExceptionHandler { thread, throwable ->
            if (throwable is NoSuchElementException && throwable.stackTrace.any {
                    it.className.startsWith("androidx.paging")
                }) {
                // 记录详细日志，包括线程信息、场景推测
                Timber.e(throwable, "Paging库空列表崩溃，线程：${thread.name}")
                // 这里可以自定义上报逻辑，比如标记分页场景
            } else {
                // 其他异常交给系统默认处理器
                Thread.getDefaultUncaughtExceptionHandler()?.uncaughtException(thread, throwable)
            }
        }
    }
}

• 给每个分页场景的PagingSource添加独特的日志标识，比如在load方法开头打印Timber.d("加载[XX列表]第$currentPage页")，这样当崩溃发生时，就能通过日志回溯是哪个列表触发的问题。
• 测试时模拟接口返回空列表的场景，复现异常，这样能更精准地定位代码中的逻辑漏洞。

内容的提问来源于stack exchange，提问作者Willey Hute