アプリケーションの SWF ファイルのサイズを小さく抑える手段として、共有アセットを外部化してスタンドアロンのファイルにする方法があります。このようなファイルは個別にダウンロードされ、クライアントにキャッシュされます。外部化した共有アセットは、実行時に複数のアプリケーションからロードされ、使用されますが、これらのアセットをクライアントに転送するのは 1 度だけで済みます。これらの共有ファイルを「ランタイム共有ライブラリ」または「RSL」と呼びます。

コンポーネントやクラスのコアセットを共有している複数のアプリケーションが存在する場合、クライアントは、これらの共有アセットをアプリケーションごとにダウンロードするのではなく、RSL として一度にダウンロードすることができます。RSL は、クライアントディスクに永続化されるため、その後再び RSL をネットワーク転送する必要はありません。これにより、アプリケーションのファイルサイズを縮小することができます。RSL を使用するアプリケーションが多いほど、利点も大きくなります。

Flex アプリケーションは、次のタイプの RSL をサポートします。

• 標準 RSL - 同じドメイン内のアプリケーション間で使用するために作成された、カスタムクラスのライブラリ。標準 RSL は、ブラウザのキャッシュに保存されます。詳細については、標準 RSL についてを参照してください。
• クロスドメイン RSL - 標準 RSL と同様のカスタムクラスのライブラリ。別のドメインおよびサブドメイン内のアプリケーションからもロードできる点で、標準 RSL とは異なります。クロスドメイン RSL は、ブラウザのキャッシュに保存されます。詳細については、クロスドメイン RSL についてを参照してください。
• フレームワーク RSL - すべてのアプリケーションで共有できる、Flex コンポーネントのプリコンパイル済みライブラリ。フレームワーク RSL は、プリコンパイルされています。詳細については、フレームワーク RSL の使用を参照してください。

カスタムライブラリから独自の RSL を作成することもできます。これには、Flex ライブラリプロジェクト用の Adobe® Flex™ Builder™ の「プロジェクトのビルド」オプションまたは compc コマンドラインコンパイラのいずれかを使用します。

リンク付けについて

リンク付けを理解することで、RSL が機能する仕組みと、RSL を利用してどのように効果を上げるかを理解することができます。Flex コンパイラは、静的リンク付けと動的リンク付けをサポートしています。静的リンク付けは、Flex アプリケーションのコンパイル時に最もよく使用されるリンク付けタイプです。一方、動的リンク付けでは、RSL の利点を生かして最終的な SWF のファイルサイズを削減することによって、アプリケーションのダウンロード時間を短縮することができます。

静的なリンク付けでは、すべての参照クラスとその依存関係が、コンパイル時にアプリケーションの SWF ファイルに含められます。このため、動的にリンク付けされたアプリケーションに比べると、最終的なファイルサイズが大きくダウンロードに時間がかかりますが、すべてのコードが SWF ファイルに含まれるため、ロードと実行は高速になります。

ライブラリ定義をアプリケーションに静的にリンクするには、library-path および include-libraries コンパイラオプションを使用して SWC ファイルの場所を指定します。

library-path オプションを使用する場合、必要なクラスだけがコンパイル時に SWF ファイルに含められるため、ライブラリの内容すべてを SWF ファイルにコンパイルする必要はありません。include-libraries オプションでは、必要なクラスであるかどうかに関係なく、ライブラリのすべての内容が含められます。また、source-path および includes オプションを使用すると、SWF ファイルに個々のクラスを埋め込むことができます。

Flex Builder では、プロジェクト／プロパティ／Flex ビルドパス／ライブラリパスダイアログを使用して、プロジェクトにライブラリを追加します。コンパイル時にライブラリを静的にリンクするには、「リンクタイプ」で「コードにマージされます」を選択します。このオプションでは、アプリケーションで使用されるクラスだけが含まれるため、library-path コンパイラオプションと同じ結果になります。

ライブラリは、その一部がアプリケーションに静的にリンクされていると、RSL として使用できなくなります。

「動的なリンク付け」とは、アプリケーションで使用される一部のクラスを、実行時にロードされる外部ファイルに残しておく方法です。動的なリンクを行うと、SWF ファイルのサイズはメインアプリケーションの割に小さくなりますが、実行時にロードする外部ファイルにアプリケーションが依存することになります。動的なリンク付けは、モジュール、実行時スタイルシート、RSL によって使用されます。

動的にリンク付けされたライブラリを使用するには、アプリケーションのコンパイル時に、ライブラリの内容をアプリケーション SWF ファイルに含めないようにコンパイラに指示します。このクラスは最終的な SWF ファイルに含まれませんが、コンパイル時のリンクチェックは必要です。実行時には、ライブラリ全体がアプリケーション SWF ファイルにロードされるため、アプリケーションの起動時間が長くなり、使用するメモリも多くなります。

runtime-shared-library-path および runtime-shared-libraries オプションを使用して、動的にリンク付けされたライブラリの場所を指定することができます。

あるいは、external-library-path、externs または load-externs コンパイラオプションを使用して、ファイルをアプリケーションに動的にリンク付けすることができます。これらのオプションは、クラスとライブラリをアプリケーションから除外し、実行時にロードするための準備としてクラスとライブラリに対するリンクのチェックのみを行うようにコンパイラに指示します。external-library-path オプションは、動的なリンク付けを行う SWC ファイルまたはディレクトリを指定します。externs オプションは、動的リンク付けを行う個々のクラスまたはシンボルを指定します。load-externs オプションは、動的なリンク付けに使用するクラスを記述する XML ファイルを指定します。このようなオプションは多くの場合、モジュールとアプリケーションにクラス定義が重複して含まれることのないように、モジュールのアセットを外部化するときに使用されます。runtime-shared-library-path オプションは、外部ライブラリを RSL として使用するためのすべての引数を提供します。

Flex Builder で、動的にリンクされたライブラリを使用するには、ライブラリパスダイアログでそのライブラリのリンクタイプとして「RSL」または「外部」を指定します。

アプリケーションのリンク付け情報を表示するには、link-report コンパイラオプションを使用します。このオプションを使用すると、load-externs オプションでロードしたファイルと同じシンタックスを持つレポートが生成されるため、レポートを引数としてそのまま使用できます。このレポートの詳細については、リンカー依存の確認を参照してください。

コマンドラインコンパイラのオプションの概要については、Flex コンパイラの使用を参照してください。

RSL のメリット

次の例は、共有コンポーネントから RSL を分離する利点を示しています。この例では、ライブラリのサイズは 150 KB（キロバイト）で、コンパイル済みアプリケーションのサイズは 100 KB です。RSL を使用しない場合、ライブラリが両方のアプリケーションにマージされるので、ダウンロードサイズの合計は 500 KB になります。第 3 または第 4 のアプリケーションを追加すると、ダウンロードサイズの合計はそのたびに 250 KB ずつ増加します。

RSL を使用する場合、RSL のダウンロードは一度しか必要ありません。2 つのアプリケーションで同じ RSL を使用する場合、合計のダウンロードサイズは 350 KB で済み、30％の削減となります。第 3 または第 4 アプリケーションを追加すると、ダウンロードサイズの総計は、250 KB ではなく 100 KB ずつ増加します。この例では、RSL を使用するメリットは、新しいアプリケーションの数に比例して増大します。

この例では、静的にリンクされたライブラリを使用するアプリケーションは、Adobe® Flash® Player がアプリケーションごとに 250 KB のロードを終えるまで実行されません。一方、動的にリンクされた RSL の場合、250 KB 全体（アプリケーションと RSL の合計サイズ）をロードする必要があるのは最初のアプリケーションだけです。RSL がキャッシュされているので、第 2 のアプリケーションはわずか 100 KB がロードされた時点で実行されます。

図で示したシナリオは、1 つの可能性に過ぎません。アプリケーションが RSL 内の全コンポーネントを使用しない限り、サイズの違いはそれほど大きくないかもしれません（サイズが小さいとダウンロード時間が短縮される）。例えば、各アプリケーションが、RSL 内のコンポーネントの半数だけを使用するケースを考えてみましょう。ライブラリを静的にリンクすると、使用されるクラスのみが含まれます。結果として、最初のアプリケーションとライブラリで 100 KB + 75 KB となり、2 番目のアプリケーションとライブラリで 100 KB + 75 KB となるので、合計のダウンロードサイズは 350 KB となります。ライブラリを RSL として使用する場合、実際にどの程度ライブラリが使用されるかにかかわらず、SWF ファイル全体がネットワーク転送され、実行時にアプリケーションによってロードされます。このケースでは、RSL を使用しても使用しなくても、合計のダウンロードサイズは同じです。

一般には、共通 RSL を使用する Flex アプリケーションが多いほど、メリットも多くなります。

RSL に関する考慮事項

RSL は、すべてのアプリケーションにとってメリットがあるわけではありません。このため、アプリケーションのダウンロード時間と起動時間について、RSL を使用した場合と使用しなかった場合の両方のケースをテストする必要があります。

標準 RSL は、異なるドメイン間で共有することはできません。クライアントが、domain1.com でアプリケーションを実行するときに RSL を使用し、次に同じ RSL を使用するアプリケーションを domain2.com で起動した場合、使用する RSL は同じであるにもかかわらず、クライアントは RSL を 2 回ダウンロードします。標準 RSL の使用にはこのように限界がありますが、クロスドメイン RSL にはこのような限界はありません。

クロスドメイン RSL は、同じドメイン内に存在するアプリケーションに限らず、あらゆるアプリケーションからロードできます。ただし、クロスドメイン RSL の場合、RSL のロード時に、要約を作成してチェックするように求められます。これにより、アプリケーションの起動時間が少しだけ長くなります。

フレームワーク RSL は、任意のアプリケーションからロードできます。プレーヤーのキャッシュにフレームワーク RSL をキャッシュするという点を利用するには、クライアントは、Flash Player の最新バージョンを実行している必要があります。すべてのクライアントが最新の Flash Player を持っているとは限らないため、フレームワーク RSL のロードに失敗することもあります。このような場合、フェイルオーバー RSL を使用することができます。

RSL を使用すると、通常はアプリケーションの起動時間が長くなります。これは、実際にどの程度 RSL が使用されるかにかかわらず、Flex アプリケーションにライブラリ全体がロードされるためです。このため、RSL のサイズはできるだけ小さく抑えます。これは、静的にリンクされたライブラリの使用方法とは対照的です。Flex アプリケーションをコンパイルすると、コンパイラは、これらのコンポーネントライブラリから必要なコンポーネントだけを抽出します。

いくつかのライブラリを共有する複数のアプリケーションがある場合、それらのライブラリを単一のライブラリにまとめ、RSL として使用した方がよいように思えます。しかし、個々のアプリケーションで恒常的にライブラリを 1 ～ 2 個程度しか使用しないのであれば、小さな RSL をいくつかロードするよりも、サイズの大きい RSL を 1 個ロードする方が負荷が高くなる可能性があります。

このような場合、負荷の大きさはアプリケーションによって異なるので、サイズの大きい 1 個の RSL と、サイズの小さい複数の RSL の両方でテストするようにしてください。RSL を 2 つ構築したとしても、大半のユーザーがその 2 つともロードするような場合は、余分なクラスが含まれた 1 つの RSL を構築する方が適切でしょう。

複数の RSL で重複するクラスがある場合は、誤ったクラスがロードされないよう、バージョンを同期化する必要があります。

基本クラスが Sprite または MovieClip の場合は、ActionScript のみのプロジェクトで RSL を使用できません。RSL では、Application や SimpleApplication などの基本クラスで、RSL のロードが解釈される必要があります。

キャッシュについて

RSL は、初回使用時にキャッシュされます。別のアプリケーションで RSL を必要とする場合、ネットワークからではなく、キャッシュからロードすることができます。ディスクアクセスはネットワークアクセスよりかなり高速なため、キャッシュは RSL を使用するメリットの 1 つです。

RSL によって使用されるキャッシュのタイプは、RSL のタイプに基づきます。標準 RSL またはクロスドメイン RSL は、ブラウザのキャッシュに格納されます。キャッシュをクリアすると RSL が削除されるので、次に必要になったときにはまたダウンロードする必要があります。署名なしのフレームワーク RSL も、ブラウザのキャッシュに保存されます。

署名済みフレームワーク RSL は、プレーヤーキャッシュに保存されます。フレームワークキャッシュは、Flash Player で維持される特別なキャッシュです。フレームワークキャッシュをクリアするには、設定マネージャをクライアントから呼び出す必要があります。フレームワークキャッシュに格納されている RSL は署名されているため、クロスドメインポリシーファイルを必要とせずに、任意の Flex アプリケーションで使用できます。

フレームワークキャッシュの詳細については、プレーヤーキャッシュについてを参照してください。