この質問が何ではないかを明確にすることから始めましょう。フラッシュ メモリの管理やガベージ コレクションの仕組み (参照カウント、マーク アンド スイープなど) の簡単な説明を求めているわけではありません。また、メモリ リークを回避するためのヒント (レンダリングのリサイクル、弱参照、イベント リスナーの削除、IDispose パターン、タイマーの停止、ステージなどのグローバル オブジェクトからの静的ポインターとポインターの回避など) を要求するものでもありません。
MXML と Actionscript でコーディングされたかなり大きな Flex プログラムがあり、上記のすべてにかなり精通している人物によってコーディングされていると仮定し、それでもメモリ リークがあると仮定します。この時点で問題をデバッグする必要があり、問題はその方法です。
Flash Builder プレミアム IDE は、時間 A と時間 B でメモリーのスナップショットを作成し、2 つのスナップショットを比較して、「浮浪」オブジェクトについて報告できます。これを使用するには、プログラムを定常状態まで実行し (時間 A)、次にもう少し実行します (時間 B)。暗黙の前提として、システムにはほぼ同じオブジェクトが含まれている必要があります。新しいものは「徘徊」しています（メモリリーク）。都合のよいことに、IDE は各浮浪オブジェクトにつながるポインタのリストを提供します。
しかし、IDE は非常に重要な情報を提供していないようです。これらのポインタのどれがメモリ内のオブジェクトを「ロック」してガベージ コレクションを防止しているか、または子オブジェクト (サイクル) からの単なるポインタであり、オブジェクトが収集されます。IDE は一部のポインターに "gcroot" のフラグを立てますが、子オブジェクトからのポインターはしばしば (通常!) gcroot のフラグが立てられるため、このフラグは必要な情報を提供しません。適度なサイズのプログラムには多数のオブジェクトが含まれる可能性があり、オブジェクトはポインターを介して複雑なグラフに接続される可能性があるため、IDE を使用してメモリ リークの原因となっているポインターを見つけることは困難です。
したがって、私の質問は、Actionscript と MXML で実装された Flex プログラムでメモリ リークの原因を見つける方法について、(既に上で述べたこと以外に) 何かヒントを持っている人はいますか?