3

非常に大規模なコードベースをコンパイルし、FlasCCで実行を開始しています。.swfを開くだけで、プレーヤーのメモリ使用量は最大300MBになります。C ++コードで使用可能な動的に割り当てられたメモリがまだ約300MBあるように見えるので、多かれ少なかれ問題ありません。

スレッドを作成すると問題が始まります。ドキュメントによると、すべてのスレッドが.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つのバックグラウンドスレッドで実行されている場合のレポートは次のとおりです:(アドビフォーラムの同じ質問からの写真）

「その他」のブロックは、これら2つのアイドル状態のpthreadを生成した後、11MBから800MBに膨らみました。記憶は「他のプレイヤー」と「未分類」に入っていました。

したがって、主な質問は、これを回避する方法です。たぶん、AS3ワーカーがより少ないメモリを消費するようにする方法はありますか？

4

1 に答える 1

1

AS3 ワーカー API を検討すると、任意の SWF ファイルを渡して実行することができます。

ほとんどの例 (AS3 内) は、現在の SWF バイトを渡し、その後、Worker.current.isPrimordial何をすべきかを決定するために何かを使用することを提案しています。

そのため、スレッドと同数のプレーヤー インスタンスを使用するという事実を回避できるとは思いませんが、ワーカー SWFを、メイン SWF ほど多くのメモリを再利用しない別のモジュールにすることをお勧めします。

具体的には、アドビのワーカーを使用した pthread の実装に依存しているため、これはおそらく非常に難しいと思います。これは明らかに、メインの SWF ファイルをワーカーとして渡すだけです。さらに、スレッドを使用して既存の C/C++ コードベースを AS3 ワーカーに移動することは、簡単なことではありません。

于 2013-03-13T02:40:28.240 に答える