Angular中SwUpdate.available订阅应在何时何地取消？

Great question—let’s unpack this clearly, since handling subscriptions properly is key to avoiding memory leaks and unexpected behavior in Angular apps.

First: Do we need to worry about unsubscribing? #

Yes, but it depends entirely on where you’re subscribing:

• If you subscribe inside a component (like the snippet from Stephen’s video, assuming that constructor belongs to a component), you absolutely need to clean up the subscription when the component is destroyed. Here’s why: SwUpdate is a root-provided singleton service—it lives for the entire app’s lifecycle. If your component is destroyed (e.g., when navigating away from its route), the subscription callback will still hold a reference to the component instance, preventing it from being garbage collected. Over time, this leads to memory leaks that can slow down your app or cause weird leftover behavior (like snackbars popping up for components that no longer exist).
• If you subscribe inside a root-level service, you don’t need to unsubscribe. Root services are created once and exist for the app’s entire lifetime, so there’s no component instance to leak here—no cleanup is necessary.

When and where to unsubscribe? #

Option 1: Manual cleanup in ngOnDestroy #

Store the subscription as a component property, then unsubscribe explicitly when the component is destroyed:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { SwUpdate, UpdateAvailableEvent } from '@angular/service-worker';
import { MatSnackBar } from '@angular/material/snack-bar';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-update-notifier',
  templateUrl: './update-notifier.component.html'
})
export class UpdateNotifierComponent implements OnInit, OnDestroy {
  private updateSubscription?: Subscription;

  constructor(private update: SwUpdate, private snackbar: MatSnackBar) {}

  ngOnInit() {
    this.updateSubscription = this.update.available.subscribe((update: UpdateAvailableEvent) => {
      console.log('Update available:', update);
      this.snackbar.open('New app version ready!', 'Refresh');
    });
  }

  ngOnDestroy() {
    // Safely unsubscribe if the subscription exists
    this.updateSubscription?.unsubscribe();
  }
}

Option 2: Use the async pipe (no manual cleanup needed) #

The Angular async pipe automatically manages subscriptions for you—it subscribes when the component initializes and unsubscribes when it’s destroyed. This is my go-to approach for component-level subscriptions because it eliminates the need for manual cleanup:

import { Component } from '@angular/core';
import { SwUpdate, UpdateAvailableEvent } from '@angular/service-worker';
import { Observable } from 'rxjs';

@Component({
  selector: 'app-update-notifier',
  template: `
    <mat-snack-bar *ngIf="updateAvailable$ | async as update">
      New version {{update.currentVersion}} available! <button (click)="refreshApp()">Update</button>
    </mat-snack-bar>
  `
})
export class UpdateNotifierComponent {
  updateAvailable$: Observable<UpdateAvailableEvent>;

  constructor(private update: SwUpdate) {
    this.updateAvailable$ = this.update.available;
  }

  refreshApp() {
    window.location.reload();
  }
}

What about performance overhead? #

Forgotten component-level subscriptions don’t just waste memory—they can also lead to unnecessary callback executions for components that are no longer active. While a single unused subscription might not cause immediate issues, repeated component creation/destruction (e.g., navigating back and forth between routes) will accumulate unused references, gradually increasing memory usage and potentially making your app feel sluggish over time.

To sum up: Always clean up component-level subscriptions to SwUpdate.available—either manually in ngOnDestroy or via the async pipe. Root service subscriptions don’t need cleanup since they align with the app’s lifecycle.

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