# HarmonyOS 5.0+ 应用退后台资源还在跑怎么办：ApplicationContext 监听和恢复补偿怎么拆

做 HarmonyOS 应用时，前后台切换很容易被写错。最常见的现象是：用户已经把应用切到后台了，页面里的轮询、动画、播放器进度、定位刷新还在继续跑；等用户再切回来，页面又突然补一堆请求，甚至出现重复监听。

这个问题不能只靠 aboutToAppear 和 aboutToDisappear 解决。它们看的是组件或页面自己的出现和消失，不等于整个应用进入前台或后台。官方 FAQ 在 2026-06-26 更新的说明里也把这个边界讲得很明确：组件只能感知自身生命周期；如果要监听应用前后台，需要使用 ApplicationContext 的 applicationStateChange，或者在 UIAbility 生命周期里维护全局状态，再让页面订阅这个状态。

下面按排查顺序拆：问题怎么复现，为什么页面生命周期会误判，ApplicationContext 方案怎么写，AppStorage 分发怎么做，回到前台时为什么还要做一次恢复补偿。


## 一、问题怎么复现

先做一个很真实的页面：页面顶部有搜索框，中间是列表，底部有一个统计区域。为了让数据看起来及时，页面每隔 15 秒刷新一次。用户切到后台后，这个刷新应该停掉；用户回到前台后，如果离开时间太久，再补一次刷新。

如果直接把逻辑写进页面生命周期，代码大概会变成这样：

    @Component
    struct SearchPage {
      private timer: number = -1;

      aboutToAppear() {
        this.startTimer();
      }

      aboutToDisappear() {
        this.stopTimer();
      }

      private startTimer() {
        // 每 15 秒刷新一次列表。
      }

      private stopTimer() {
        // 停止刷新。
      }

      build() {
        Column() {
          Text("搜索页")
        }
      }
    }

这段代码只适合页面级资源，不适合应用级前后台。因为页面消失可能只是跳到了详情页，应用还在前台；页面没销毁也可能应用已经被切到后台。把这两件事混在一起，后面就容易出现“该停的时候没停，该恢复的时候又恢复太多次”。

## 二、先把应用状态收口

我更推荐把应用前后台状态放到一个中心里，只注册一次 ApplicationContext 监听。这样页面不需要到处写应用级监听，也不容易重复注册。

    export class AppForegroundCenter {
      private static foreground: boolean = true;
      private static listeners: Array<(value: boolean) => void> = [];

      static setup(context: common.UIAbilityContext) {
        const appContext = context.getApplicationContext();
        appContext.on("applicationStateChange", (state) => {
          const nextForeground = state === "foreground";
          AppForegroundCenter.update(nextForeground);
        });
      }

      static onChange(listener: (value: boolean) => void): number {
        this.listeners.push(listener);
        listener(this.foreground);
        return this.listeners.length - 1;
      }

      static off(index: number) {
        if (index >= 0 && index < this.listeners.length) {
          this.listeners[index] = () => {};
        }
      }

      private static update(value: boolean) {
        if (this.foreground === value) {
          return;
        }
        this.foreground = value;
        this.listeners.forEach((listener) => listener(value));
      }
    }

这个中心只做一件事：把应用前后台状态变成一个稳定的事件源。它不关心页面里有什么列表、播放器、定位或者下载任务。页面收到状态后，再决定自己要暂停什么、恢复什么。

## 三、案例一：轮询任务后台必须停

第一个案例是列表轮询。后台继续轮询没有意义，还会增加电量和网络消耗。

    @Component
    struct PollingListPanel {
      @State foreground: boolean = true;
      @State lastRefreshTime: number = 0;
      private listenerId: number = -1;
      private timer: number = -1;

      aboutToAppear() {
        this.listenerId = AppForegroundCenter.onChange((value: boolean) => {
          this.foreground = value;
          if (value) {
            this.resumePolling();
          } else {
            this.pausePolling();
          }
        });
      }

      aboutToDisappear() {
        AppForegroundCenter.off(this.listenerId);
        this.pausePolling();
      }

      private resumePolling() {
        this.refreshIfExpired();
        this.startTimer();
      }

      private refreshIfExpired() {
        const expired = Date.now() - this.lastRefreshTime > 30 * 1000;
        if (!expired) {
          return;
        }
        this.lastRefreshTime = Date.now();
        // 这里发起一次列表刷新。
      }

      private startTimer() {
        if (this.timer >= 0) {
          return;
        }
        // 这里启动定时刷新。
      }

      private pausePolling() {
        if (this.timer < 0) {
          return;
        }
        // 这里停止定时器。
        this.timer = -1;
      }

      build() {
        Column({ space: 8 }) {
          Text(this.foreground ? "前台刷新" : "后台暂停")
          Text("最近刷新时间：" + this.lastRefreshTime)
        }
      }
    }

这里有两个细节：回前台时不是无脑刷新，而是判断数据是否过期；启动定时器前先判断 timer，避免重复启动。很多重复请求就是少了这两个判断。

## 四、案例二：播放器和动画不能只停一半

第二个案例是播放器页面。播放器常见的问题是音频暂停了，但波形动画还在跑；或者动画停了，播放状态没保存，回前台后进度显示不对。

    class PlaySnapshot {
      playing: boolean = false;
      position: number = 0;
      updatedAt: number = 0;
    }

    @Component
    struct PlayerPanel {
      @State foreground: boolean = true;
      @State snapshot: PlaySnapshot = new PlaySnapshot();
      private listenerId: number = -1;

      aboutToAppear() {
        this.listenerId = AppForegroundCenter.onChange((value: boolean) => {
          this.foreground = value;
          if (value) {
            this.restorePlayerView();
          } else {
            this.freezePlayerView();
          }
        });
      }

      aboutToDisappear() {
        AppForegroundCenter.off(this.listenerId);
        this.freezePlayerView();
      }

      private freezePlayerView() {
        this.snapshot.position = this.readCurrentPosition();
        this.snapshot.updatedAt = Date.now();
        this.stopWaveAnimation();
      }

      private restorePlayerView() {
        this.syncProgress(this.snapshot.position);
        if (this.snapshot.playing) {
          this.startWaveAnimation();
        }
      }

      private readCurrentPosition(): number {
        return this.snapshot.position;
      }

      private syncProgress(position: number) {}
      private stopWaveAnimation() {}
      private startWaveAnimation() {}

      build() {
        Column({ space: 8 }) {
          Text(this.foreground ? "播放器可见" : "播放器后台")
          Text("播放进度：" + this.snapshot.position)
        }
      }
    }

这个案例说明：前后台切换不是一个 boolean 判断就结束了。进入后台时要保存现场，释放 UI 动画；回前台时要恢复 UI，而不是让组件自己猜状态。

## 五、ApplicationContext 和 AppStorage 怎么配合

如果项目里很多页面都要感知前后台，可以把 foreground 写进 AppStorage。这样页面只订阅一个统一状态，不用每个页面都直接接 ApplicationContext。

    export class AppStateBridge {
      static setup(context: common.UIAbilityContext) {
        const appContext = context.getApplicationContext();
        appContext.on("applicationStateChange", (state) => {
          const foreground = state === "foreground";
          AppStorage.setOrCreate("appForeground", foreground);
          AppStorage.setOrCreate("appForegroundChangedAt", Date.now());
        });
      }
    }

页面侧只读 AppStorage：

    @Component
    struct ForegroundAwarePanel {
      @StorageLink("appForeground") foreground: boolean = true;
      @StorageLink("appForegroundChangedAt") changedAt: number = 0;

      build() {
        Column() {
          Text(this.foreground ? "前台" : "后台")
          Text("变化时间：" + this.changedAt)
        }
      }
    }

这个方案的好处是页面不会直接依赖 ApplicationContext，后续也容易替换实现。比如有的模块只关心前后台，有的模块还关心网络状态、电量状态、登录状态，都可以用类似方式收口。

## 六、验证清单

我会按下面这几项验：

- 切到后台后，轮询、动画、定位这类资源确实停掉；
- 回到前台后，只补一次必要数据，不连续发多次请求；
- 页面之间来回跳转，监听数量不会越来越多；
- 页面销毁时也会释放页面自己的资源，不依赖应用后台事件兜底；
- 长时间后台后再回来，页面不会先显示旧状态再突然跳变。

这个清单比单纯看页面能不能跑更重要。前后台问题一般不是马上崩，而是越用越慢、请求越来越多、状态越来越乱。

## 七、最后怎么避免再踩坑

我的建议是把三条边界写清楚。

第一，应用前后台只在应用层监听，不要散落到每个页面。第二，页面生命周期只处理页面自己的资源，不要拿它代替应用前后台。第三，回前台时不要只恢复定时器，还要按过期时间补数据，避免用户看到旧状态。

这样写的好处很直接：资源释放有统一入口，页面恢复有明确规则，后面排查性能问题时也知道从哪里开始看。