AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android [Page 2]
原文： Inside iPhone OS 4.0: Multitasking vs Mac OS X, Android [Page 2]
マルチタスキングでの iPhone 4.0 vs. Android
Apple は当然のことながら Google がどのようにして Android のマルチタスキングモデルを設計したのかを理解しているし、Google が一般に文書公開されたオープンソースオペレーティングシステムにおいてサービスというコンセプトを特許化したという証拠はどこにもない。 そのため、Apple がマルチタスキングのために Google のモデルをまったくクローン化しなかったということから、Apple はこの問題について研究し、同社がより良いと考えるマルチタスキングへの独自アプローチを編み出した、と Steve Jobs が語ったときもただ単に大見得を切っていたのではないことが分かる。
同時に、Apple の新しいマルチタスキング API のある側面は Android のものと非常によく似ている。 David Quintana による Android と iPhone 4.0 の相違点についての 概観 によると、 iPhone 4.0 での「見かけ上のマルチタスキング」、つまり Apple が「Fast App Switching」と呼ぶものは、前述した Android のアプリサスペンドコンセプトとほとんど同一のものだという。
iPhone 4.0 のあるアプリから別のアプリへと切り替えると、以前に使っていたアプリはメモリー内に保持されるものの、その活動は凍結される。 先に指摘したように、デスクトップ OS のマルチタスキングという意味では実際にはマルチタスキングではなく、実際にはそうではないのに、複数のアプリがすべて実行されているかのような幻想でしかない。 そうしたアプリは切り替えて戻ってきてもすぐには立ち上がれるような準備は整っていないのだ。 だから名前が Fast App Switching になったのだ。
Apple がこのメカニズムを発表するまで、多くの iPhone プログラマらは、ユーザが素早くアプリを切り替えられるような「状態保存（saved state）」コンセプトほどは「マルチタスキング」を必要とはしていないという考えを表明していた。 それがまさに Fast App Switching のやっていることだ。
ちょうど Android の場合と同じく iPhone 4.0 は、バックグランドで凍結しているアプリを保存して、それから終了することでメモリーを回収でき、そのためユーザが戻ってくると、そのアプリはユーザが離れたのと同じ場所から再開できるようになっている。 ところが iPhone 4.0 は Android とは違って、TasKiller のようなプロセス管理ユーティリティを必要とすることなく実行中のアプリを明示的に終了できるシンプルな手法を提示している。
というのもホームボタンを押すだけではアプリを終了させることにはならなくなったため、Apple はショートカットに触れてホールドするという動作で、ちょうどホームボタンがやっていたように、赤いマイナス印を表示して実行中のアプリのタスクトレイから終了して取り除くことができるようになったのだ。 ユーザにとって思いがけない問題を引き起こしかねない、手動によるアプリやシステムプロセスの手動管理はいっさいない。
ちなみに、このタイプの「見かけ上のマルチタスキング」はまた、Microsoft が今年末に発表する Windows Phone 7 で採用することを計画しているものでもある。 強調のためにもう一度繰り返そう： マルチタスキングのこうした側面は、デスクトップ環境でのような複数のアプリケーションを同時に動作させるというものではなく、アプリ間で素早く切り替えられるようにそれらをメモリー内に残しておくというものだ。
より効率的な iPhone 4.0 でのマルチタスキング
Windows Phone 7 の見た目だけのマルチタスキングを超えるものとして iPhone 4.0 では、ユーザがアプリから離れた後も実行し続けてほしいサードパーティ製アプリの特定のタスクセットもサポートしている。 これはコンセプト的に Android のサービスに似ているが、新しい方法で実装されている。 Quintana が書いているように、iPhone 4.0 の「バックグランドプロセスは Android とは大きく異なる」のだ。
Quintana が指摘するところによると、一番の違いは iPhone 4.0 にはサービスというコンセプトがまったく存在しない点だ。 アプリはバックグランドクライアント／サーバコンポーネントを提供しない。 替わりに Apple は、ユーザがそのアプリから離れた後でもタスクを続行できるようにするためにアプリが従わなければならないルールセットを開発した。
ユーザが切り替えた後にもそのアプリが作業を続行するというアイデアは iPhone にとって新しいものではない。 サードパーティ製アプリにとって新しいだけのことだ。 Apple の Phone アプリは、その広告で長く謳われていたように、常にこれをしているからだ。 通話が進行中でも、ユーザはホームボタンを押してウェブをブラウズしたり、連絡先を探したり、メールをチェックしたりでき、その間 Phone アプリはその通話を維持する。
同じことが iPod アプリでも起こっており、音楽の再生を続行できる。 SMS や Mail はバックグランドでメッセージを受信できる、などなど。 しかし、もしユーザがメッセージをチェックしたり、アップデートを間断なく行ったり、バックグランドで他の操作を持続したりして、インストールしたあらゆるアプリですべて制限なくリソースを消費することになったら、これはユーザにとってまたたく間に問題となる。
一度に複数のことをしたいというユーザの希望と、そこそこ長い時間にわたって電話が機敏に動いてくれるというユーザの期待との間のバランスをとるために、Apple はサードパーティが実装できるような多くのバックグランドタスクを定義し、こうしたタスクが可能な限り効率的に確実に実行されるようなルールを定めた。
効率的なマルチタスキングの前提条件としてのシステムワイド通知
この道を行くための最初のステップは昨年実現されていた： プッシュ通知だ。 Apple は、アプリがバックグランドに居座ったり、バックグランドサービスがアップデートのためにリモートサーバを照会し放題にするのではなく、ユーザアプリに代わって効率的にアップデートをリスンし、その通知を受け取ったアプリを（都合の良い時に）起動したり、そのアプリに切り替えたりしてユーザが対処できるような通知をユーザに表示するシステムワイドなサービスを生み出した。
これは、他のプラットフォームが実際には実現していないものだ。 その優れたプッシュ通知が賞賛されている RIM の Blackberry でさえ、サードパーティ製アプリに公開のプッシュ通知メッセージング基盤を公開したのは最近のことでしかない。 この結果、ほとんどの Blackberry アプリはすでに非効率的な方法でアップデートのためにサーバ照会を行うようにデザインされることになった。というのも、制限のないマルチタスキングがすでにそこにあり、アプリは「間違った方法」でそれを行えるようになっていたからだ。 そしてユーザは短いバッテリー持続時間というかたちで代償を支払っている。
Android アプリも同様にユーザのバッテリー持続時間の問題を抱えている。なぜなら、個々のアプリがすべてスリープしている間も統一されたシステムスレッドがアップデートを監視するようにするのではなく、アプリはそれぞれバックグランドで照会しているからだ。 Apple のプッシュ通知機能はそのため、サードパーティ製アプリのためのマルチタスキングを同プラットフォーム上で試す以前からこの複雑な問題を思慮深く解決したのだ。
iPhone 4.0 では、システムレベル通知の第二番目のタイプが追加されている： それがローカル通知だ。 このメカニズムによって、アプリはスケジュール上にシステムがそれらのために処理する合図を設定できるようになっている。 外部サーバからプッシュされるイベントとするのではなく、アプリが起動している間にそのアプリによって設定され、そのアプリが眠っている間にシステムによって保持され時間通りに実行されるのだ。
例として、ライブのウェブキャストのアラームを設定するアプリが挙げられるかもしれない。 そのアプリはバックグランドに残って、そのアラームまでのカウントダウンをする必要はない。 システムがそのアラームを受け取って、そのアプリそのものがスリープ状態になっている間も時間になったらそのアプリに代わってそれをユーザに渡すのだ。
ページ 3 / 3： バックグランドでものごとを処理する、異なるマルチタスキングの理由。
前のページへ