ユーザーを満足させる高性能 Android アプリを構築するための 5 つのヒント

今日では、携帯電話やさまざまなモバイルアプリケーションが人々の日常生活の重要な一部となっています。そのため、アプリケーションの数は急増し続けています (現在、少なくとも 210 万の Android アプリケーションがオンラインになっています)。 Android 開発者にとって、アプリケーション分野における競争が激化する中で、エンドユーザーを満足させることができるアプリケーションを作成することがますます重要になっています。

Android アプリ開発者として、アプリのエンドユーザーを満足させるための鍵は何かご存知ですか?答えは、高性能です。実際、エンドユーザーの 96% がアプリケーションのパフォーマンスを非常に重要だと考えています。以下では、エンドユーザーに満足のいくユーザー エクスペリエンスを提供する 5 つの方法について説明します。

この投稿の本題に入る前に、まず高パフォーマンスとは何か、そしてエンドユーザーに満足のいくユーザー エクスペリエンスを提供する上でそれがなぜそれほど重要なのかを定義したいと思います。

高性能な Android アプリケーションは、デバイスのリソースを適切に使用し、エンドユーザーが目標やタスクを迅速に達成できるように支援します。実際、高性能アプリケーションは、エンドユーザーが感じる遅延も短縮できます。

ここで重要な用語は「知覚される遅延」です。これは、ボタンをクリックしてからエンド ユーザーが感じるインターフェイスの変化までの時間差を指します。エンドユーザーが実行するアクションとデータのソースに応じて、認識されるレイテンシを削減する方法は多数あります。

ここで、エンドユーザーのインタラクションとデータの読み込みに関する 5 つのシナリオを見て、Android アプリ開発者として、認識される遅延を減らし、アプリの応答性を高めてエンドユーザーのニーズに応えるために何ができるかを探ってみましょう。

1. 最も近いリソースからロードする

開発する Android アプリのエンド ユーザーは世界中に広がっており、これらのユーザーがモバイル ライフスタイルにますます依存するようになっていることは間違いありません。

レイテンシが増加する主な理由は、エンドユーザーとアプリケーションにデータを配信する Web サーバー間の距離を常に管理することが難しいことです。

認識されるレイテンシを減らすには、できるだけ近いリソースからアプリケーションにデータの大部分を提供する必要があります。さらに、多くの不正な API リクエストを最も近いリソースからクリアできるため、バックエンド サーバーへのラウンドトリップが回避され、エンド ユーザーのニーズに対する応答時間が改善されます。

Akamai Intelligent Edge Platform はすぐに使用できます。 Akamai を使用すると、データが常に最適化されたリソースからロードされるようになり、アプリケーションのパフォーマンスが向上し、エンドユーザーがデータ コンテンツに簡単にアクセスできるようになります。

2. キャッシュとプリフェッチ

Web サーバーから読み込まれたリソースの多くは、何度も再利用されることがよくあります。スマート キャッシュ メカニズムは、オブジェクトまたは API 応答を再利用のために一定期間保存できるため、長い往復の送信時間が短縮されます。多くのネットワークまたは画像読み込みデータベースはすでにこの機能を提供しており、ニーズに合わせて構成できます。これらのキャッシュされたオブジェクトは瞬時に読み込まれるため、レイテンシが非常に低く、エンドユーザーは遅延をまったく感じません。

これらのデータベースでは、キャッシュされたコンテンツの有効期限が切れると、ネットワークから再読み込みできるようにマークが付けられます。この情報に基づいて、キャッシュされたオブジェクトの再利用を一定期間保持するようにデータベースを設定できます。これらのデータベースの多くは、max-age などの HTTP ヘッダーもサポートしています。これにより、アプリの更新を高速化することなく、サーバーから直接読み込まれたキャッシュされたコンテンツのキャッシュ可能性とライフサイクルを制御できます。

ただし、ライブスポーツスコアを提供するアプリケーションなど、場合によってはキャッシュが適切でないことがあります。このようなアプリの場合、Android アプリ開発者はネットワークからデータを読み込み続けることができます。最も近いソースからデータをロードする場合 (上記を参照)、アプリのパフォーマンスは大幅に向上しません。

場合によっては、エンドユーザーが次に何を行うかがわかっていることもあります。たとえば、電子書籍を読むアプリケーションは、エンドユーザーが本の特定のページを読んでいるときに、ページを前後にめくりたい可能性があることを予測できます。この知識に基づいて、アプリケーションは事前にいくつかのページをプリフェッチしてキャッシュすることができます。こうすることで、エンドユーザーがこれらのページにアクセスしたときに、ページを即座に読み込むことができます。

同様に、電子商取引アプリケーションでは、エンドユーザーが製品の 4 行目を参照した場合、次の製品ページも参照する可能性が高くなります。アプリケーションがコンテンツの次のページを事前に取得してキャッシュできる場合、エンドユーザーが次のページに移動すると、データを即座に読み込むことができます。

ご覧のとおり、データのプリフェッチとキャッシュによって、認識されるレイテンシを減らし、エンドユーザーの満足度を高める方法は数多くあります。

3. API応答速度が速い

アプリケーションは頻繁に API を使用します。 API 応答がすばやく読み込まれると、エンド ユーザーは待機時間が短縮され、アプリケーションの使用時間が長くなります。

これを実現するには、Android アプリ開発者として、できるだけ多くのアプリが可能な限り最も近いソース (つまり、ネットワークのエッジ、上記を参照) から読み込まれるようにする必要があります。こうすることで、オリジン サーバーにアクセスする必要がある API リクエストだけが、地球の反対側まで届く長い旅をする必要がなくなります。

もう 1 つのアプローチは、アプリケーションとバックエンド サーバー間で送信されるデータのサイズを縮小して、API 応答時間を短縮することです。これを行うには、JSON の代わりに Colfer や Google の Protocol Buffers (Protobuf とも呼ばれます) などのデータ形式を検討することができます。データはネットワークに送信する前にバイナリに変換する必要があります。 JSON と比較すると、この形式では API リクエスト/レスポンスのバイト長を大幅に削減できます。 Protobuf を使用するには、Web サーバーとアプリケーションの両方に追加の投資が必要になることに注意してください。ただし、多くの場合、Protobuf を採用することで得られるパフォーマンスの向上は、それを有効にするために必要な労力をはるかに上回ります。

API 応答をすばやく読み込み、認識されるレイテンシを最適化する 3 番目の方法は、予測可能で繰り返される API 応答をキャッシュまたはプリフェッチすることです。キャッシュする場合、Android アプリ開発者は API 応答をローカル データベース テーブルに保存して、ネットワークから読み取るよりも高速に読み取ることができます。このローカル データベースは、独自のロジックに基づいて空にしたり更新したりできますが、ローカル データベースから読み込んでから更新すると、最高のパフォーマンスと最小のレイテンシを実現できます。

4. 画像と動画を最適化する

API に加えて、エンドユーザーは大量の画像やビデオを読み込む必要がある場合もあります。一般的に、アプリによって読み込まれた画像は、Web サイトなど、同じアプリ内の他の場所でも使用できます。

モバイル アプリケーションと比較すると、コンピューターを使用して開く Web サイトの画像には、画面サイズ、解像度、デバイスの種類に関する要件が異なります。アプリ内のグラフィックは、リソースが限られたモバイル デバイス向けに最適化することが重要です。モバイルアプリ上の動画でも同様です。

これらのメディアが最も近いソースからデータを読み込む場合でも、速度が遅くなる可能性があります。したがって、アプリベンダーとしては、画像や動画が最適化されているかどうかも判断する必要があります。これらのオブジェクトの巨大なサイズとグローバル モバイル データ ネットワークの予測不可能性により、近くのサーバーを使用するだけで得られる低遅延によるメリットが簡単に相殺されてしまう可能性があります。

この最適化を実現するには、モバイル アプリが画像やビデオを読み込むのに最適な解像度とサイズを備えていることを確認する必要があります。デバイスが大きすぎると、ダウンロードに時間がかかります。サイズが小さすぎると、画面上で画像がピクセル化されて表示されます。

Akamai Image Manager は、Android アプリ開発者が単一の高品質のオリジナル画像を複数のモバイル デバイス向けに自動的に最適化できるようにするソリューションです。この最適化により、画像やビデオのキャッシュも容易になります。デバイスの種類が限られている場合は、同じイメージの複数の異なるコピーを保存することもできます。

画像には、アプリケーションで一般的に使用されない EXIF データ (たとえば、写真を撮るときのカメラ設定の詳細) が多数含まれていることがよくあります。 Akamai Image Manager はこれを自動的に最適化できますが、tinypng などのサービスを使用してこのデータを手動でクリーンアップすることもできます。この最適化により画像ファイルのサイズが縮小され、読み込み時間が短縮されます。

もう 1 つの最適化アプローチは、プログレッシブ イメージとアダプティブ ビデオ ストリーミングを活用することです。この最適化により、端末の Android アプリケーションはイメージ全体のダウンロードを待つ必要がなくなります。アプリケーションはこれらの画像を段階的にダウンロードし、ダウンロードが完了すると表示を開始できます。これにより、エンド ユーザーに空白の画像ビューが表示されることがなくなり、認識される遅延が軽減されます。同様に、適応型ビデオバッファリング技術は、ネットワークの状態に基づいてビデオ品質を動的に調整できます。帯域幅が低い場合、ビデオの解像度を縮小して、エンドユーザーが読み込み画面だけでなくビデオの一部を見ることができるようにすることができます。

PNG や JPEG 画像のほかに、WebP 形式も試すことができます。 WebP 画像は作成に時間がかかりますが、読み込み時の効率が高くなります。 SVG 画像を試すことは、ローカルまたはネットワーク経由で読み込むときにディスク領域を節約するもう 1 つの効果的な方法です。

5. ローカルアニメーションとトランジションを最適化する

アニメーションは、エンドユーザーが満足のいくユーザー エクスペリエンスを実現し、ユーザーのアクティビティを通知する上で重要な役割を果たします。アニメーションは、パフォーマンスよりも、知覚される遅延とより顕著な関係があります。

アニメーションの読み込み時間が長すぎると、エンドユーザーはイライラしたり退屈に感じたりするでしょう。アニメーションが短すぎたりぎくしゃくしたりすると、エンドユーザーがコンテンツの意味を理解するのが難しくなります。どちらの状況も、エンドユーザーにとって悪い体験となります。バッテリーの消費も、適切に設計されたアニメーションでは考慮しなければならない側面です。アニメーションは、快適なユーザーエクスペリエンスを提供しながら、できるだけ少ないリソースを消費する必要があります。

Google のマテリアル デザイン ガイドラインによると、モバイル デバイス上の長いアニメーションの長さは 300 ～ 400 ミリ秒、短いアニメーションの長さは 150 ～ 200 ミリ秒です。これより長いまたは短いアニメーションは、遅延を感じたり、追うのが困難になる可能性があります。モーションに関するマテリアル デザイン ガイドラインは、例を挙げてこれらの時間範囲を理解するのに適しています。

したがって、エンドユーザーが短いアニメーションの内容をわかりやすく理解できるようにするには、アニメーションの継続時間を 150 ～ 200 ミリ秒にする必要があります。同様に、遷移補助（ある画面から別の画面に移動するなど）も 400 ミリ秒を超えないようにしてください。繰り返し実行されるアニメーション (プログレスバーなど) も同様の原則に従う必要があります。 1 つのアニメーションの長さは 300 ～ 400 ミリ秒にすることができ、進行状況バーが終了する前にループします。

人間が動きをどのように認識するかについて詳しく知りたい場合は、「Human Processor Model」と呼ばれる研究を読んでください。

結論は

高いパフォーマンスを得るための鍵は、データの詳細を考慮し、リソースを慎重に使用することです。幸いなことに、この目標を達成する方法はたくさんあります。

上記の 5 つのヒントに加えて、Android アプリ開発者には、「The Art of Computer Programming」と「Introduction to Algorithms」という 2 つのリソースを強くお勧めします。これらのリソースは、コーディングのベスト プラクティスに従い、最も効率的なアルゴリズムを使用して高性能な Android アプリケーションを作成し、エンド ユーザーに満足のいくユーザー エクスペリエンスを提供するのに役立ちます。

[[266295]]