AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android [Page 3]
原文： Inside iPhone OS 4.0: Multitasking vs Mac OS X, Android [Page 3]
三種類の特別なバックグランドタスク： VoIP、オーディオ、ロケーション
Apple が iPhone 4.0 でサポートしているその他のマルチタスキングシナリオには 3 種類あり、それらはアプリが手がけたい継続タスクに関連している。 特定タイプのアプリにたいして「一度にひとつのアプリ」モデルへの例外を認めるこのメカニズムは、iPhone OS でのマルチタスキング開発をめぐって AppleInsider が 先に掲載した記事［和訳］ でも期待されていたものだ。
最初の例外では、API がアプリに対してバンドルされた Phone アプリのように動作することを許可するものだ。 つまり、通話の着信を可能にし、他のアプリが使用されている間も通話を持続できるようにするものだ。 Apple の Phone アプリ以外は携帯電話通話を行えないため、この機能は Voice over IP と呼ばれている。Skype のようなインターネット接続を利用したアプリが通話を行えるようにデザインされているからだ。
この新しいバックグランド VoIP メカニズムを利用するためには、アプリをシステムに登録し、システムが VoIP 着信のためにネットワークソケットリスニングを維持しつつ、そのアプリはサスペンドするというものだ。 通話要求があった場合、システムはその VoIP アプリを呼び出して、それにネットワーク接続のコントロールを受け渡して通話できるようにする。
ふたつめのシナリオは内蔵の iPod アプリに似ている。 バックグランドオーディオだ。 これによって、Pandora といったアプリは、同アプリがフォアグランドにない時でさえ、音楽ストリームを再生し続ける能力をリクエストできるようになる。 Apple は、この新しい Background Audio 基盤の仕様をリクエストするアプリに iPod で使用しているのと同じバックグランド再生コントローラを結びつける。
マルチタスキングにおける三番目のシナリオは、定期的な位置情報更新に関連する。 この新しい Background Location は、位置情報データを利用する二種類のタイプのアプリに対応する。 運転の際の道案内を行う GPS アプリと、ユーザの位置情報から友人に通知したり近隣のイベント情報を提供したりするソーシャル・ネットワーキングアプリだ。
前者の場合、Apple は（TomTom のような）道案内に特化したアプリがスリープ状態に入らないようにして、そのアプリがバックグランドになった場合でさえ、音声による道案内を提供できるように GPS へのアクセスを許可している。 こうすると通常であればバッテリー持続時間が急速に短くなってしまうが、GPS を利用している人はほとんどの場合継続的な電源を供給するためのキットを利用している。
その一方で、Loopt といったソーシャル・ネットワーキングアプリは、便利に使えるようにするためには同じようにユーザの位置情報を知る必要があるが、車でのキットのようなものは使わないのが普通だ。 GPS を使った場合、限られた利用価値しかない軽量サービスを提供するだけでもかなり iPhone のバッテリー持続時間を短くしてしまうことは間違いない。 こうしたタイプのサービスを効率的にサポートするために、Background Location はアプリに、ユーザが携帯のセルタワー間を移動する度に携帯電話がすでに定期的に入手しているデータを提供する。
ユーザが 500 ないし 1000 メートル移動する際に、このアップデートは行われる。 位置情報の変更が通知されると、システムはアプリを目覚めさせ、その位置情報をアップデートし、その変更を処理するための一定時間を与えてから、再びそのアプリをサスペンドする。 こうすることで、こうしたタイプのアプリが（現行の iPhone の場合のように）絶えずフォアグランドに来ることなく GPS によるバッテリー使用税の問題を迂回できる。
異なるマルチタスキングの理由
Apple による制限付のマルチタスキングというアプローチは、効率性の向上に加えて、マルチタスキングをサポートしない iPhone 3G のようなデバイスとサポートしているより最近のデバイスとの間での簡素化された互換性を可能にしてくれる。 これら新しい API を利用できるアプリは、バックグランドでものごとを処理する能力をただリクエストすれば良いだけだ。なので、ハードウェアがそれをサポートしていない場合、そのリクエストはただオペレーティングシステム側から拒否されるだけなのだ。
Google のサービスをもちいたアプローチは、クライアント／サーバコンポーネントという新しいモデルが必要となる。 もし Apple がそれをコピーしていたとしたら、開発者らは古いデバイスのためのアプリセットと、より新しいデバイスのためのアプリというまったく異なるコードベースを作成しなければならなかったはずだ。Apple がすでに App Store に既存タイトルからなる大規模なライブラリーを持っていることを勘案すると、これは複雑で問題を孕んだ移行ステップとなってしまう。
加えて、Android 上のサービスで開発中が行っていることの多くは、すでにプッシュ通知を備えた iPhone OS で処理されている。 そのため Android でのようなサービスアーキテクチャを iPhone 4.0 ために実装するということは、自分のアプリを移植したがっている Android 開発者らにたいして、より効率的なプッシュ通知ではなく、サービスを利用してそうすべきだと仄めかしているようなもので、プッシュ機能がほとんど無視され使われなくなってしまった Blackberry でのような問題を生んでしまうだろう。
統一された開発ツール： Clang、LLVM そして Xcode
これもまたすべて、iPhone 4.0 にマルチタスキング機能を組み込むための Apple のデザインはすべて、異なるやり方をする別のプラットフォームとの間で互換性や類似性をもたせようとするのではなく、iPhone OS プラットフォームにとって最高のものにすることであるという結論につながっている。
Apple が iPhone OS と他のプラットフォームとの間でアプリの移植を簡単・シンプルにすることにはまったく興味がないとしても、それはまったく驚くにはあたらない。 そうしてしまうと、iPhone OS の有利な点がだだ漏れになってしまうだけであり、開発者らが iPhone OS 固有の機能を最大限活用しようと奮起するのではなく、複数のプラットフォーム間で動作するもっとも低い共通分母に焦点を合せることを奨励することになってしまう。
これは、Apple が Flash や Java を iPhone でのメタプラットフォームとしてサポートすることにまったく関心を持っていない理由と同じ理由だ。そしてまた、同社が iPhone アプリを出力する開発ツールを生み出すというサードパーティによる努力をサポートしたがらない理由でもある。 Adobe が追加したいと望んでいる Flash Professional 戦略は、そのユーザが iPhone 4.0 のマルチタスキング機能をサポートできるようにするものだ。Adobe は、Apple がするようには、こうした機能を次から次へと対ができないし、そうすることは必ずしも Adobe の関心でもない。
Apple が新たに打ち出した C、C++ そして Objective-C 以外の言語での iPhone 4.0 開発の禁止令は、Adobe の Flash CS5 のような外部の開発ツールへの攻撃として大方ではみなされている。 しかし、Rainer Brockerhoff をはじめとするオブザーバーらは、Apple が C 言語にフォーカスしようとしているのは Clang を利用した iPhone OS 開発を最適化するための同社の戦略により関連している、と 当時から指摘していた。
Clang（略して「C 言語」）は、Apple が出資してきたオープンソースプロジェクトで、（当然ながら）C、C++ そして Objective-C コードのための新しい フロントエンドコンパイラ として機能する。 Clang は LLVM、つまり Low Level Virtual Machine につながっており、これは Apple の Mac OS X および iPhone OS 双方に対応した Xcode 開発ツールのためのバックエンドコンパイラとして機能する。
Clang と LLVM からなるコンビネーションは、効果的に GCC（GNU Compiler Collection、Unix ライクなオペレーティングシステムのための GPL ライセンスされたコンパイラ）に置き換わった。 Apple によって置き換えられたコンパイラツールチェーンはより寛大な BSD ライセンス下にあるため、Apple はそれをより緊密に自社の Xcode Integrated Development Environment に統合できるようになった。
加えて Clang と LLVM のおかげで Apple はコードのコンパイルというワークフローのさまざまなステップをより最適化し、柔軟でモジュール化された新しいコンパイリングツールが GCC に提供しているさまざまな最適化と拡張によって、より効率的で高速、よりコンパクトで、よりデバッグが簡単な Mac と iPhone 用のアプリを生み出せるようになっている。
Clang と LLVM にそこまでの戦略的作業を投資している Apple が開発者らにたいして、マルチタスキングへの新たなサポートなど、iPhone にも iPhone OS の最新機能にも最適化されていないような、表れつつある最大公約数的プラットフォームを梃に iPhone アプリを送り込もうとするのではなく、自社独自の開発ツールを使うようプッシュするのは驚きでもなんでもないのだ。
前のページへ