我们已经有一个庞大的代码库编译并开始在FlasCC中运行。当你打开.swf时,玩家的内存使用量约为300MB。它或多或少都很好,因为C ++代码似乎仍有大约300MB的动态分配内存。
我们创建线程时会出现问题。 According to documentation,每个线程都将.swf复制到内存中并在沙箱中运行。这是否意味着每个pthread都会占用玩家用来打开.swf的相同~300MB的内存?
看来是这样。我做了一个简单的测试,产生pthreads并转储内存使用情况( 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个后台线程运行时报告的内容:(a picture from the same question on Adobe forums)
产生这两个空闲pthreads后,“Other”块已从11到800 MB膨胀。记忆进入了“其他玩家”和“未分类”。
所以主要的问题是:如何解决这个问题?也许有办法让AS3工作者消耗更少的内存?
答案 0 :(得分:1)
如果您考虑使用AS3 workers API,则可以传递任何要执行的SWF文件。
大多数示例(在AS3中)建议传递当前的SWF字节,然后使用类似Worker.current.isPrimordial
的内容来决定要做什么。
所以,虽然我认为你不能避免事实上你将拥有与线程一样多的玩家实例,但更好的方法是使worker SWF a separate module不会像主SWF那样回收更多的内存。
对于你的具体情况,我意识到这可能非常困难,因为你依赖于Adobe对worker的pthread的实现,这显然只是作为worker传入主SWF文件。此外,使用线程将现有的C / C ++代码库移动到AS3工作者远非琐碎。