当AI开始读源码，调Bug这件事彻底变了

曾经的我："这个网上搜不到，我真解决不了"，现在的我："Cursor，你快把这几万行的源码读完找到Bug，不然我就要退订你了😎！"。

一、问题起点：为什么 RecyclerView 总是多加载一页？

有一天在调试性能时，我发现一个奇怪的问题：

RecyclerView 首次渲染总是会「多加载一页视图」，导致首屏加载明显变慢。

直觉告诉我问题出在布局逻辑上，可能在源码中存在某种预布局的逻辑，但是网上搜索、问AI都没能找到原因。直觉告诉我读源码是最好的解决方案，但是让我这种喜欢看博文"二手学习"的人去读源码，简直要了我的老命。于是我决定 ------ 让 AI 来帮我读。

二、让 AI 读源码：准备源码环境

我先下载了源码：

方法1：在 Android Studio 中 Ctrl + 左键 点击 RecyclerView
方法2：AOSP 源码仓库 Github源码仓库
方法3：Android Code Search 在线查看

然后，我把 LinearLayoutManager.java、RecyclerView.java 这些核心文件加载进 AI 工具（Cursor），提出了第一个问题：

"为什么 RecyclerView 会多布局一页？有没有控制预加载空间的变量？"

三、AI 的推理：锁定 `mExtraFillSpace`

AI "思考"一番很快就定位到一个关键变量：

java 复制代码

int remainingSpace = layoutState.mAvailable + layoutState.mExtraFillSpace;

AI 告诉我：

remainingSpace 决定了当前布局还要绘制多少像素区域。

它由 mAvailable（当前可用空间） + mExtraFillSpace（额外填充空间）组成。后者的存在可能导致多绘制一页。

AI 接着自动展开搜索：

查看 mExtraFillSpace 的定义；
追踪它的赋值位置；
分析它在 onLayoutChildren()、updateLayoutState()、layoutForPredictiveAnimations() 中的变化。

我都不用手动翻文件，只需读 AI 生成的分析摘要：

四、AI 的源码结论（自动整理）

java 复制代码

/**
 * mExtraFillSpace 用于预布局不可见的 items。
 * 当存在目标滚动位置（如 smoothScrollToPosition）时，
 * calculateExtraLayoutSpace 会返回整个屏幕高度。
 */

简而言之：

当 RecyclerView 有目标滚动位置时（例如调用了 smoothScrollToPosition），系统会提前布局整页的额外 items，保证滚动时不闪烁。

于是我去全局搜索项目代码，果然发现了一行：

kotlin 复制代码

recyclerView.smoothScrollToPosition(0)

------ 而且是在每次刷新数据后调用的。

五、验证与解决

为了验证 AI 的结论，我在相应的位置加上断点进行调试：

java 复制代码

Log.d("RV", "extraFillSpace = " + layoutState.mExtraFillSpace);

结果验证了：布局中 mExtraFillSpace 的确等于整个屏幕高度。

移除那行平滑滚动代码后，首次渲染时间立刻下降。

最终结论：

smoothScrollToPosition(0) 会触发额外的预布局逻辑，导致 RecyclerView 预加载一整页不可见 View。

六、AI + 源码阅读的力量

过去，定位这种问题要靠断点、日志、阅读成千上万行代码，并整理源码调用逻辑。现在，只需给AI一句指令：

"帮我查查 RecyclerView 为什么会多加载一页。"

AI 就能：

自动定位相关代码，梳理相关的逻辑
展示定义、赋值、调用链，找到可疑代码
甚至解释背后的设计意图

我只需要验证结论并落地修复。

这是一种创世纪的 Debug 模式，AI时代，甚至不需要人来阅读源码，只需要将源码交给AI，成千上万行的代码，AI只需要几秒钟就能读完并定位到相关逻辑。

七、附：AI对话截图

仅使用免费版cursor

AI的思考过程
AI的结论

当AI开始读源码，调Bug这件事彻底变了