Adobe AIR と ActionScript Native Extensions (ANE)

ANE と NativeProcess クラス

ANE の話を始める前に、NativeProcess クラスの確認です。

NativeProcess は、AIR アプリケーションから OS ネイティブのコードを呼び出すときに使うクラスです。AIR 2 から追加された機能で、一見 ANE と良く似た機能を提供します。

では、どのように ANE と使い分ければ良いのでしょうか？

と思った人のために、NativeProcess との違いを並べてみると、

• NativeProcess は、デスクトップのみで使用可能
• NativeProcess を使用するアプリは、ネイティブインストーラーとしてパッケージ／配布する必要がある
• NativeProcess は AIR アプリとは別のプロセスを起動する
  • そのため別プロセスがクラッシュしても AIR アプリは安全
  • プロセス間通信の処理を実装する必要がある （開発効率と実行効率が低くなる可能性）

となります。

デバイス上で使おうと思ったら ANE しかないということですね。

ANE の利点

ANE は、AIR を使う （選択する） ことによって生じていた、いくつかの制限を取り除きます。そのため、従来は AIR の採用が難しかった場面でも AIR 3 からは ANE が使えるからね、というケースがありそうです。

具体的な制限として考えられるのは、

OS の機能との連携

AIR の提供する API はデバイスの全ての機能をカバーしません。今後も （原理的に） 全てのデバイスの機能をカバーすることは難しいでしょう。

実際、ジャイロスコープのように比較的新しい機能への対応はまだですし、特に Sony S2 タブレットのデュアルスクリーンのように、現状一部のデバイスでしか使われていない機能のサポートは当面ないものと予想されます。

このような一部の API が使えないために AIR 使えない！となっていた場面が、ANE の利用により改善されそうです。

既存のコードの再利用

既に、過去に多くのネイティブコードを使った開発を行っていて、コード資産を持っている場合、当然、それらを活用できるかどうかは重要でしょう。ANE を使えば、どのプラットフォームであれ、コード資産を ActionScript から呼び出して利用できます。

そうすると、過去の資産を生かしつつ、同時に、アプリのポータビリティを高める、デザイナーとのワークフローを改善する、といった AIR の持つ利点も得られるようになるかもしれません。

パフォーマンスの改善

パフォーマンスの最適化、特にハードウェアを最大限に利用したい場合、ネイティブコードに敵うものはなさそうです。この点 （懸念） が AIR 導入のネックになっていたこともあるのではないでしょうか。

高度なパフォーマンスチューニングが必要とされる処理があったときも、ANE を使えば、その箇所をネイティブコードで記述することができます。このアプローチは、計算処理だけでなく、GPU の機能を直接呼び出すといったケースでも役立ちそうです。

ANE の役割

ANE は、大まかに以下のような機能を提供します。

• ActionScript のコードからネイティブコードで実装された関数の呼び出し
• ActionScript のコードとネイティブコードの間のデータ共有
• ネイティブコードから ActionScript オブジェクトへのアクセス

なんとなく使い方がイメージできたでしょうか？

ANE を利用する際は以下のものを用意します。

1. ANE の API を使ってネイティブコードを呼び出す ActionScript クラス
2. ANE のネイティブコード用 API を使って ActionScript と連携するよう実装されたネイティブコード
3. ActionScript 側もしくはネイティブコード側が使うリソース （画像など）

これらの項目が用意できたら、ane ファイルとしてパッケージします。この ane ファイルをリンク指定することで、AIR アプリの開発者は、ane 経由でネイティブコードを呼び出せるようになります。

利用できるネイティブコードは、プラットフォームごとに決まっています。また、パッケージできる形式も決まっています。

• Android ： .jar または .so
• iOS : .a
• OS X : .framework
• Windows : .dll

一部のデバイスのみ特殊な機能を持つ、ただし OS は同じ、という状況で ANE を使う場合、特殊機能を持つデバイスにはネイティブコードの実装を用意して、その他のデバイスには ActionScript の実装を用意する、という使い方も可能です。

（上のリストでは、ネイティブコードの実装が必須であるかのように書きましたが、実際には ActionScript だけで ANE を実装しても良いわけです）

ANE と API 設計

ANE を使う場合、

• デバイス固有の機能を利用する
• ネイティブコードの開発を行う

という理由から、通常の AIR アプリケーションよりもポータビリティは下がりそうです。

ですが、ANE 側が提供する API を注意深く設計すれば、「AIR アプリ本体は変更無しで ANE のパッケージを取り替えるだけ」 で、複数のプラットフォームに対応できそうな気もします。

では、どのように ANE のインターフェースを設計するのがよさそうか？と考えてみると、AIR の SDK を参考にするのが良いように思われます。そうすると AIR ランタイムの API との一貫性もできそうですし。

具体的には、

• 機能が使えるかどうかを示す isSupported や supportsXX 属性を用意する。例えば NativeWindow クラスでは NativeWindow.isSupported や NativeWindow.supportsMenu などの属性を使って、利用可能な機能を判断できる
• 実行時に、実行環境に依存する振る舞いを取得できるよう supportedXX 属性を用意する。例えば Multitouch.supportedGestures 属性は利用可能なジェスチャーの一覧を Vector 型で保持する
• 結果の通知にはイベントを使用する。例えば、Geolocation クラスは GeolocationEvent を使って、位置情報を通知
• 実行時の確認を強要しない様、機能が利用できなくても呼び出せるように API を設計する （ただし害はなさないような実装にし、呼び出す前に必ず if 文でチェックしないと危険、という API は作らない - そもそも条件文の記述を避けられるようにすることが目的なので）

といった点が挙げられます。

設計が済んだら、インターフェースだけ定義されたクラスを SWC にしておけば、実際に AIR アプリの開発に利用して API の使い勝手を確認できます。もちろん、コンパイルが通るだけ、ですが。