0

考虑以下示例：

Components.utils.import('chrome://something/content/main.jsm');

// inside main.jsm
Components.utils.import('chrome://something/content/sub.jsm');

卸货main.jsm也是卸货sub.jsm还是sub.jsm除卸货外还应卸货main.jsm？

注意：卸载是shutdown()Firefox 引导插件的一部分。

4

1 回答 1

1

不，它不会。

从加载器的角度来看，所有模块都是独立的和共享的。这是有道理的，因为所有模块在应用程序中只加载一次。好吧，Cu.unload当然，直到你；尽管该模块的后续Cu.import会像初始加载一样再次加载它。

因此，一个模块在所有访问它的代码之间共享。这意味着将发生以下情况：

other.jsm

EXPORTED_SYMBOLS = ['shared'];
shared = {abc:123};

bootstap.js

// Initial load of shared.jsm
Cu.import(".../other.jsm");
// Will be seen by all other modules, since this is shared. 
shared.def = 345;

// Will not propagate, as the top-level name shared is just a reference
// in the current scope, initially holding a reference to the object from shared,
// but now overriden.
shared = "string";

Cu.import(".../main.jsm");

main.jsm

// Since the module was already loaded before, the loader will not load it again
// but instead just use provide the references. 
Cu.import(".../other.jsm");

Cu.reportError(shared.abc); // 123
Cu.reportError(shared.def); // 456

这可能非常方便，例如当您需要一个中央位置来跟踪/共享/缓存内容时，但在关机时的内存泄漏方面也有点危险。

例如，如果您向 中添加了另一个服务获取器Services.jsm，例如：

Cu.import("resource://gre/modules/Services.jsm");
Cu.import("resource://gre/modules/XPCOMUtils.jsm");

XPCOMUtils.defineLazyServiceGetter(Services, "uuid",
                                   "@mozilla.org/uuid-generator;1", "nsIUUIDGenerator");

现在这是有问题的，原因有两个：

  1. Services将（最初）保留对这些字符串参数的引用。这些字符串归您的模块所有。Cu.unload配置您的模块不会完全破坏您的模块实例，因为Services仍然引用这些字符串，因此您的模块不能被完全垃圾收集，并且您的模块实例将有效地成为Zombie Compartment。
  2. 由于所有其他附加组件以及浏览器代码都获得相同的服务。向其中添加新内容时可能会出现名称冲突。其他东西可能已经添加了uuid属性。

此外，您永远不应该使用不Cu.unload属于您的模块！

卸载是 Firefox 引导插件中 shutdown() 的一部分。

无所谓的操作Cu.unload。它将始终如一地工作。

于 2014-07-01T10:28:28.333 回答