我知道垃圾收集是JavaScript的弱点,但我想尽我所能做到这一点。
我正在使用remote
从我的渲染器进程创建新窗口,而不是从main
进程创建新窗口,我怀疑我的进一步复杂化。如果这是一个重大问题,我可以通过 main 进程创建它们。
以下是我现在创建窗口的方法:
import { remote } from 'electron';
function openInternalImageViewer(url) {
let imgViewer = new remote.BrowserWindow()
imgViewer.loadURL(url);
}
在关闭窗口后,通过提供的API足以实现我的目的,简单地将imgViewer
变量设置为null
,还是我怀疑我需要更正确?
答案 0 :(得分:2)
您无法直接确保从内存中删除JavaScript对象。您只需删除不再需要的所有引用,这样垃圾收集器就可以完成其工作。 (我不会称之为“弱点” - 与必须进行手动内存管理相比,它是JavaScript的强项,它可以为您完成所有工作。)
您不必担心函数局部变量:当函数返回时,变量无论如何都会超出范围。在没有完成任何操作之前手动“清除”它们。例如:
function openInternalImageViewer(url) {
let imgViewer = new remote.BrowserWindow()
imgViewer.loadURL(url);
/* ...let user interact with imgViewer... */
imgViewer = null; // Useless assignment.
}
对于let
和var
变量都是如此。
当然,全局变量不同(但当然你不应该有很多这样的变量):
var imgViewer;
(function openInternalImageViewer(url) {
imgViewer = new remote.BrowserWindow()
imgViewer.loadURL(url);
})(some_url);
/* ...let user interact with imgViewer... */
imgViewer = null; // This cleanup makes sense!
/* program execution continues, imgViewer no longer needed */
从引擎的角度来看,无论您指定null
,undefined
还是123
都无关紧要,因此您可以选择对您最有意义的值。
此外,在创建/分配内容时没有任何区别。垃圾收集的重要性在于对象是否“无法访问”,即您的代码无法再次访问它。
要验证它是否有效,您必须使用某种内存分析/分析工具。最简单的形式是使用操作系统的任务管理器。写一个大致类似的测试:
for (var i = 0; i < 100; i++) {
openWindow();
closeWindow();
}
并观察所有相关进程的内存消耗是否恢复到原始值。它可能不会立即这样做,相反,你会看到一个“锯齿”模式,其中内存不断增长,直到GC启动并再次降低它。您可以考虑在测试中手动强制GC循环;请注意,在生产代码中,这将浪费时间,因为自动GC行为已经非常仔细地调整启发式,以平衡垃圾收集所花费的时间与可用内存。