モバイルOSアーキテクチャ。 ユーザーの傾向と印象

インテルの中国部門のエンジニアが執筆し、スマートフォン用オペレーティングシステムの分野の動向の分析に専念した記事の短い短縮翻訳をご紹介します。

私たちを取り巻く世界は広くなっています。 私たちは、家族や同僚と連絡を取り合い、膨大な数の異なるサービスを提供するのに役立つモバイルデバイスで長距離を移動します。 モバイルデバイスの機能の基盤は、そのオペレーティングシステムです。 そのようなOSの開発における私たち自身の経験と現在の市場状況のビジョンに基づいて、私たちの意見では、将来のOSを評価するいくつかのパラメーターを選び出します-ユーザーエクスペリエンス、エネルギー管理、クラウドサポート、オープン性。 この記事では、指定された基準グループに基づいて、現在のモバイルOSの調査結果を示します。

はじめに

モバイルOSのデザインは、デスクトップOSから組み込みOSを経て、現在スマートフォンに見られる製品に進化しました。 このプロセス中に、OSアーキテクチャは複雑なものから単純なものに変わり、途中で停止しました。 進化自体は、ハードウェアとソフトウェア、およびインターネットサービスの技術的進歩によって推進されました。



最近では、モバイルデバイスを使用するためのモデルは非常に単純です。 ユーザーは、データまたはオフラインゲームを管理するためのアプリケーションを起動し、静的なWebページをダウンロードしたり、メールを使用したりすることもありました。 現在、状況は劇的に変化しています。「プリインストールされた」機能はもうありません。デバイスは水曜日に一種のポータルとして機能し、多くのプレーヤーがサービスプロバイダー、独立した開発者などです。 -膨大な数のサービスを提供します。





モバイル利用モデル



消費パターンの観点では、今日のモバイルOS（Apple iOS、Google Android、Microsoft Windowsなど）のすべての代表者は、違いよりも類似点が多くなっています。

• それらはすべて、規定されたAPIを使用してSDKを文書化しており、開発者はこれらのOS用のアプリケーションを作成できます。
• それらのすべてには、開発者がアプリケーションを公開し、ユーザーがアプリケーションをダウンロードするオンラインアプリケーションカタログがあります。
• それぞれがマルチタスクと3Dグラフィックスのサポートを実装し、センサーとタッチスクリーンが広く使用されています。
• すべてのシステムで、ユーザーインタラクションのスムーズさと応答性に多くの注意が払われています。
• インターネットの使用は静的なページとはかけ離れており、HTML5はWebアプリケーションのデフォルトプラットフォームになりつつあります。
• すべてのオペレーティングシステムは、モバイル決済システムをサポートしています。
• すべてのシステムは、エネルギー消費の最適化に重点を置いています。

現在のモバイルOSの共通性は、通信だけでなく、ハードウェアとソフトウェアの分野における世界的な技術動向によるものです。 次に、上記の基準の観点から新世代のOSを分析します。 私たちはすぐに、それらが互いに矛盾していることを大いに指摘します。

ユーザー体験

パフォーマンスの従来の概念は、モバイルデバイスにはほとんど適用できません。 スマートフォンに関連した静的なパフォーマンスの代わりに、ユーザーの快適さ、感度、滑らかさ、一貫性、正確さで表現された彼の行動に最適に応答する能力という概念で操作することがより論理的です。 ベンチマークの集計ではデバイスAがBよりも劣っていることは非常に一般的ですが、ユーザーの知覚の観点からは、スマートフォンの特定のサブシステムを測定するテストではユーザーとの相互作用が考慮されていないため、人はこれをまず推定します



たとえば、ビデオをご覧ください。 従来のテストは、FPSや失われたフレームの数など、多くのメトリックで動作します。 このアプローチには少なくとも2つの問題があります。 まず、動画の再生は、プレーヤーの起動、動画データの読み込み、巻き戻しプロセスなど、複合体全体からの1つのアクションにすぎません。 ユーザーの観点からは、すべてをまとめて評価する必要があります。 別の問題は、スムーズな相互作用の重要な値としてのFPSがユーザーエクスペリエンスを常に反映するとは限らないことです。 たとえば、デバイスBのGallery3Dアプリケーションで画像をスクロールすると、顕著な速度低下が見られ、デバイスAではFPSが低くなりますが、すべてがスムーズに進みます。 問題が何であるかを理解するために、時間軸上に描画するフレームをプロットしました。 おそらく、おそらくその理由は誰にでも明らかです。FPS自体に加えて、その安定性を考慮する必要があります。つまり、平均値からの最大偏差のメトリックを導入する必要があります。







デバイスAおよびBのGallery3Dフレームレート



比較として、デバイスBの最適化後のフレームレートのグラフを示します。 ご覧のとおり、平均FPSはあまり変化しておらず、ユーザーの感情については言えません。





最適化後のデバイスBのフレームレート



ユーザーの感覚は主観的な概念であることを忘れてはなりません。 現代の科学では、ユーザーの反応を追跡するために、眼球運動、心拍数などを監視するいくつかの方法が使用されています。 ソフトウェアを作成するとき、考えられるすべての分析方法を使用して、体系的に問題にアプローチする必要があります。 メトリクスのシステム（たとえば、既に述べた感度、滑らかさ、一貫性、精度）を開発したら、ユーザーにとって快適さの境界を決定する必要があります。 以下の表は、いくつかの実験値を示しています。

	いいね	よし	有効な
遅延時間	≤100ミリ秒	≤200ミリ秒	≤500ミリ秒
グラフィックアニメーション	≥120fps	≥60fps	≥30fps
ビデオを再生する	≥60fps	≥30fps	≥20fps

明らかに、これらのデータは本質的に統計的であり、人間の性質に目を向けて適用する必要があります。

Androidの開発経験に基づいて、ユーザー最適化（ソフトウェア）アプリケーションは、並列化最適化とほぼ同様であり、実装がより難しいのは次の理由であるという結論に達しました。

• ソフトウェアは、多くのソフトウェアおよびハードウェアコンポーネント、およびそれらの相互作用に影響を与えます。
• これはユーザーエクスペリエンスにも影響するため、ソフトウェアはエネルギーの問題を考慮する必要があります。
• ソフトウェアは厳しい時間枠で動作します。 アプリケーションは、高速でも低速でもなく、ユーザーにとって快適な速度で動作する必要があります。
• ソフトウェアは主に主観的であり、開発者の本能に大きく依存しています。

電力管理

モバイルOS開発者にとって、エネルギー効率は常に頭痛の種でした。 アプリケーションの大食いは絶えず成長しており、バッテリー技術の進歩は慢性的にそれに追いついていません。 そのため、電力管理の重要性は常に高まっており、この問題を解決するには真にグローバルなアプローチが必要です。



過去10年間で、モバイルプロセッサは省エネの点で大きく進歩しました。 最新のモデルは、拡張Intel SpeedStepなどの動的な電圧と周波数の変更をサポートしています。 OS側からは、たとえばLinuxのcpufreqなどの特別なカーネルコンポーネントが、プロセッサの動作モードの制御に関与しています。 現在、エネルギー効率のための闘争の最前線を、プロセッサ（多くはすでに行われている）からモバイルデバイスの他のシステムに移行するプロセスを目の当たりにしています。 たとえば、グラフィックプロセッサの動的制御（CPUで使用されるものと同様）の導入により、場合によっては最大50％のエネルギーを節約できます。 I / Oシステムにも注意が必要です。 知能を高め、最適な動作モードを独立して選択する能力も消費にプラスの影響を与えます。



現在のオペレーティングシステムでは、電力消費の状況は次のとおりです。 Android OSは「柔軟な中断」の原則を公言しています。 デバイスの動作電力消費を制御する手段がないため、Androidは、システム内で何か興味深いことが起こらなければ、システムをサスペンド状態にすることを積極的に試みます。これは、ウェイクロックロックがないことで決まります。 Windows 8は、「接続されたスタンバイ」と呼ばれる根本的に新しいデバイス状態を提供します。 すべてのシステムプロセスが中断される従来のS3スタンバイモードとは異なり、ここではシステムは非常に経済的なモードで動作し続け、たとえば電子メールを受信できます。 接続されたスタンバイモードは、プロセッサのハードウェアとシステムのカーネルのソフトウェアに実装されます。



エネルギー消費の観点から見たアプリケーションの正しい動作は、記述された両方の節約アプローチのアキレス腱です。 最近の調査では、無料のAndroidアプリケーションはエネルギーの75％を無駄に消費し、広告を最小化モードで表示し、ブロックをgivingめないことが示されています。 同じことがWindows 8にも当てはまります。エネルギー効率の点で誤って記述された1つのアプリケーションでも、システム全体が接続されたスタンバイモードになることはできません。 現在、この種の「曲がった」アプリケーションに対処する方法について明確な理解はありません。

開放性

モバイルOSのもう1つの重要な機能は、その開放性です。 オープン性とは、ニーズに合わせてOSを使用、配布、カスタマイズ、改善する自由度を意味します。 開発者の観点から、OSのオープン性に関する別の研究があります。 ここでは、エコシステムのフレームワーク内、つまり、このOSの運用に何らかの形で関係するすべての関係者の枠組みの中で検討します。



最近では、ほとんどの携帯電話にはソフトウェアが閉じられており、サードパーティの開発者はそれらにアクセスできませんでした。 ユーザーは組み込みツールで満足しなければなりませんでした。 進化の過程で、APIを介してOSと対話するサードパーティソフトウェアのインストールを許可するオペレーティングシステムを備えたスマートフォンが登場しました。 開発者には適切なプログラミングツール（SDK）が提供されました。 この種のOSの良い例は、Apple iOSです。 AndroidなどのオープンソースOSにより、エコシステム全体の自由度が向上します。 オープンソースの利点は、プログラミングに関係のないエンドユーザーでも感じることができます。たとえば、このOSを使用しているメーカーの数、そして最終的にはモデルの数です。

クラウドサポート

クラウドテクノロジーはモバイルOSでさらに普及しています。 ほとんどの場合、それらを使用するアプリケーションは、ブラウザーまたはWebアプリケーションで開くWebサイトです。 多くの場合、アプリケーションはHTML5で作成されるため、モバイルOSでのこの技術の実装は開発者の焦点です。 サイトhtml5test.comは、さまざまなプラットフォームでのHTMLサポートを定量化し 、結果を表に示します（古いデータは記事に記載されています 。 最も関連性の高いものを公開しています-翻訳者のコメント） 。 モバイルOSの世界に初めて参入したTizenがこのランキングで1位になったことを特に嬉しく思います。

ブラウザ	プラットフォーム	スコア+ボーナス
ティゼン2		492 + 16
ブラックベリー10	BlackBerry Q10またはZ10	485 + 11
ドルフィンエンジンベータ	Android 2.2以降	469 + 3
Opera Mobile 14	Android	448 + 11
ティゼン1		426 + 16
Firefoxモバイル22	さまざまなプラットフォーム	422 + 14
Chrome 25	Android 4	417 + 11

サードパーティのブラウザは、システムやその開発プロセスを制御できないため、OSに組み込まれているブラウザに比べて有利な状況にありません。 理想的には、ブラウザは独自の環境で動作する必要があり、すべての開発者はこのために努力しています。 現在、多くの人がFirefox OSについて聞いていますが、このビデオではOpera OSのプレビューを見ることができます。 ただし、独立した開発者は依然としてトップにとどまっていることに注意してください。別のブレークスルーは、中国のブラウザーDolphin Engine（約翻訳者）です。



Webアプリケーション、つまりWebテクノロジーを使用するローカルプログラムは、ランタイム、フレームワーク、および開発ツールの形式で、モバイルOSからのサポートを（だけでなく）必要とします。

• ランタイム環境は、アプリケーションの健全性を保証します。 ブラウザから生成されますが、OS環境自体により統合されています。
• Webフレームワークは、jQueryMobileやSenchaなど、アプリケーション開発用の機能豊富なライブラリを提供します。
• 開発ツールは、開発者が多様なニーズに合わせて使用​​できるように、柔軟でなければなりません。

HTML5はクロスプラットフォーム標準として宣言されていますが、実際には、HTML5サポートはプラットフォーム間で同じではなく、標準化プロセスは本格的です。 非互換性を克服するために、PhoneGapフレームワークが作成されました。これは、すべての主要なモバイルOSでサポートされています。 すべてのエコシステム参加者は、すべての人に共通のHTML5を持ちたいと願っていますが、モバイルOS開発者は独自のアイデアを絶えず導入しているため、実装はそれほど簡単ではありません。



パフォーマンスの問題は、HTML5を扱うすべての開発者を心配しています。 私たちの意見では、モバイルオペレーティングシステムの最適化の最も関連する側面は次のとおりです。

• ハードウェアアクセラレーション。 グラフィックとビデオにはハードウェアアクセラレーションが必要です。
• マルチスレッドのサポート。 Web WorkerはHTML5で確実にサポートされる必要があります。
• JavaScriptエンジンの最適化。 JIT（Just In Time）は、すべての主要なJavaScript実装に含まれています。
• ネイティブまたはハイブリッドアプリケーションのサポート-既存のシステムライブラリを使用する機能は、Webアプリケーションを作成する際の別のアプローチになります

上記のすべてを要約すると、アプローチに多少の違いはあるものの、すべてのモバイルOSが一方向に、ある程度は互いに近づいていることを改めて指摘します。 この傾向は今後も続くようで、ユーザーとアプリケーション開発者の両方の手に渡るだけです。