ブラウザ増加でFlashPlayerメモリ閾値低下

こんなこと気にする人orプロジェクトがどれくらいいるのか分かりませんが、

ひとつのInternetExplorerプロセス上で、複数ブラウザウィンドウを上げていった時、
ブラウザウィンドウの数と、Flashが利用可能な総メモリ使用量は反比例する。

・・・という事象があります。
(事象というかバグなんじゃねーのかって話ですが、Adobeは認めてくれませんでした。)

どういうことかと言うと、例えば、1ブラウザウィンドウの時には、Flashとして1GB程度使うことができても、30くらいブラウザウィンドウを同一ブラウザプロセス上に起動してしまうと150MB程度しか使えず、その閾値を超過するとアドオンエラーとしてブラウザ毎いきなり落ちるという事象です。

※なお、ここでいうFlashのメモリというのは、flash.system.System.totalMemory で取得できるメモリ使用量の数値のことです。

1GBなんて使うの作るが馬鹿だし、30もブラウザあげられることなんてそうそう無いだろう。と、思われるかもしれませんが、この数値はあくまでもご参考です。実際はアプリケーションによってこの閾値はいろいろ変わります。特に、使われる部品の種類が増えると閾値が下がることもわかっていますし、また、SWFLoaderを使うだけで、100MB程度閾値が下がることも分かっています。

気をつけなければいけないのが、単体で数十MB程度使用するアプリで、同一ブラウザプロセスで複数立ち上げることが想定され得るアプリケーションです。4〜5のブラウザ数で、閾値が300MB程度に落ちている可能性があります。

また、この事象はあくまでも、Flashが稼動するブラウザの数に依存します。さらに、ブラウザ全体で使用するメモリ使用量ではなく、あくまでもFlashが使用するメモリ使用量に依存します。

なので、意識しているアプリが数十MB程度で収まっていても、普通にFlashが稼動するWEBサイトを別ブラウザで閲覧されうるような状況だと、この「Flashが稼動するブラウザ数」が増加していく環境にあることになります。

閾値については、各環境で調査されることをオススメします。端末スペック等により、結果が微妙に異なるためです。閾値調査では、メモリ使用量を簡単に増加させるアプリを作らなければいけませんが、MXMLコンポーネントで闇雲に大量の部品を配置したものをつくり、それをMXMLアプリケーションでAddChildしていくようにして、そのAddChildする数を調整することで、メモリ使用量を調整することができるような計測アプリが適当でしょう。そして、その大量部品を配置したMXMLコンポーネントですが、部品種類が少ないものと、多いものをそれぞれ作って、それぞれで閾値調査すべきです。

閾値が決まったら、実際のアプリケーションで、計測した閾値がどれだけ妥当かを検証すべきでしょう。

この事象に悩まないようにするためには、やはりできるだけ小さい単位で処理単位を分割し、ひとつのアプリを軽くすることです。そうすると、どうしてもアプリ間連携が必要になるかと思いますが、SWFLoaderはできるだけ使用したくないですね。なんといってもUnload処理ができません。どこかでHTML単位でリフレッシュする処理を入れないと、Flashメモリ使用量が単純増加していく危険性があります。Moduleを使えばUnloadができますが、あまりメモリ開放効率はよくなさそうです。(ちゃんと調べてませんが)。JavaScriptやサーバサイドをうまく活用して、データ連携をしつつ、トータルでのFlashのメモリ使用量をできるだけ少なく抑えるようにすべきだと思います。