3

我们有相当庞大的代码库编译并开始在 FlasCC 中运行。当您打开 .swf 文件时，播放器的内存使用量约为 300MB。这或多或少都很好，因为似乎仍有大约 300MB 的动态分配内存可供 C++ 代码使用。

当我们创建线程时，问题就开始了。根据文档，每个线程都将 .swf 复制到内存中并在沙箱中运行。这是否意味着每个 pthread 都会占用播放器打开 .swf 所使用的相同的约 300MB 内存？

似乎是这样。我已经对生成 pthread 和转储内存使用（flash.system.System向我们报告的内容以及CModule.ram.length）进行了简单的测试。这是日志：

Starting 10 threads.
Memory usage: total=288MB private=335MB free=2MB CModule=33MB
Thread 0 started.
Memory usage: total=683MB private=732MB free=1MB CModule=36MB
Thread 1 started.
Memory usage: total=1071MB private=1121MB free=1MB CModule=37MB
Thread 2 started.
Memory usage: total=1459MB private=1510MB free=1MB CModule=38MB

此时 plash_player_debugger 已经退出（崩溃）而没有任何错误消息。

这基本上意味着我们没有线程。启动 2 个 pthread 后，C++ 代码只剩下约 50MB 的可用内存。

Adobe Scout 对内存使用情况进行了更深入的细分。以下是 .swf 使用 2 个后台线程运行时报告的内容：（来自 Adob​​e 论坛上相同问题的图片）

在生成这 2 个空闲 pthread 后，“其他”块已从 11 MB 膨胀到 800 MB。记忆进入“其他玩家”和“未分类”。

所以主要问题是：如何解决这个问题？也许有办法让 AS3 工作者消耗更少的内存？

4

1 回答 1

1

如果您考虑 AS3 工作者 API，您可以传递任何要执行的 SWF 文件。

大多数示例（在 AS3 中）建议传递当前的 SWF 字节，然后使用类似的东西Worker.current.isPrimordial来决定要做什么。

因此，虽然我认为您无法避免您将拥有与线程一样多的播放器实例这一事实，但更好的方法是使工作 SWF 成为一个单独的模块，它不会像主 SWF 那样回收尽可能多的内存。

具体而言，对于您的情况，我意识到这可能非常困难，因为您依赖 Adob​​e 的带有工作线程的 pthread 实现，这显然只是作为工作线程传入主 SWF 文件。此外，将使用线程的现有 C/C++ 代码库转移到 AS3 工作线程绝非易事。

于 2013-03-13T02:40:28.240 回答