Androidはアプリケーションの実装言語がJavaであるため、またちょっとかわったソフトウェア構成になる。今回はその構造から説明したい。
Android 前知識
Androidはアプリケーション開発環境としてJava言語が採用されている。
当初はJavaのみだったが、携帯端末はただでさえPCなどよりスペックが弱いため「ネイティブ言語で開発したい」という要望が高まった。
そこでAndroid Native Developers Kit（NDK）というC、C++でアプリが開発できる環境が提供され、それに見合った各機能のAPIが用意されることになった。
しかしJavaでしか提供していない機能もあるため、JNIというJavaとCの相互呼び出しインターフェースも提供され、高機能なソフトウェアではこれが巧みに使用されている。
さらに、Androidアプリはプロジェクトに含まれるリソースファイルをそのままアプリ内にファイルで保持しているわけではない。アプリ自体がzip化されているため、fopenなど、言語に良くあるファイル操作APIで読み込むことができないのだ。Assets内のファイルはAssetsManagerを通してファイルデスクリプタのみを取得し、そのデスクリプタで読み書きする。
こんな制限があるため、Androidでは他のプラットフォームで使われているファイル読み込み機能を含むライブラリやフレームワークが移植できなかったりする。なぜこんな仕様にした・・・・
Java：MediaPlayer
Androidでもっとも簡単に音声を再生するためには、MediaPlayerクラスを使用する。
上記のファイルの扱いに注意すれば、本当にシンプルにできているサウンドAPIだ。
基本的にstart、stopするだけで再生、ストップが可能なので説明は特にしない。
Java：SoundPool
SoundPoolは実装がネイティブで行われているため、レイテンシが少ないという特徴があるAPIだ。
ただ、データをオンメモリで扱いloadをあらかじめ完了しておく必要があるとのことで、SE再生などに使用される場合が多い。
同時再生数が多いなど比較的高負荷に耐えられるAPIだが、BGMなど長い音声の再生には向いていない。
また、古いAndroidでは読み込み完了のタイミングが開発者側では知ることができない、という若干トンデモ仕様でもあった。
データロード関連以外では、比較的使用しやすいAPIとなっている。
Java：AudioTrack
AudioTrackはデータをオンメモリにもできるし、少しづつ読み込むストリーミングにもできる。
お、これいいじゃん！と思っていたが、あまりにもバグが多くてみんな使用を避けたという経緯がある。
（少し前の話なので、現在どうかは不明。バグに関しては後述箇所も参照してほしい）
こちらも実際の処理はネイティブで実装されているとのことなので、スペックは問題なく使用できるものかと思われる。
NDK：OpenSL ES
NDKリリース以降、待望だったNDK完結のサウンドAPI。OpenXXという名前から想像できるように、Khronosが策定したAPIの一つとなっている。
ただ、Android NDK以外で採用されているのを見たことがない。
通常の再生、録音とともにコールバック機構なども備えるため、比較的実装しやすいAPIになっている。
マルチチャンネルなどももちろんサポートしているため、これを採用しているフレームワークは多いようだ。
仕様によると3次元音源シミュレーション機能も入っている、が、Androidでは動かない。
AndroidではOpenSL ESの仕様の全てを実装しているわけではないとのこと。
余談だが、ALSAが内部で使われているらしい。
AndroidはオープンソースのOSで、それぞれのハードベンダーが独自にカスタマイズすることが可能となっている。
また、ハードもそれぞれがAndroidの仕様に「出来るだけ」沿った形で設計されている。そのような経緯からか、Androidのサウンド系APIにはバグが多く、OSアップデートでFixされる例も多かった。音がならないようなものから、ループだけが効かない、など本当にデバッグしたかが疑わしい端末まであった。
OSの問題だけでなく、ハードベンダーの実装が追いついていなかったこともバグが発生した原因なので、あまりAndroidばかりを責めてはいけない。いけないのだ・・・
これまでサウンド系APIに関して各プラットフォームの事情をそれぞれ説明した。
OSの方針や立ち位置、使われ方から様々な特徴がAPIごとに現れている。
どのAPIを使用するかはケースバイケースなので、このシリーズはその参考にでもしてほしい。
0 件のコメント:
コメントを投稿