今日は晴天ながら最高気温が 11 ℃とかなり寒い一日でした。FITC Toronto 2010 の最終日はいよいよ深津さん & 新藤さんのセッションです。

深津さんは、もともと Packager for iPhone を使った開発についてのセッションが予定されていたのですが、2 週間前に変更せざるを得ない状況になったため、一般的なデバイス向けの開発についての内容に変更されていました。確かに iPhone に限らなくても、解像度や大きさの異なるスクリーン向けのインターフェースデザインを考えるのはここしばらくの大きな課題になりそうです。PhoneBook は既に申請済みで 5 月には発売されるのではないかとのことでした。iPad 版も見せて貰いましたが、かなり楽しいアプリになってます。それだけに Packager for iPhone が禁止されたのが残念です。

新藤さんからは、最近の仕事として BetweenAS3 の紹介 （他の Tween ライブラリとのパフォーマンス比較） と、それから、まだ秘密のプロジェクトですがという前置き付きで Flash Lite ベースの新しい携帯向け UI の紹介がありました。ストリーミング中継を見た方は分かると思いますが、iPhone や Andoroid 等のスマートフォンを含めても、ここまでユーザーにデザインを開放している携帯電話の UI はいまのところ無いと思うので、こういうのが広まると面白くなりそうです。実機の登場が楽しみですね。

2 人とも他のセッションはほとんど見ずに直前まで準備をしていたというだけあって、終わった後はかなり疲れた様子でした。本当にご苦労様です。

今回の最後のセッションは、 G-Speak を作った John Underkoffer でした。前日の Alex McDowell のセッションでは、ストーリーを元にした空間や生活環境をデザインした例として、映画 「マイノリティー・レポート」 に登場する 50 年後のワシントン D.C. を如何に作り上げたかという話があったのですが、今日のセッションでは 「マイノリティー・レポート」 に出てくるコンピューターインタラクションがどのようにデザインされたのかという説明があり、両方合わせて聞くと、未来の人と環境とのインタラクションの作りこみが先にあり、その中で展開するものとして映画のシーンが作られていたということがよく分かります。だから、「マイノリティー・レポート」 そっくりのシステムの実用化もできたわけですね。

まず、お知らせを 2 点。

明日の FITC は、深津さんと新藤さんのセッションがあります。http://fitc.influxis.com/ にてライブ中継される予定ですので、日本からもご覧頂けます。時間は、25時10分からです。

それから、FITC San Francisco が正式に発表されました。8 月 17 日から 19 日の 3 日間です。現在までに確定している講師のリストはこちらです。（Speakers）

さて、今日のトロントは晴天で最高気温 18 ℃と平年よりだいぶ暖かい一日になりました。そんな 2 日目のセッション情報を少しばかり。

Second Story の Thomas Wester のセッションは、幅が数メートル規模の大きさのテーブル上にインタラクティブなコンテンツを開発するという話でした。注意する点は大きく 3 つあるとして以下のような説明がありました。

• スクリーンが大きく、複数のユーザーが触ったり覗き込んだりする。一般的な Web のデザインの文法が使えない
• 制作物の物理上の制限やデバイスの機能的な制限について十分に検討しながらデザインを行う。設置される環境も動作に大きく影響することに注意
• Flash を使う場合の一般的な注意点。過去のほとんどのプロジェクトで Flash を使用してきているが、Flash だけで作ったという訳ではない。実現したい表現に対して、様々なハードウェアとソフトウェアの組み合わせから、最適な構築方法を見つけることが重要

Flash Catalyst CS5, Flash Professional CS5, Flash Builder 4 のセッションについては、特に目新しい話はありませんでした。内容は各製品ページに欠かれている情報と基本的に同じものだったので、参考までにリンクを張っておきます。

• Flash Catalyst CS5
• Flash Professional CS5
• Flash Builder 4

各製品のデモについては以前よりも改善された箇所が見られました。日本でも製品発表後のイベントなどで見れるかと思います。

余談ですが、Flash Professional のセッションで、fla ファイルをなんと読むか、という質問に対してその場で投票をしたところ、"エフエルエー" が "フラ" を大きく上回ったので、今後は "エフエルエー" が公式な呼び方になる、かもしれません。

FITC Toronto 2010 は今年で 9 回目を迎える FITC の本家で、3 日間に 70 以上のセッションが行われる大きなイベントです。FITC は世界の各地でも行われていて、昨年は日本でも初めて FITC Tokyo が開催されました。

今日のトロントは、一日中時々雨混じりの曇り空で朝からずっと 11 ℃ のままの寒い一日でした。そんなトロントから、1 日目の様子を少しばかり。

Jamie Kosoy のセッションは Big Spaceship のワークフローについての説明でした。FITC Tokyo のときと、被ってるネタもあったりしましたが、HTML5 の話になったときに、「デザイナーは Photoshop デザイナーとか Illustrator デザイナーとか言わないのに、Flash 開発者って言うのは何故？」 っていう言葉が印象的でした。 「開発者もどんな技術に対してもオープンでいればいいんじゃない？どうせ技術はどんどん変わるんだし」 とのことで。

Jim Corbett の Flash Player 10.1 のセッションは、ちょっと前にパフォーマンス関連のブログ記事を書きましたが、それをもうちょっと詳しくしたような内容でした。いつか日本語にして公開されると良いなと思います。OS X 向け Flash Player のパフォーマンスチューニングの質問が出たときには、Apple と協力しながら行っているということをはっきりと言ってました。iPhone / iPad の件だけが特殊で、一部で語られているような子供の喧嘩状態になってる訳ではないですよ、と。それから、UI デザインに関しては、従来 Flash はブラウザの中だったから UI も Flash っぽいものに （OS と区別できるよう） 意図的にしていたけれど、デバイス上ではそれぞれの OS に合わせた UI が表示される方がよいかもね、その機能を支援する API を 将来の Flash Player に持たせてもよいかもねと言ってました。

Mark Anders と Richard Galvan のキーノートセッションは、ランタイムに関してメモリ使用の最適化の効果が具体的に示されて、ある Flex アプリケーションを Flash Player 10.1 上で実行したところ、それだけでメモリ使用量が Flash Player 10 の時の 3 分の 1 になったという話がありました。それから、実機を用いたデモで Droid （TI OMAP 3430 550 MHz） と Nexus One （Snapdragon 1GHz） で目に見えるくらいパフォーマンスの差があったのことが印象に残りました。デバイスの性能向上に関しては楽観的になっても良いのかもしれませんね。ツールに関しては明日詳しいセッションがあるので、ごく簡単な紹介のみでしたが、Flash 開発ワークフローに InDesign が登場するようになったのが面白いところです。InDesign CS5 には Flash Professional の機能の一部が移植されていて、特に、TLF を使った文字組み中心のコンテンツにはかなり使えそうな印象です。

下の写真は、左から、Flash チームの千野さん、Flash Player チームの高田さん、Flex チームの渡辺さんです。

製品の品質を高めるため、文字通り毎日一生懸命頑張ってます！

Flash Builder 4 の知ってると便利なショートカットキーの紹介です。エディターとしては豊富な機能を持つ Flash Builder は、機能が多い分 （ADC 記事: Flash Builder 4 新機能） 使い方を見つけるのに手間がかかったりすることもありますが、そんなときに役に立つ情報です。これで、コーディング中ほとんどマウスを使うことはなくなるかも？

以下の説明は、Windows のキーを前提に説明していますが、Mac の場合は

Ctrl = Cmd
Alt = Option

です。

Ctrl-3 : クイックアクセス

Ctrl-3 をタイプすると小さなウインドウが開きます。このウインドウ内から、メニューの実行や設定変更、それからビューの切り替えなども行うことができます。

開いた直後の状態では、前回までに選択したアイテムの履歴が表示されるため、よく利用するものはここからすぐに選ぶことができます。選択は上下矢印とエンターキーで行います。ショートカットキーの割り当てられていないコマンドを呼び出すのには特に便利です。

この中に探しているものが無い場合は、検索対象に含まれる文字を入力します。すると、入力された文字に応じて絞り込まれたアイテムが表示されます。

下は、「ファイル」 を入力したところです。「プロファイル」 のように一部に 「ファイル」 を含むものも表示されています。この中から選択して、コマンドやメニューを直接実行できます。

上の状態では、全ての一致する項目が表示されていません。もう一回 Ctrl-3 を押すと、全ての項目が表示されます。↓

このパネルから Flash Builder のほとんどの機能にアクセスできます。とりあえずこんな機能ないのかな？と思ったときのヘルプ代わりにも便利です。

記事の元ネタとなっている Optimizing Performance for the Flash Platform が更新されました。前のバージョンより 15 ページほど増えています。とりあえず、CPU 編の 「Timer と ENTER_FRAME イベント」 を更新しておきましたのでよろしければご覧ください。その他には主に AIR 関連のトピックが追加されています。

では、Optimizing Performance for the Flash Platform から最後の Tips です。

まず、Flash Player 10.1 から追加された新しいネットワーク関連の機能 2 点です。

サーキュラーバッファリング （circular buffering）

• ビデオをプログレッシブダウンロードで再生する場合、デスクトップ環境では （Flash Player 10.1 含む） ロードした FLV ファイル全体をローカルディスクにキャッシュする。Flash Player はキャッシュから再生を行う
• デバイス上では、
  1． FLV のキャッシュに必要な領域が不足
  2． 20 MB 以上のディスク領域 （もし無ければ 4 MB 以上のメモリ） が利用できる - この値はコンパイル時に設定可能
  の条件でサーキュラーバッファリングが行わる
• サーキュラーバッファリングでは、キャッシュファイルが一杯になると、ファイルの先頭から再利用される
• ファイル全体がキャッシュされないと再生できないファイル （MP4 の一部のファイル等） を保存する領域が足りないと Flash Player はそのファイルをダウンロードしない

スマートシーク　（smart seeking）

• Flash Media Server 3.5.3 から Flash Player 10.1 にストリーミングを行うとスマートシークが使える
• 従来の動作は、シークが行われると、バッファされたデータは全て捨てられる
• スマートシークでは、シーク先がバッファされている範囲内だった場合、再利用できるデータはそのまま使われる。そのため、すぐに再生が開始され、ストリーミングに必要な帯域も削減することができる

あとは、Tips が 3 つあります。

SWF の分割

• SWF を複数に分割することで読み込みから起動までを高速化できる
• その際、アセットやロジックが重複してダウンロードされないように注意する
• RSL （Runtime Shared Library） を使って共通部分をダウンロードし、それを複数の SWF から getDefinition() メソッドを使って利用することが可能 - クラス定義、フォント、ビットマップ、サウンドなどが RSL 化できる

入出力エラー

• ネットワーク接続が不安定な場合に備えて IOErrorEvent.IO_ERROR イベントのリスナーを定義することが望ましい
• その際、エラーの発生をユーザーに知らせ、リトライができるようにすることを推奨

Flash リモーティング

• XML を使った通信はデータ量が多くなり、処理時間もかかるため、少量のデータを送受信するのに適している
• 大量のデータを送受信する場合は、AMF の使用をするべき
• AMF を使用する場合、サーバ側には ZendAMF, FluorineFx, WebORB, BlazeDS などのモジュールが必要
• Flex SDK を使うと、AMF が簡単に利用できる （Flash Professional でも Flex フレームワークの SWC を利用可能）

今回は Optimizing Performance for the Flash Platform から、描画パフォーマンスに関連する Tips です。

StageQuality

• デバイスは画面サイズが小さいため、イメージの品質の差がデスクトップ環境に比べて分かりにくい
• デバイスの画面は解像度が高いため、アンチエイリアス無しでも画像の質はあまり低下しない
• そのため、デバイスでは通常 StageQuality は MEDIUM で十分
  StageQuality.LOW: アンチエイリアスは一切行われない、もっとも高速
  StageQuality.MEDIUM: 一部アンチエイリアスが行われるがビットマップは対象外
  StageQuality.HIGH: アニメーションされるビットマップのみアンチエイリアスされない
  StageQuality.BEST: すべてのビットマップがアンチエイリアスされる、もっとも低速
• テキストのアンチエイリアスを "読みやすさ優先" にすると、StageQuality の値に係わらず、常にテキストはアンチエイリアス処理される

アルファブレンド

• アルファ属性を設定した場合、アルファブレンドを必要とするエフェクトの使用は避ける
• アルファ属性の使用も必要なときのみにするべき

ビットマップキャッシュ

• ビットマップキャッシュはベクター画像を内部的にビットマップデータに変換してから描画する機能、いったん作成されたビットマップはメモリ上にキャッシュされ再利用される
• ビットマップキャッシュ機能を利用するには、cashAsBitmap 属性に true を設定する
• 複雑なベクター図形やテキストの描画に効果がある
• 図形が変化するごとにビットマップを生成する、そのため頻繁に変更される図形は、ビットマップキャッシュするとかえって遅くなる
• ビットマップを保持するため、メモリをたくさん必要とする
• 図形の位置が変化してもキャッシュされたビットマップは再利用されるが、回転したり大きさを変えるとビットマップは再作成される
• アルファの値が変わった場合もビットマップは再作成される
• AIR と Packager for iPhone では、回転や大きさの変更でもキャッシュされたビットマップが使えるよう cashAsBitmapMatrix 属性が提供されている
• cashAsBitmap = true のとき、opaqueBackground 属性を設定すると、さらに処理を高速化できる
• cashAsBitmap は個々のオブジェクトに設定した方が、親オブジェクトに設定するよりも、使用するメモリ量を削減できるケースが多い （画面上で閉める領域の大きさに比例する）
• フィルターは自動的に cashAsBitmap = true を設定する。これによりパフォーマンスに影響が出る

GPU

こちらの記事をご参照ください Flash Player 10.1 のハードウェアを利用した描画機能 （グラフィックス編）

Adobe 製品サイトが更新されました。CS5 製品情報が公開されています。Web Premium には Flash Builder 4 Standard と Flash Catalyst CS5 が組み込まれました。

Web Premium CS5 のページ

Flash Professional CS5 のページ

出荷時期については、

"日本語版は2010年5月下旬にダウンロード提供およびパッケージの出荷開始、英語版は2010年4月下旬にダウンロード提供を開始しパッケージの出荷は 5月中旬開始を予定しています。"

とのことです。一部 5 月 28 日という報道もあるようですが。

それから、Adobe Stroe にて CS5 製品の先行予約が開始されています。（Adobe Store - Japan）

Flash Professional CS5 の価格は、製品版が 84,000 円 (本体)、アップグレード版が 25,000 円 (本体) です。アップグレード対象製品は、Adobe Flash CS4 Professional, CS3 Professional または Macromedia Flash Professional 8 または Basic 8 となっています。

CS5 Web Premium の価格は、製品版が 225,000 円 (本体) で、アップグレード版は対象製品により異なり、

• CS4, CS5 スイート製品から：94,000 円 (本体)
• CS2, CS3, Studio 8 スイート製品から：128,000 円 (本体)
• 3世代前までの単体製品から：178,000 円 (本体)

とのことです。（正確な条件は Web サイトでご確認お願いします）

いよいよ来週は CS5 発表のオンラインイベントですね。

Optimizing Performance for the Flash Platform から、AS3 関連の Tips です。この分野はいろいろな最適化手法がありますので、ここで紹介されているもの以外にも探せば見つかると思います。このページ Some ActionScript 3.0 Optimizations の下の方にもいろいろなサイトへのリンクがまとめられています。ご参考まで。

さて、本題に戻って、

Vector と Array

• 可能な場合は Vector を使用した方が早い
• 必要な Vector の大きさを最初に指定しておくとさらに早い （メモリ領域が足りなくなると、新たなメモリ確保とデータのコピーが必要になるため）

const MAX_NUM:int = 300000;
var coordinates:Vector.<Number> = new Vector.<Number>(MAX_NUM, true);
 

描画 API

• Flash Player 10 から追加された新しい描画 API を使うと、従来の moveTo() や lineTo() を使った処理よりも高速化できる
  drawPath()
  drawGraphicsData()
• 描画する図形が複雑になるほどその差が大きくなる

var container:Shape = new Shape();
container.graphics.beginFill(0x442299);
 
var coords:Vector.<Number> = Vector.<Number>([132, 20, 46, 254, 244, 100, 20, 98, 218, 254]);
var commands:Vector.<int> = Vector.<int>([1,2,2,2,2]);
 
container.graphics.drawPath(commands, coords);
 

Flash Player 10.1 の RC （Release Candidate） が Adobe Labs に公開されています。（Flash Player 10.1@Labs）

RC 版は、何も無ければこのままリリースされるという位置づけのバージョンですので、サイト運営やコンテンツ開発を担当されている方は、今動いているものがそのまま動作するか、確認よろしくお願いします。

ダウンロードはこちらから： Adobe Labs Downloads/Flash Player 10.1

バグを発見したらこちらへ： Adobe Bug and Issue Management System/Flash Player （英語のみです）

今のところ、OSX 10.6.x + Safari 4 / Chrome だと32-bitモードにしないと日本語入力できないことが判明していて、近いうちに何とかなる予定だそうです。

念のため、バージョンチェックについてはこちらの記事もご参照ください。（Flash Player 10 バージョン判別チェックリスト）

引き続き Optimizing Performance for the Flash Platform から、CPU の使用率を削減するための Tips です。

最初は、デバイス上での Flash Player 10.1 の新機能 3 点です。

スリープモード

• Flash Player 10.1 はアプリケーションが中断されたことを検知するとスリープモードになる
• スリープモードではフレームレートが 4 fps になり、描画は行われない
• スリープモード中はイベントが発生しない
• AIR にはスリープモードは無い

ポーズとレジューム

• Flash Player 10.1 はコンテンツがスクリーン上に表示されない状態になると再生を停止 （ポーズ） し、表示されると再生を再開 （レジューム） する
• ポーズ時には積極的にメモリの開放も行われる
• ポーズが起きるのはコンテンツがページのスクロールなどにより完全に表示されない状態になったとき
• ポーズ状態でも映像と音声の再生は継続する （ただし描画は行われない）
• hasPriority = true を設定 （下の項目参照） すると、ポーズ状態でも ActionScript の実行が行われる
• この機能も AIR には無い

hasPriority

• 新しい HTML 属性 <param name="hasPriority" value="true" />
• 値を true にすると、例えばページの下にの方にあってスクロールしないと表示されないようなコンテンツが、表示されないままでも読み込み後直ぐに再生が開始されるようになる
• ただし、表示されていないコンテンツの場合、再生されても描画は行われない
• CPU に余裕が無いとき、この属性の値に係わらず、コンテンツをクリックしないと再生を開始しない （クリック・トゥー・プレイとよばれる機能）

さて、以下は、CPU リソースを効率的に使うための Tips です。Flash Player 10 以前のバージョンにも適用されます。

前回に引き続き Optimizing Performance for the Flash Platform からメモリ使用の最適化に関する Tips です。

ビットマップのダウンサンプリング

• Windows Moblie 向けの Flash Player 10.1 では 32-bit イメージを 16-bit イメージにダウンサンプリングすることにより使用するメモリ量を半分にする
• 透明な部分を持つイメージに対してはダウンサンプリングが行われない

BitmapData の単一参照機能

• Flash Player 10.1 では、埋め込まれたイメージから BitmapData インスタンスを作成すると、常に単一のインスタンスを参照する
  
• 既存のコンテンツも再コンパイル無しで Flash Player 10.1 上で実行するだけでこの機能が利用できる
• 従来の Flash Player では BitmapData のインスタンスを生成した数だけ、実際にインスタンスがメモリ上に生成されていた

フィルターの使用

• フィルターを Sprite などに利用すると、2 つのビットマップが生成される （Sprite をビットマップ化したものと、フィルター適用後のビットマップ）
• 2 つのビットマップのうち表示に使用されるのはフィルター適用後のビットマップのみ
• Flash Player 10.1 はフィルターが 30 秒以上変更されないか、表示されなくなると、元のビットマップ （フィルターの適用されていない方） を開放する
• 解放後にフィルターが変更されると、元のビットマップがサイド生成される （動的ビットマップアンロード）
• Flash Player 10.1 で改善されてはいるが、フィルターの使用は負荷が高い
• 動的にフィルターを適用することが不要な場合には、Photoshop 等で作成した画像を読み込む方がよい

Adobe のヘルプサイトに、Flash Platform 用コンテンツのパフォーマンス最適化のドキュメント （ベータ版） が公開されています。（Optimizing Performance for the Flash Platform） Flash Player 10.1 における変更点も詳しく説明されています。

もう直ぐ内容のより充実した正式なドキュメントが日本語版として公開されると思いますが、とりあえず概要だけでも紹介しておきたいと思います。

なお、このドキュメントかなり細かいです。通常のコンテンツではここまで気にしなくてもよいのでは、というくらい些細な違いも取り上げられています。今後、iPhone や Andoroid 携帯などリソースの限られたプラットフォームを扱う人は知ってた方がよいかもですが。

まず、メモリ管理関連のトピックからです。

Display Object

• 以下の 3 種類のクラスを目的に応じて使い分ける
• 特に Shape のインスタンスは MovieClip のインスタンスの半分程度のメモリ使用量
  Shape: インタラクションの不要な場合
  Sprite: インタラクションは必要だがタイムラインが不要な場合
  MovieClip: インタラクション、タイムライン共に必要な場合

getSize() メソッド

• オブジェクトのメモリ使用量を調べることができる。単位はバイト
• flash.sampler.getSize(o:*):Number
• Flash Builder のプロファイラでも使用されている。flash.sampler パッケージを利用して独自のプロファイラ作成も可能

BitmapData の再利用

• 元の画像データが同じ Bitmap を複数作るときは BitmapData を共有する
• 下の例では、1 つの BitmapData インスタンスを 300 個の Bitmap が参照 - BitmapData を 300 個作る場合に比べ約 700KB の削減

すでにあちこちで書かれている話ですが、いちおうメモということで。

Mozilla や Google を中心とするグループが、ブラウザーのプラグインインターフェースとして広く採用されている NPAPI を拡張しようという議論を行っているそうです。

現在議論されている仕様がこちらの wiki にあります。

PlatformIndependentNPAPI

これによると、現在の NPAPI の持つ限界として以下のものが挙げられています。

• ブラウザーとは別プロセスでのプラグイン実行など、新しい機能への対応が必要
• 多くのプラグインが NPAPI 以外にも OS やブラウザー固有の API を利用せざるを得ない状況になっている （特に画面描画系）
• プラグインと HTML のレイヤーを正確に合成する事が困難で、OS やブラウザごとに異なる表示がされる原因となっている

これらの問題に対応するため、次世代の NPAPI では以下の 4 点の変更が検討されているようです。

1. ブラウザーと別のプロセスでプラグインを実行するための明確なセマンティクスの定義を追加
2. プラグインの描画とブラウザーの画面合成プロセスを統合
3. OS とブラウザーから独立した、２D および 基本的な ３D 描画に必要な API やイベントの定義を追加
4. プラグインを読み込む事無しに利用可能なプラグインを判定する機能

新しい NPAPI のために Pepper と呼ばれる新しいプラットフォームが定義され、OS やブラウザー非依存の環境を実現しようとしているとのことです。

この件に関して、Flash Player チームのブログ （Improved Flash Player Support in Chrome） では、以下のようなコメントが寄せられています。

• 新しい API は OS やブラウザー中立のため、プラットフォーム間での、動きやパフォーマンスに関する一貫性の無さは最小化されるだろう
• 新しい API はプラグインをより柔軟にかつ緊密にブラウザーと統合できるように設計されている
• 新しい API はパフォーマンスや安定性も改善するだろう、なぜならブラウザーはより多くの情報を直接共有できるようになるからだ
• 新しい API はブラウザとプラグインのセキュリティモデルの統合を容易にすることで、より安全な閲覧環境実現を可能にする

その他にも、パスワード管理や SEO 対策などにも利用できそうですし、HTML レイヤーを Flash レイヤーの上に描画することができるようになるかもしれません。（ならないかもしれませんが）

既に Flash で制作された iPhone アプリケーションを目にした事のある人も多いかと思いますが、昨年秋に MAX2009 で発表された Packager for iPhone の仕組みについての説明を少しばかり。

Packager for iPhone は Flash の出力を iPhone 用に変換する機能を持っています。少し紛らわしいですが、Flash CS5 に iPhone アプリの書き出し機能がある訳ではなくて、Flash CS5 には "iPhone アプリの書き出しができる Packager for iPhone" との連携機能がある、が正しい理解です。

これは賢い選択だったのではないかと思います。というのは、iPhone OS のアップデートがあっても、Packager for iPhone だけが対応すればよいからです。

AIR 書き出しの仕組み

まずは、AIR アプリケーション開発の流れの確認から話を始めます。下が AIR アプリ開発の大まかなステップです。

1. Flash Professional でアプリケーション開発
2. SWF, application.xml, その他必要なリソースを生成
3. 上記を一つにパッケージ
4. パッケージに署名
5. .air ファイルとして配布

AIR アプリを iPhone にインストールできないかと考えたときに、一番楽そうな方法は iPhone 用の AIR ランタイムを開発して配布、なのですが、これはできません。一番の問題は、iPhone ライセンスが、JIT (Just in Time) コンパイラーやインタープリターの使用を禁じていることです。そのため、SWF 内のバイトコードを VM が実行時に解釈するという AIR の実行モデル自体が許可されないのです。

だったら SWF を ARM 向けに事前コンパイルするしかないですね、というのは簡単な結論ではありますが、それにより、どのプラットフォーム上でも実行できるという AIR アプリケーションの持つ利点を放棄する事になってしまいます （EXE ファイルに変換すると、iPhone 専用モジュールになってしまうからです）。にもかかわらず英断が行われて、SWF 用の AOT (Ahead of Time) コンパイラーとして開発されたのが Packager for iPhone ということになります。

これも良い選択だったのではないかと思います。実行モジュールとして配布することにすれば、今のアプリケーション流通モデルにそのまま乗っける事ができますし、どのプラットフォーム用にも作れるという Flash オーサリング環境の優位性はまだ残ってているわけですし。