1. 屏幕解锁后数据翻倍一个 AsyncTaskLoader 的重复加载现场Android Loader 是官方在 Fragment/Activity 体系里提供的一套异步数据加载框架AsyncTaskLoader是它最常见的实现基类适合做数据库查询、列表拉取、配置读取这类「加载一次、多处复用」的场景。它最大的卖点是跟着宿主生命周期走配置变更旋转屏幕、切换语言时不用重新查一遍数据。但很多人第一次用AsyncTaskLoader都会踩到同一个坑手机息屏再解锁数据莫名其妙加载了两遍列表里出现重复项日志里loadInBackground()被调了两次。这个问题特别隐蔽因为它在模拟器上不一定复现只有真机息屏解锁才稳定触发。你盯着代码看半天onCreateLoader只调了一次LoaderManager也没重新初始化可数据就是重复了。根因不在调用方而在 Loader 自己的生命周期息屏时 Loader 会走onStopLoading()解锁时走onStartLoading()如果你在onStartLoading()里无脑forceLoad()那每次解锁都会重新拉一次数据。这篇就围绕「Android Loader 屏幕解锁后重复加载」这个具体场景把 Loader 生命周期讲透给出可直接复制的LoaderManager初始化与去重配置片段再用解锁前后的日志对比帮你验证修复效果。适合已经用过AsyncTaskLoader、但被重复回调折磨过的 Android 开发者。核心检索词就三个Android Loader、AsyncTaskLoader、屏幕解锁重复加载。先说结论问题出在onStartLoading()没有做状态判断以及onStopLoading()没有取消正在进行的加载。官方CursorLoader源码里这两块写得非常克制照着抄基本不会错。下面从生命周期切入一步步定位并消除重复加载。2. 先搞懂 Loader 生命周期为什么息屏解锁会触发 onStartLoading要理解重复加载得先接受一个事实Loader 的启动和停止跟宿主 Activity/Fragment 的可见性不是一回事它跟的是 LoaderManager 的 start/stop 状态。当屏幕关闭时系统会让当前 Activity 进入 stopped 状态LoaderManager随之调用Loader.onStopLoading()屏幕解锁、Activity 回到前台LoaderManager又调用Loader.onStartLoading()。这一停一起就是重复加载的温床。完整的 Loader 生命周期回调大致是这样一条链路onCreateLoader()只在 LoaderManager 第一次需要这个 id 的 Loader 时调用一次负责 new 出实例。之后onStartLoading()会在每次 Loader 进入 started 状态时被调用——注意是「每次」包括息屏解锁、从后台切回、Fragment 重新 attach。onStopLoading()在 Loader 进入 stopped 状态时调用比如息屏、切后台。onReset()在 Loader 被销毁或需要重置时调用负责清理数据。deliverResult()负责把结果投递给回调loadInBackground()才是真正干活的地方。问题代码通常长这样static class CouponShopQueryLoader extends AsyncTaskLoaderListCouponStore { private int couponId; public CouponShopQueryLoader(Context context, int couponId) { super(context); this.couponId couponId; } Override protected void onStartLoading() { forceLoad(); // 每次 started 都强制加载解锁必重复 } Override public ListCouponStore loadInBackground() { return ds.queryShopByCoupon(couponId, pageNo, PAGE_SIZE); } }这段代码在onStartLoading()里直接forceLoad()等于告诉 Loader「不管有没有数据每次启动都重新查」。息屏时onStopLoading()没被重写正在跑的加载没被取消解锁时onStartLoading()又无条件forceLoad()于是第二次查询启动数据自然重复。正确的做法是引入一个缓存字段mData在onStartLoading()里判断有缓存就直接deliverResult(mData)投递旧数据只有缓存为空或内容发生变化时才forceLoad()。同时在onStopLoading()里cancelLoad()把没跑完的加载取消掉避免息屏期间还在后台空转。onReset()里把mData置空保证真正需要重置时不会拿到脏数据。这里有个关键方法takeContentChanged()它返回「自上次加载后内容是否变化过」的标志。配合ForceLoadContentObserver使用可以在数据源变化时精准触发重载而不是每次启动都重载。官方CursorLoader就是靠这套机制做到「该刷新时刷新不该刷新时复用」的。理解了这层你就明白为什么「严格遵守官方 demo」不是一句空话——CursorLoader的源码本身就是AsyncTaskLoader的最佳实践范本。下面给出可直接复制的完整配置。3. 可复制的去重配置LoaderManager 初始化与 AsyncTaskLoader 完整片段这一节给出一份可以直接抄进项目的完整实现。核心思路三句话缓存结果、按需加载、停止即取消。先看 Loader 本体这是去重的关键。static class CouponShopQueryLoader extends AsyncTaskLoaderListCouponStore { private ListCouponStore mData; private final int couponId; private final int pageNo; private static final int PAGE_SIZE 20; CouponShopQueryLoader(Context context, int couponId, int pageNo) { super(context); this.couponId couponId; this.pageNo pageNo; } Override public ListCouponStore loadInBackground() { // 只在真正需要时执行工作线程 mData ds.queryShopByCoupon(couponId, pageNo, PAGE_SIZE); return mData; } Override public void deliverResult(ListCouponStore data) { if (isReset()) { // Loader 已重置丢弃结果避免内存泄漏 return; } mData data; if (isStarted()) { super.deliverResult(data); } } Override protected void onStartLoading() { if (mData ! null) { // 有缓存先投递界面立刻有数据 deliverResult(mData); } if (takeContentChanged() || mData null) { // 内容变化或首次加载才真正拉取 forceLoad(); } } Override protected void onStopLoading() { // 息屏/切后台时取消未完成的加载防止解锁后重复 cancelLoad(); } Override public void onCanceled(ListCouponStore data) { super.onCanceled(data); // 加载被取消这里可做清理不要投递结果 } Override protected void onReset() { super.onReset(); onStopLoading(); mData null; } }几个点必须说清楚。onStartLoading()里先deliverResult(mData)再判断是否forceLoad()顺序不能反否则界面会先空一下再出数据。takeContentChanged()依赖内容观察者如果你没注册ForceLoadContentObserver它默认返回 false那mData ! null时就不会重载这正是我们想要的去重效果。onStopLoading()里的cancelLoad()是消除重复加载的直接手段——息屏时把在跑的加载掐掉解锁时mData若已有值就直接复用。接下来是 LoaderManager 的初始化。在 Activity 或 Fragment 里这样写public class CouponShopActivity extends AppCompatActivity implements LoaderManager.LoaderCallbacksListCouponStore { private static final int LOADER_ID_COUPON_SHOP 1001; private CouponShopAdapter adapter; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_coupon_shop); adapter new CouponShopAdapter(this); // 用 initLoader已存在则复用不会重复创建 getSupportLoaderManager().initLoader( LOADER_ID_COUPON_SHOP, null, this); } NonNull Override public LoaderListCouponStore onCreateLoader(int id, Bundle args) { return new CouponShopQueryLoader(this, couponId, pageNo); } Override public void onLoadFinished(NonNull LoaderListCouponStore loader, ListCouponStore data) { // 先清空再填充避免重复项叠加 adapter.setData(data); } Override public void onLoaderReset(NonNull LoaderListCouponStore loader) { adapter.setData(null); } }注意initLoader和restartLoader的区别initLoader在 Loader 已存在时直接复用不会重新创建适合常规场景restartLoader会强制重建 Loader只在确实需要丢弃旧数据时用。很多人重复加载就是因为无脑用了restartLoader每次解锁都重建缓存全丢。如果你用 AndroidX把getSupportLoaderManager()换成getSupportLoaderManager()或LoaderManager.getInstance(this)即可API 一致。onLoadFinished里务必先清空适配器再 setData否则旧数据和新数据叠加看起来也像「重复加载」。4. 验证请求与成功结果解锁前后日志对比改完代码怎么确认真的修好了最直接的办法是打日志对比。在 Loader 的关键回调里加Log.d然后做一次「息屏—解锁」操作观察日志。修复前的日志大概是这样D/Loader: onCreateLoader id1001 D/Loader: onStartLoading D/Loader: loadInBackground start D/Loader: loadInBackground end, size20 D/Loader: onLoadFinished size20 // 息屏 D/Loader: onStopLoading // 解锁 D/Loader: onStartLoading D/Loader: loadInBackground start -- 重复加载 D/Loader: loadInBackground end, size20 D/Loader: onLoadFinished size20 -- 数据翻倍修复后的日志应该是D/Loader: onCreateLoader id1001 D/Loader: onStartLoading D/Loader: loadInBackground start D/Loader: loadInBackground end, size20 D/Loader: onLoadFinished size20 // 息屏 D/Loader: onStopLoading D/Loader: onCanceled // 解锁 D/Loader: onStartLoading D/Loader: deliverResult from cache, size20 -- 直接复用缓存 D/Loader: onLoadFinished size20 -- 数据不翻倍关键差异在解锁后修复前会再次出现loadInBackground start修复后只看到deliverResult from cacheloadInBackground不再被调用。这就是去重生效的铁证。验证时建议用真机模拟器的息屏行为有时不触发onStopLoading。操作步骤打开列表页确认数据正常按电源键息屏等 3 秒解锁回到应用观察日志和列表项数量。如果列表项数量保持不变、日志里没有第二次loadInBackground说明修复成功。还可以用adb logcat过滤标签命令如下adb logcat -s Loader:D这样只输出你关心的 Loader 日志解锁前后对比一目了然。如果条件允许再测一次旋转屏幕确认配置变更时也不会重复加载——正常情况下initLoader会复用 LoadermData缓存直接投递同样不会触发loadInBackground。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 之外的 Loader 报错虽然 Loader 本身不涉及网络鉴权但很多人在排查重复加载时会顺手接入远程数据源于是撞上一堆看似无关的报错。这里把几类高频错误和 Loader 场景对照说明避免你被带偏。第一类是java.lang.IllegalStateException: Fragment not attached to Activity。这通常发生在loadInBackground()里直接访问了 Activity 或 Fragment 的 UI 组件。记住loadInBackground()跑在工作线程只能碰数据层不能碰 UI。把 UI 操作挪到onLoadFinished()里。第二类是LoaderManager报Attempting to launch a loader before onCreate。这是初始化时机不对initLoader必须在onCreate或之后调用不能在构造函数里调。放到onCreate里最稳。第三类是数据重复但日志只显示一次loadInBackground。这种情况多半是onLoadFinished里没清空适配器旧数据和新数据叠加。检查adapter.setData()内部是否先clear()再addAll()。第四类是onCanceled之后仍然收到onLoadFinished。这是deliverResult里没判断isReset()和isStarted()导致的。按第 3 节的写法isReset()时直接 returnisStarted()才投递就能避免。如果你在 Loader 里做网络请求可能会遇到401 Unauthorized或local proxy failed这类报错。这类问题跟 Loader 生命周期无关属于鉴权和网络层。排查思路是先确认请求头里的鉴权信息是否正确再确认网络配置是否被系统代理拦截。reading choices这类报错通常出现在解析响应体时字段缺失检查数据模型和接口返回是否对齐。OAuth相关报错则要确认 token 是否过期、刷新逻辑是否在loadInBackground里正确执行。这里要提醒一句Loader 的loadInBackground里做网络请求时不要依赖 Activity 的 Context 做长生命周期操作用getContext().getApplicationContext()更安全。另外onStopLoading里cancelLoad()只是标记取消loadInBackground如果已经在跑需要自己检查isLoadInBackgroundCanceled()来提前退出否则取消不彻底。对照真实报错时先分清是生命周期问题还是数据层问题。生命周期问题看日志里onStartLoading/onStopLoading的调用次数数据层问题看loadInBackground的返回值和异常栈。两者分开排查效率高很多。6. 从 Loader 到稳定数据层把去重思路沉淀成习惯Loader 这套东西虽然现在有协程、Flow、Room 这些更现代的方案但存量项目里AsyncTaskLoader依然大量存在尤其是老电商、老工具类 App。把它的生命周期吃透不只是解决一个重复加载的 bug更是理解「异步加载如何跟界面生命周期对齐」这件事。我自己的经验是凡是涉及「加载一次、多处复用」的场景都要问三个问题数据有没有缓存启动时要不要判断缓存有效性停止时有没有取消在途任务这三个问题对应mData、takeContentChanged()、cancelLoad()答上来基本就不会重复加载。如果你在项目里需要统一管理模型调用、API Key 和编码 Agent 的配置可以借助 TaoToken 这类平台把鉴权和模型接入收敛到一处。它的 API 地址是 https://taotoken.net/api模型对话入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。长期做编码和 Agent 的可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。控制台在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite Claude Code 相关配置参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。官网入口 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。回到 Loader 本身最后再强调一个容易忽略的点onReset()里一定要调onStopLoading()并把mData置空。很多人只写了mData null忘了取消在途加载结果 Loader 被销毁后回调还在跑触发onLoadFinished时宿主已经没了轻则日志报错重则崩溃。官方CursorLoader的onReset就是先super.onReset()再onStopLoading()照抄不会错。把第 3 节那份 Loader 代码存成模板下次写AsyncTaskLoader直接改loadInBackground里的查询逻辑就行。息屏解锁重复加载这个问题从此不会再找上你。