使用在Angular中调用requestAnimationFrame的库
我正在使用库（ https://echarts.apache.org.org/v4 /en/api.html#echarts ）内部调用request> requestAnimationFrame的内部。当我处于空闲状态时 - 我看到稳定的4-5％CPU使用情况，RAM不断增长（导致GC），我看到这些requestAnimationFrame被调用的函数被调用，这些功能被Angular劫持。
我认为，如果库可以调用本机requestAnimationFrame，我可以减少CPU使用率，但是有什么方法可以在不更改库的情况下进行操作？即使我可以在this.ngzone.ngzone.runoutsideangular - requestAnimationFrame callback调用requestanimationframe中，即使我可以在中进行初始调用。 /code>，所以我们又回到了角度。
因此，问题是1）我可以在那里使用本机requestAnimationFrame 2）我会以这种方式赢得某种完美吗？
I'm using a library (https://echarts.apache.org/v4/en/api.html#echarts) inside Angular that internally calls requestAnimationFrame. When I have chart in idle state - I see stable 4-5% CPU usage and RAM keeps growing (leading to GC) and I see these requestAnimationFrame scheduled functions being called, which are hijacked by Angular.
I think I could reduce CPU usage if library could call native requestAnimationFrame, but is there any way to do it without changing the library? Even if I can do initial call inside this.ngZone.runOutsideAngular - requestAnimationFrame callback calls requestAnimationFrame and this time it's not inside runOutsideAngular, so we're back to Angular.
So the questions are 1) can I use native requestAnimationFrame there and 2) will I win some perf this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我刚刚偶然发现了这个确切的问题。我正在使用 ECharts 5，所以也许它与 4 不同，但我对
runOutsideAngular不与requestAnimationFrame一起工作有相同的期望，但 这个 GitHub 讨论 确信我尝试了一下，结果成功了。我没有使用 ngx-echarts，但这是同样的问题，也是同样的解决方案。我没有太多时间来实际深入研究并弄清楚最小值到底是什么，但我只是疯狂地用
NgZone.runOutsideAngular包装了对 ECharts 的每个调用：初始init一个、所有事件订阅、每次对setOptions和resize的调用。执行此操作后，Angular Dev Tools Profiler 不再显示数百个
requestAnimationFrame来源变更检测。所以我非常确信它已经解决了。正如我所说，我不确定 ECharts 5 是否是关键（或者我在 ECharts 中使用 SVG 渲染器），但如果您还没有尝试过，我肯定会尝试一下。
I just stumbled across this exact issue. I'm working with ECharts 5, so perhaps it's different from 4, but I had the same expectations about
runOutsideAngularnot working withrequestAnimationFrame, but this GitHub discussion convinced me to try it, and it worked. I'm not using ngx-echarts, but it's the same issue, and the same solution.I haven't gotten much time to actually dig in and figure out exactly what the minimum is, but I just went crazy and wrapped every call to ECharts with
NgZone.runOutsideAngular: the initialinitone, all event subscriptions, every and every call tosetOptionsandresize.After doing that, the Angular Dev Tools Profiler no longer showed hundreds of
requestAnimationFrame-sourced change detections. So I'm quite convinced that fixed it.As I say, I'm not sure if ECharts 5 is the key (or that I'm using the SVG renderer in ECharts), but I'd definitely give that a try if you haven't yet.