Android Java：代码为何被调用两次？Handler与线程问题

这种情况我之前开发时也碰到过，明明只希望触发一次的完成逻辑，结果Log.d打印了两遍——确实挺闹心的。你猜测条件位置可能有误是个不错的方向，咱们来拆解可能的原因和对应的解决方案：

一、最常见的原因：判断逻辑处于重复触发的回调中 #

如果你的if(diggingStatus==100)是放在进度更新的回调方法里（比如类似onProgressChanged或者自定义的进度监听），那很可能是这个回调被调用了两次，而两次的diggingStatus都是100。比如：

• 数据源重复发送了100的状态值
• UI刷新机制导致回调被额外触发一次

解决办法：加一个“执行标记”来控制单次触发
你可以新增一个布尔变量，用来标记完成逻辑是否已经执行过，确保即使状态重复触发，代码也只会跑一次：

// 类成员变量，初始为false
private boolean hasDiggingCompleted = false;

// 假设这是你的进度监听方法
public void onDiggingStatusUpdated(int diggingStatus) {
    // 同时判断状态和标记位
    if (diggingStatus == 100 && !hasDiggingCompleted) {
        // 先标记为已执行，避免重复触发
        hasDiggingCompleted = true;
        Log.d("DiggingTag", "挖掘完成！");
        // 这里放你需要执行的其他完成逻辑
    }
}

二、检查diggingStatus的赋值逻辑 #

有没有可能在代码的多个地方，重复把diggingStatus设置为100？比如在异步任务的回调、定时器或者其他逻辑分支里，不小心多次执行了diggingStatus = 100，导致条件被触发两次。

解决办法：追踪赋值源头
你可以给diggingStatus的赋值代码加Log，看看哪些地方触发了它变为100，是否有重复赋值的情况：

// 每次赋值时打印日志，追踪调用来源
diggingStatus = 100;
Log.d("StatusSetTag", "diggingStatus被设置为100，调用来源：" + Thread.currentThread().getStackTrace()[2]);

这样能快速定位到重复赋值的位置，调整逻辑避免重复设置。

三、排查组件生命周期导致的重复监听 #

如果你的逻辑是在Activity、Fragment这类有生命周期的组件里，还要注意是不是组件重建（比如屏幕旋转、配置变化）导致监听被重复注册了——旧的组件实例没被销毁，新的实例又注册了一次，导致两次触发完成逻辑。

解决办法：在生命周期钩子中清理监听
比如在Activity的onDestroy方法里，移除进度监听的注册：

@Override
protected void onDestroy() {
    super.onDestroy();
    // 移除你的进度监听，避免内存泄漏和重复触发
    diggingManager.removeDiggingStatusListener(this);
}

快速排查步骤总结 #

1. 先在if(diggingStatus==100)的前一行加Log，看看这个判断所在的方法被执行了多少次，以及每次的diggingStatus值
2. 优先尝试添加布尔标记位，快速解决重复执行的问题
3. 追踪diggingStatus的赋值源头，看是否有重复设置的情况
4. 检查组件生命周期，确保监听不会被重复注册

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