神話の駆逐艦の足跡にあるのか、なぜAndroidは遅いのに、％モバイルOS％はそうでないのか？

こんにちは、Habr！



Androidのハードウェアアクセラレーションに関する記事の私の以前の翻訳は、コメントで白熱した議論を引き起こしました。その主な動機は「Androidが遅くなるのはなぜですか」という質問でした。 同様の状況がインターネット全体で観察されているため、著者であるAndrew Munn（彼について）がAndroidブレーキの本当の原因を分析する別の非常に興味深く新鮮な翻訳（以下Google+から）を以下に示します。 私はこの投稿を自分で読んで楽しんでおり、最初にhabrasocietyと共有したことを誇りに思っています。

iOS、Windows Phone 7、QNX、およびWebOSが非常にスムーズなのに、Androidの速度が低下するのはなぜですか？

この投稿は、この質問に答えることを目的としています。



ただし、ポイントに移る前に、いくつかの予約が必要です。 第一に、私はソフトウェア工学の学位を持つ3年生です。 私はAndroidチームにインターンされ、Honeycombのハードウェアアクセラレーション作業の大部分を担当したRomain Guyは私のコードの一部を見ましたが、フレームワーク自体を開発しているチームにはいませんでした。 私はAndroidを知る真剣な権限を持っていません。ここで話していることを保証することはできません。100％正確ですが、言葉を実証するために可能な限りのことをしました。



第二に、私は1月からWindows Phoneチームのインターンシップに参加しているため、このポジションで無意識のうちにAndroidに立ち向かえる可能性がありますが、友達に聞いたら、話をしないように頼むのは本当に難しいですAndroid 私は週に数日よりもAndroid Tシャツの方が多く、Nexus SよりもMacbookを配りたいと思います。Googlplexは2番目の家のようなものです。 いずれにせよ、私の興味はおそらくAndroidに偏っている。



それでは、神話に関する以前の記事の分析を始めましょう（Diana Hackbornの投稿の完全版について話しています）。



ダイアナは驚くべき啓示から投稿を始めます。



「ウィンドウ内のレンダリングを見ると、完全な60FPSを達成するためにハードウェアアクセラレーションを使用する必要はありません。 これは、ディスプレイのピクセル数とプロセッサの速度に大きく依存します。 たとえば、Nexus Sには、800x480の画面でリストをスクロールするなど、Android UIに表示される通常のすべての項目について、毎秒60フレームの問題はありません。



え？ これはどのようにできますか？ Nexus Sを使用したことのある人なら誰でも、おそらく単純なListViewを除いてすべての速度が低下することを知っています。 また、バックグラウンドで何かが発生した場合、たとえば、アプリケーションのインストールや内部ドライブからのユーザーインターフェイスの更新など、まともなパフォーマンスの外観を忘れてください。 一方、iOSはアプリケーションをインストールする場合でも100％スムーズに動作します。 しかし、DianaはCPUの潜在的なパフォーマンスについて嘘をついていないことを知っているので、どうなりますか？

主な理由

これは、ガベージコレクターによる一時停止ではありません。 これは、Androidがバイトコードを介して動作するためではなく、iOSはネイティブコードで実行されるためです。 これは、iOSでは、インターフェイス全体のレンダリングがリアルタイム優先モードの個別のユーザーインターフェイススレッドで行われるためです。 一方、Androidは従来のPCモデルに従っており、メインレンダリングは通常の優先度で行われます。



これは、抽象的または学問的な違いではありません。 あなたは自分でそれを見ることができます。 最寄りのiPadまたはiPhoneを手に取り、Safariを開きます。 Facebookなどの複雑なWebページのダウンロードを開始します。 ロードの途中で、画面に指を置いて動かします。 すべてのレンダリングが即座に停止します。 指を離すまで、サイトはロードされません。 これは、ユーザーインターフェイススレッドがすべてのイベントをインターセプトし、ユーザーインターフェイスがリアルタイムでレンダリングされるためです。



Androidでこの演習を繰り返すと、ブラウザーがページのレンダリングとHTMLのレンダリングの両方を試みることに気付くでしょう。 どちらかを「優れた」ものにする。 Androidの場合、これは効果的なデュアルコアプロセッサが本当に役立つケースです。そのため、Galaxy S IIはその滑らかさで有名です。



iOSでは、アプリケーションがApp Storeからインストールされ、画面に指を置くと、レンダリングが完了するまでインストールが即座に一時停止します。 Androidは同じ優先順位でこれを実行しようとするため、フレームレートが低下します。 これがどのように発生するかに気づくとすぐに、Androidフォンのどこにでもあることがわかります。 ムービーアプリでのスクロールが遅いのはなぜですか？ 映画のサムネイルは下にスクロールすると映画リストに動的に追加されますが、iOSではスクロールが停止したときにのみ静かに追加されます。



何人かの人々は、iOSでのレンダリングプロセスの簡単な説明で私が犯したエラーを説明することを約束しました。 特に：



1）アニメーションの合成と事前設定-コアアニメーションとコンパニオンレイヤーのレンダリングを含むすべては、実際にバックグラウンドストリームで行われます。



2）Core Animationレイヤーでの新しいコンテンツのレンダリングとアニメーションの設定は、メインストリームで行われます。 これは、ユーザーインターフェイスが描画されるのと同じストリームです。



3）ネイティブコードでは、開発者が作成したすべてのコードはメインスレッドで発生します。 ただし、Appleはこれらをシステム駆動のバックグラウンドスレッドに移動するための非常にシンプルなAPI（Grand Central DispatchおよびNSOperation）を提供しています。 iOS 5では、コアデータ（オブジェクトリレーショナルデータベース）コンテキストをメインスレッドで直接使用できないことさえ宣言できます。



何に気付きますか？ リストをスクロールし終わるまで画像は描画されません。システムが画面のタッチを監視すると、WebKitのページレンダリングが停止します。これは、指が画面にある間、全世界を一時停止する最初の組み込みメカニズムです。

（実際、これは完全に真実ではありません。センサーを監視している間、メインスレッドは特別なモードになり、デフォルトでは、このモードでは特定のコールバックが遅延します。完全にバックグラウンドスレッドで、停止することなく、スクロール時に自動的に一時停止することはありません。開発者はこれらの遅延を明示的に示す必要があります。 この意図的な動作は、個々のアプリケーションの開発者によって慎重に実装されます。



これは技術的な違いではなく、文化的な違いです。 iOSの優れた開発者は、スクロールとトラックのタッチがほぼ完全に1秒あたり約60フレームで動作するまでソフトウェアをリリースしません。Androidの優れた開発者も同様です。

その他の理由

Androidが遅くなる主な理由は、UIスレッドの構造とその優先度ですが、これが唯一の理由ではありません。 まず、Dianaの予約にもかかわらず、ハードウェアアクセラレーションが依然として役立ちます。 ICSにアップグレードして以来、Nexus Sがこれほどスムーズに機能したことはありません。 :)]。 ハードウェアアクセラレーションは、ホーム画面やAndroidマーケットなどのアプリケーションに大きな違いをもたらします。 GPUは固定機能を備えた機器であるため、GPUが提供する支援もバッテリー寿命を延ばします。



第二に、以前に述べたこととは反対に、DalvikでGCと連携して作業する場合でも、ガベージコレクションは依然として問題です。 たとえば、これまでにHoneycombまたはICSでフォトギャラリーアプリケーションを使用したことがある場合、なぜフレームレートがそれほど低いのか疑問に思うかもしれません。 フレームレートは1秒あたり30フレームに制限されており、ほとんどの場合60 FPSで写真をスクロールできますが、ガベージコレクターで一時停止すると顕著なスタッターが発生することがあります。 フレームレートを30に制限すると、st音が修正され、常にスムーズなアニメーションが保証されます。



第三に、機器に問題があり、これもダイアナが言及しています。 Tegra 2は、Nvidiaマーケティング部門からの壮大な主張にもかかわらず、低メモリ帯域幅に有害であり、NEON命令セットをサポートしていません（ARMのNEON命令はIntel SSEと同等で、CPU上のマトリックスの計算を高速化できます）。 ハニカムタブレットは、Tegra 2よりもいくつかの点で理論的には性能が劣っていたとしても、異なるGPUで優れています。たとえば、Nexus SまたはApple A4のSamsung Hummingbird。 これは、リリースされた最速のハニカムタブレットであるTab Galaxy 7.7がGalaxy S IIを搭載したExynosプロセッサを実行していることを示しています。



第4に、Androidにはより効率的なユーザーインターフェイス合成に切り替える方法があります。 iOSでは、各タイプのユーザーインターフェイスが個別に表示され、メモリに保存されるため、多くのアニメーションでは、ユーザーインターフェイスの再構成を表示するのにGPUのみが必要です。 GPUはこれが非常に得意です。 残念ながら、Androidでは、ユーザーインターフェイスの階層がレンダリングに合わせて平坦化されているため、アニメーションを表示するには、画面の各セクターを再描画する必要があります。



第5に、Dalvik VMはデスクトップJVMほど開発されていません。 Javaは、恐ろしいデスクトップGUIのパフォーマンスで有名です。 ただし、多くの問題はDalvikの実装に持ち越されません。 Swingは、ネイティブAPIの上にあるクロスプラットフォームレイヤーであるため、ひどいものでした。 元の計画は完全にSilverlightに基づくものでしたが、メインユーザーインターフェイスのWindows Phone 7はネイティブコードに基づいていることに注意してください。 マイクロソフトは、インターフェイスに必要なパフォーマンスを提供するために、コードをネイティブにする必要があると最終的に決定しました。 Windows Phone 7のネイティブコードとバイトコードの違いは簡単にわかります。Silverlightで書かれたサードパーティアプリケーションのパフォーマンスは劣っています（NodoとMangoはこの問題を緩和し、Silverlightインターフェイスは通常非常にスムーズになりました）。



幸いなことに、上記の5つの質問のそれぞれは、Androidに根本的な変更を加えることなく解決できます。 ハードウェアアクセラレーションは、Android ICSを実行するすべての電話で実行され、Dalvikはガベージコレクターの効率を改善し続け、Tegra 2はついに時代遅れになり、既存のインターフェイス構成の問題に対する回避策があり、Dalvik VMはリリースごとに高速になります。 最近、TechCrunchのJason KincaidにGalaxy Nexusの滑らかさを尋ねて、彼は答えました。



「一般的に、Galaxy NexusのICSは非常にスムーズに動作します。 ランダムなst音があります-Galaxy Nexusで連続してファンクを取得できる場所の1つは、マルチタスクボタンを押したときです。 ただし、アプリケーションの一般的な検索（メイン画面の左側にスワイプする）にアクセスするように切り替えた場合は特に、iPhone 4Sの速度も予想以上に低下したと考えています。



これで、Androidのブレーキの問題は基本的に解決されました。 それほど速くない。

未来へ

Android UIは、冒頭で説明した設計上の制限により、完全に滑らかになることはありません。



-インターフェイスのレンダリングは、アプリケーションのメインスレッドで行われます。

-インターフェイスのレンダリングは通常の優先度で行われます。



Galaxy Nexus、またはEeePad Transformer Primeクアッドコアプロセッサを使用しても、これら2つの設計制限が有効な場合、スムーズさと許容可能なフレームレートを保証する方法はありません。 これは、3年前の最初のiPhoneとスムーズな操作で比較するには、Galaxy Nexusのパワーが十分であると言います。 では、なぜAndroidチームはこのようなレンダリング構造を使用したのでしょうか？



Androidでの作業はiPhoneがリリースされる前から始まり、当時AndroidシステムはBlackberryと競合するように設計されていました。 元のAndroidプロトタイプにはタッチスクリーンがありませんでした。 Androidの妥協案は、ハードウェアキーボードとトラックボールを備えたデバイスで理にかなっています。 そして、iPhoneが登場したとき、Androidチームはこの製品の競合他社を急いでリリースしましたが、残念なことに、システムのユーザーインターフェイス全体を書き換えるには遅すぎました。



これが、Windows Mobile 6.5、Blackberry OS、Symbianのタッチスクリーンのパフォーマンスがひどい理由です。 Androidのように、ユーザーインターフェイスのレンダリングを「優先順位付け」することを目的としていませんでした。 iPhoneのリリース後、RIM、Microsoft、およびNokiaはモバイルOSを放棄し、ゼロから開発を開始しました。 Androidは、「iPhone時代」以前に存在した唯一のモバイルOSです。



では、なぜAndroidチームは現状を変えなかったのでしょうか？ Romain Guyに説明させていただきます。



「...私たちが今日しなければならない仕事の多くは、何年も前に行われた特定の選択のために存在します.......ユーザーインターフェイスアニメーションでは最大の問題です。それを改善するために他のソリューションに取り組んでいます（別のレンダリングストリームを使用する可能性、など）。シンプルなソリューションは、もちろん、新しいグラフィカルツールキットを作成することですが、このアプローチには多くの欠点があります。



ロメインは、この決定の不利な点と不利な点を特定していませんが、仮定することは難しくありません：



-すべてのアプリケーションは、新しい構造をサポートするように書き直す必要があります。

-Androidは古いアプリケーションのサポートモードを提供する必要があります。

-新しいシステムが開発されるまで、他のAndroid機能の作業は中断されます。



ただし、これらのマイナス点とデメリットにもかかわらず、「ゼロから」という書き込みが発生するはずです。 初心者のマネージャーとして、Androidの遅さはまったく受け入れられないと感じています。 この問題は、Androidチームにとって最優先事項です。



Androidのテーマがハイテクに精通した友人とハイテクに精通していない友人の両方から提起されたとき、Androidがだんだん遅くなっていると何度も耳にします。 現実には、Androidはアプリケーションを開いてWebページをiOSよりも速く、またはさらに速く表示できますが、認識はすべてです。 ブレーキUIの修正。これは、Androidの評判とイメージを回復するための長い旅の始まりです。



問題の認識、ブレーキ-これはGoogleの哲学に違反しています。 Googleはすべてが高速であるべきだと考えています。 Google検索、Gmail、Chromeの主要な哲学は次のとおりです。 HTTPを改善するために、GoogleがSPDYを作成したのはそのためです。 そのため、Googleはサイトの最適化に役立つツールを作成しています。 これが、Googleが独自のCDNを開始する理由です。 これが、WebGLを使用してGoogleマップが表示される理由です。 Youtubeでのバッファリングは、ほとんどの人がよく覚えているものの、だんだん少なくなっている理由です。



しかし、おそらくAndroidインターフェースの遅延の最も重要な理由の1つは、人間と機械の相互作用（HCI）の分野に起因するものです。 最新のタッチスクリーンは、指と画面上のアニメーションが1対1で対応していることを前提としています。 iOSのスクロール効果（弾性バンド）がとてもクールで、楽しく、直感的である理由です。 そして、ヴァージンアメリカフライトのタッチスクリーンは非常にイライラする理由です。非常に遅く、非常に不正確です。



ユーザーインターフェイスブレーキは、人とタッチスクリーン間の接続を中断します。 デバイスとの通信が自然でなくなる。 魔法を失います。 ユーザーはユーザーとの対話から除外され、ユーザーが不完全なコンピューターモデリングを使用していることを無条件に承認する必要があります。 iPadでよく迷子になりますが、Xoomが画面間で途切れると縮みます。 2億人のAndroidユーザーが最高です。



そして、私は彼らが長期的にそれを手に入れることを知っています。 Androidチームは、世界で最も献身的で才能のある開発チームの1つです。 Diana HackbornやRomain GuyのようなスターがいるAndroidは良い手にかかっています。



この投稿がAndroidのブレーキに関する混乱を減らすことを願っています。

少し運が良ければ、Android 5.0はHTC G1のリリース以来、私たちが夢見ていたスムーズなAndroidをもたらします。 同時に、私はレドモンドで美しくスムーズなモバイルOSで作業し、彼女にふさわしい評価を彼女に与えようとしています。