AIR プロジェクトに 2 つの大きなビットマップがあり、それらの可視性をユーザーにすばやく切り替えたいと考えています (同時に表示されるビットマップは 1 つだけです)。
アプリケーションの開始時に両方のビットマップをロードしてメモリに保持しようとしたので、最初のビットマップを表示して 2 番目のビットマップをすぐに非表示にする (またはその逆) ことができます。
ただし、デフォルトでは、プラットフォームは 30 秒後に非表示のビットマップをアンロードします。
この動作により、以前にアンロードされたビットマップを再度 RAM にロードする際に遅延が発生します。10秒ほどかかり、長すぎます。
どうすれば対処できますか？
まず第一に、あなたは幸運にもBitmapロードするでしょう。LiveDocsによる：
AIR1.5およびFlashPlayer10では、BitmapDataオブジェクトの最大サイズは幅または高さが8,191ピクセルであり、ピクセルの総数は16,777,215ピクセルを超えることはできません。（したがって、BitmapDataオブジェクトの幅が8,191ピクセルの場合、高さは2,048ピクセルになります。）Flash Player9以前およびAIR1.1以前では、制限は高さ2,880ピクセル、幅2,880ピクセルです。
とにかく、Bitmapそれ自体を保存する代わりに、なぜ保存しませんBitmapDataか？次に、画像を表示するたびに、BitmapDataを使用して新しいビットマップを作成します。
BitmapData.getPixels()それにもカットオフがある場合（なぜそうなるのかわからない）、どの出力を使用してみることができますByteArray。ビットマップをロードする必要があるたびに、を実行してBitmapData.setPixels( ByteArray )から、ビットマップデータを新しいビットマップオブジェクトに追加します。
警告：最後の方法は遅く、非常に遅くなります。
とにかく、おそらく画像のサイズを小さくするか、タイルシステムを調べることを検討する必要があります。そこで何をすべきかについては、Bing Mapsタイルシステムに関するこの記事を参照してください（アプリケーションに関係なく、すばらしい、よくまとめられた記事です）。これは明らかに必要以上に複雑ですが、256x256（BingとGoogleの両方で使用）は大きな画像をタイリングするのに適したサイズです。ビューポートの外にあるときにそれらを非表示にすることができるように、すばやくオンデマンドでロードできるほど小さいです（DisplayObjectステージ上のsが多いほど、実行が遅くなります）
私たちのプロジェクトでも同様の問題がありました。過去 10 秒間にビットマップが画面にレンダリングされていない場合、AIR はロードされたビットマップの圧縮されていない画像データを削除することがわかりました。ただし、ランタイムは圧縮された PNG または JPG データを保持するため、次にレンダリングする必要があるときに、必要に応じて画像を再圧縮解除できます。ただし、これにより、大きな画像を解凍する必要がある場合に、アプリでかなりの遅延が発生します。
私たちの修正には、ステージから画像 (後ですばやく表示する必要があるもの) を削除しないことが含まれます。画像を削除する場合は、代わりにステージの上部でアルファ 0.001 に設定します。画面には表示されませんが、Flash はレンダリングする必要があります。この修正は、レンダリング パフォーマンスに悪影響を及ぼすように聞こえますが、実際には、ステージ上にぶら下がっている「ほぼ透明な」ビットマップとの違いに気付きませんでした。
この修正にもかかわらず、いくつかの問題が発生する可能性があります。画面に何も変化がない場合、ランタイムはレンダー パスを実行することさえしません。長時間 (約 10 秒間) 何もレンダリングされない場合、Flash は不要なビットマップがステージ上に表示されている場合でも、それらを破棄し始めます。別の手法を使用して、Flash にレンダリングを強制的に継続させました。
これにより、少なくとも 1 秒に 1 回、Flash がレンダー パスを実行するようになります。
注: ビットマップ サイズの制限は、AIR 3 (および Flash Player 11) で完全に削除されました。したがって、今日、イメージが RAM に収まる場合は、ロードできます。