AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android
原文： Inside iPhone OS 4.0: Multitasking vs Mac OS X, Android
デスクトップでのマルチタスキング
Mac OS X を実行するデスクトップシステムでは、複数のアプリケーションを開いて実行するだけでなく、それぞれがウィンドウを開いた状態であることが求められる。 またバックグランドでたくさんのことを処理することも求められている。というのも、そうでなければ、役立つことができるはずの時にも高価な CPU や GPU はただそこに鎮座しているだけになってしまうからだ。
ここ 10 年間における Mac OS X の開発において、Apple はプロセッサの動作を持続させるべく新しいテクノロジーを追加してきた。 このオペレーティングシステムは 2001 年に、派手なコンポジットグラフィクスエンジンを搭載してデビューした。そして新たなリリースを重ねるごとに CPU（そして後には GPU も）で、影から透明反射までバックグランドで行う作業を追加してきた。
そのいくつかのバックグランド機能を挙げるとすると、Mac OS X はまた一定の間隔でインデックス作成をおこなう Spotlight、自動のファイルシステム最適化や、ファイルがアクセスされる度に履歴追跡バックアップをする Time Machine がある。 Mac が早くなればなるほど、システムはフォアグランドのアプリケーションが（望むらくは）目に見えてスローダウンすることなくさまざまな利用可能なプロセッサコアにさらに多くのバックグランドタスクを投げ込めるようになる。
Snow Leopard における 新しい改善点 の多くは、どうしたらシステム内で利用可能なさまざまなプロセッサコアにもっとも効率的にタスクを送り込めるか（Grand Central Dispatch）と、多くの場合アイドル状態になっている GPU をどう新たに活用するかに集中していた（OpenCL）。 デスクトップオペレーティングシステムがより多くのことをするようになればなるほど、よりリッチな体験を提供できるようになる。
モバイルでのマルチタスキング
iPhone が登場して Apple の Mac OS X 初のモバイル版がデビューした際、その新しいオペレーティングシステムのデザインゴールは完全に反対のものだった。 システムは限られた独自のバッテリーで動作しなければないような時に、バックグランドでは多くのことを行いたくはない。 その時間の多くですべてのものをできるかぎりアイドル状態にしておきたいのだ。
もちろん、それでも多くのことが処理されなければならないし、大体において典型的なデスクトップよりも多くなることさえある。 例えば、電話着信や SMS メッセージの着信をつねに監視していなければならない。 つまり、ベースバンドユニットが電話やメッセージを着信できるようにしておくためには、適切な信号でもっとも近いセルタワーを絶えず追跡していなければならないのだ。
電源管理は、もちろんのことながら完全に新しいアイデアという訳ではない。 Apple は 20 年ちかくにわたってノートブックを販売してきたし、バッテリー持続時間を確保するために不必要なハードウェアをシャットダウンするため高度な手法を生み出してきた。
しかし iPhone のようなハンドヘルドモバイルデバイスでは、考慮に入れなければならないのはハードウェアの電源管理だけではない。 アプリで作業するためのまったく新しいユーザーインタフェースもそこにはあるのだ。 Apple は、許容できるバッテリー持続時間を備えたうえで機能と機能性との間でバランスのとれたモバイルデバイスをどうしたら最高のかたちで送り出せるのかを見極めるために多大なエンジニアリング努力を注ぎ込んできた。
意図的な非マルチタスク化
iPhone における主要なデザイン決定は、電話や SMS、iPod、Clock、そしてこれらとその類似機能をサポートするプロセスなど、実質的なマルチタスキングをコアのシステムアプリにを制限することだった。 サードパーティ製アプリが iPhone 2.0 で登場した際、これらがバックグランドで実行できるような割り当てはいっさい存在しなかった。
Apple による説明は、サードパーティ製アプリを同時に実行できるようにすると、セキュリティー問題の可能性だけでなく、バッテリーを消費しすぎることになり、利用可能なすべてのシステムリソースを食いつぶしてしまわないようにバックグランドプロセスを管理するためのマニュアルツールを提供する必要性が生まれてしまうというものだった。
替わりに Apple は、バックグランドでアプリを動作したい主な理由のためのソリューションに向けて作業していると語っていた。 それは、外部からのアップデートをリスニングすることだ。 Apple の戦略は、これがどれほど重大な約束となるのかを理解していたために予測よりも遅れて実現されたものの、その結果うまれた Push Notification サービスでは iPhone アプリが実際にはバックグランドで実行されていないのに、絶えずアップデートをサーバ側に照会して外部からのアップデートに反応しているように見えるものだった。
サードパーティ製アプリがマルチタスキングできないような技術的な制限はいっさいない。 その制限は、そのモバイルデバイスのパフォーマンスをシンプル化・最適化するために Apple によって人為的に課されたものだった。 iPhone をジェールブレイクすれば、ユーザはサードパーティ製アプリでも制限のないマルチタスキングを有効にできた。 ところが、これによってバッテリー持続時間やパフォーマンスに問題が発生し、ユーザは手動で対処する必要にせまられることになった。
見せかけのマルチタスキング
Google は、デスクトップシステムでのマルチタスキングとは大きく異なる動作をするマルチタスキングを Android のために生み出した。 実際、両者はあまりに違うので、それらにたいして同じ言葉を使うことはほとんど混乱のもとになるくらいだ。
デスクトップシステムでは、複数のアプリケーションはすべて（バックグランドプロセスに加えて）同時に開き、同時に作業を行える。 異なるアプリケーションのウィンドウ間をマウスが行き来することで、各アプリケーションにイベントが送られる。 それらはすべて、タスクがバックグランドで行われて実質的には何もしておらず、本当には処理パワーを一切占有しておらず、ユーザがアクティブにしない限り（仮想メモリーのおかげで）メモリーもまったく消費していない場合でも有効になっている。
Android では、ユーザがひとつのアプリから別のアプリへと切り替えた時、バックグランドのアプリはサスペンドされる。 これは昏睡状態に入るようなものだ。 依然としてメモリーは占有している（潤沢にある訳でもないのに）ものの、何にも反応できず、作業も継続できず、新しいタスクも開始できない。 システムがメモリー不足の状態で実行されると、サスペンドされているアプリの状態を保存し、それらを終了しはじめる。
終了されたアプリはそれでも実行しているかのように見える。 ユーザがそのアプリに切り替えると、そのアプリは再起動され、あたかも何も起こっておらず、バックグランドで実行されていたかのように見えるように、システムによって保存された状態が受け渡される。 これまでのところ、これは本当にはマルチタスキングでもなんでもなく、むしろ iPhone のように一度にひとつのアプリを実行しつつアプリ間を高速で切り替えるだけのものだ。
