Angular setTimeout 性能不佳

Question

我有一个组件，每次都需要使用不同的@input变量重新渲染，因为我在ngOnInit()中实现了一些逻辑。 我通过在父组件中使用以下方法来执行此操作，其中showSettings用于隐藏，然后在100ms延迟后显示组件（带有新输入）。

private _reloadSettings() {
    this.showSettings = false;
    let a = performance.now();
    setTimeout(() => {
         this.showSettings = true;
         console.log(performance.now() - a);
     }, 100);
    }

一切工作正常，除了重新渲染花费的时间比预期的要长，即它应该在 100 毫秒左右（或稍微多一点），但实际上我正在变得像8000ms到10000ms ，并且每次重新渲染都会变得最糟糕。

Answer 1

在您的应用程序的其他部分，您正在做太多的工作。

在这种情况下，我们无法解决您的问题。 我会 go 关于调查angular 变化检测。

除此之外，我将向您展示在您的代码库中要查找的一些内容：

变化检测

您可以从ChangeDetection.Default切换到ChangeDetection.OnPush 。 这可能会破坏您的应用程序的某些部分，但如果您修复这些问题，您将获得与setTimeout一样的所有应用程序范围的操作的巨大性能提升。

在上面的例子中，你正在监听 service observable，它可能是任何东西

泄露订阅

constructor(myService) {
  myService.data.subscribe(data => {
    this.array = data.array;
  });
}

上面的代码很糟糕，订阅永远不会被删除，这意味着浏览器无法从memory中删除组件，并且subscribe方法中的代码每次都会运行。 在这种情况下很好，但如果你要在内部进行一些计算，它可能会很快变坏。

您可以通过以下方式修复它：

1. 仅订阅首次发射。

myService.data.pipe(
  take(1),
).subscribe(data => {
  this.array = data.array;
});

2. 用管道的 observable 替换它。 这将使其保持反应性，但 angular 将

this.array$ = myService.data.pipe(
  map(data => data.array),
  // Uncomment next line, if the observable is used multiple time
  // shareReply({ ... }), // 
)

Answer 2

尝试使用 queueMicrotask 而不是 setTimeOut。

queueMicrotask(() => {
     this.showSettings = true;
     console.log(performance.now() - a);
 });

SetTimeout 是一个宏任务。 setTimeout 中提供的回调 function 将被加载到回调队列（又名 MacroTaskQueue）中。 它一直等到调用堆栈为空。

微任务也有类似的行为。 但是，微任务获得更高的优先级，因此它在宏任务队列之前运行。

在此处阅读更多信息