依存関係の連鎖がもたらす問題
パッケージマネージャー(APM)でインストールする AIR 拡張機能の多くは、単体では提供されません。共有コアライブラリ、Android サポートライブラリ、Google Play サービス、Firebase、ネットワークや画像のライブラリなど、ヘルパーANEの連鎖を伴います。こうしたヘルパーは、別の拡張機能が必要とするためだけに含まれていることも少なくありません。
これらのANEはすべてアプリにパッケージされ、その機能を使うかどうかにかかわらず、起動時に読み込まれます。その結果、アプリは大きくなり、起動は遅くなり、バックグラウンドでの処理も増えます。
当社のアプリでの測定結果
当社のアプリは、古いスマートフォンやタブレットからライブ映像と双方向音声を配信することがよくあります。2026年、当社はアプリ内のサードパーティ拡張機能をすべて自社の自己完結型拡張機能に置き換え、実機で結果を比較しました:
| Android アプリの拡張機能数 | 45(うちサードパーティ製35、その大半がヘルパーANE)→ 13、すべて自社製 |
| アプリケーション記述子 | Android：197 → 133 行（マニフェスト追加分 117 → 85）、iOS：161 → 126 行。管理すべきマニフェスト項目が減り、壊れる可能性のある箇所も減ります |
| アプリサイズ | Android で −6.5 MB(−10 %)、iOS で −5.9 MB(−14 %) |
| アプリの起動 | 約2倍の速さ |
| バックグラウンド処理 | ストリームと並行して動作する分析ライブラリやヘルパーライブラリはありません。映像と音声に使える CPU と帯域幅が増え、特に古い端末で大きな違いになります |
競合と更新の強制
複数の拡張機能が同じヘルパーANEを共有している場合、それらのバージョンを一致させる必要があります。ある拡張機能の新バージョンが共有ヘルパーの新バージョンを必要とし、さらにそれを使う他のすべての拡張機能の新バージョンも必要になることがよくあります。
その結果、本来不要だったアップデート、ビルド時のバージョン競合が生じ、あらゆる組み合わせをすべてのプラットフォームで再テストしなければなりません。それはアプリを少しも良くしない作業です。
当社のアプローチ:自己完結型
プラットフォームのライブラリを薄いシェルで包み、そこに複数の補助 ANE をぶら下げるのは、多くの拡張機能を素早く提供するための近道です。すべての拡張機能を完全かつ自己完結型で構築するには、はるかに多くの手間がかかります。それぞれが必要なものだけを正確に備え、各プラットフォームで個別にテストされ、しかも他のすべての拡張機能と並んで動作しなければなりません。私たちはその手間を引き受けることを選びました。お客様のアプリがその影響を受けないようにするためです。
- 1つの機能に1つのファイル。各拡張機能は単一のANEです。コアライブラリもヘルパーANEもパッケージマネージャーも不要です。
- 機能に必要なものだけ。Android でのプッシュ通知用の Google Play Billing や Firebase Cloud Messaging のように、プラットフォームライブラリが必要な場合は、ビルド時にそのライブラリだけが自動的に追加されます。それ以外は何も追加されません。
- 独立したアップデート。ある拡張機能を更新しても、別の拡張機能の更新が必要になることはありません。
- 本番環境での実績。すべての拡張機能は、iOS、Android、macOS 上の当社のアプリで稼働しており、最新の端末と古い端末でテストされています。
拡張機能IDをアプリケーション記述子に追加し、ファイルをプロジェクトにコピーするだけで完了です。すべての拡張機能を見る · 料金