LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリの画像最適化とは — 表示速度と体感品質を左右する工程

アプリの画像最適化と読み込み高速化とは、端末に届くまでの転送量とメモリ消費を抑えながら、ユーザーが画面を開いた瞬間に近いタイミングで画像を表示できるようにする一連の設計を指します。一覧画面のスクロールが引っかかる、画像が多い画面の起動が遅いといった体感速度の問題は、多くの場合この工程の設計不足に起因します。

ここで扱う範囲は、端末内での画像表示に関わる技術選定です。アプリ全体のインストールサイズを削減するApp Thinning・App Bundleの活用や、起動時間・ANR（応答なし）対策を含むパフォーマンス改善全般は、それぞれ別の論点として扱っています。本稿は画像に絞り、遅延読み込み・キャッシュ・フォーマット・配信という4つの技術要素と、その計測方法に焦点を当てます。

Android公式ドキュメントは、ビットマップ（画像データ）を扱う際の課題として、メモリ予算を超過しやすい点とUIスレッドでの処理がANRの原因になりやすい点を挙げています^*1。例えば1200万画素の写真をARGB_8888形式でそのまま読み込むと、1枚あたり約48MBのメモリを消費するとされています^*1。この数値からも分かるように、画像は他のUI要素と比べてメモリ・転送量への影響が大きく、個別に最適化の設計を組む価値がある領域だと言えます。

遅延読み込みとプレースホルダーで初期表示を軽くする

画面に表示されていない画像まで一度に読み込む実装は、初期表示を遅らせる典型的な原因です。遅延読み込み（画面に入るタイミングで画像の取得を開始する方式）を導入すると、最初に必要な分だけを先に表示でき、体感速度が改善します。

先読み（プリフェッチ）でスクロールの引っかかりを防ぐ

一覧画面のスクロール中に画像が遅れて表示される問題には、先読みの仕組みが有効です。Apple公式ドキュメントは、テーブルビュー・コレクションビューでの先読み（prefetching）について、セルが表示される前に非同期で画像を取得・準備しておくことで応答性を高める仕組みを紹介しています^*2。画面に入ってから読み込みを始めるのではなく、入る少し手前で取得を始めておく設計が要点です。

プレースホルダーで「何も表示されない時間」をなくす

画像取得中に空白のまま待たせると、ユーザーは読み込みが止まっていると感じやすくなります。取得完了までの間、単色のブロックやぼかし画像などのプレースホルダーを表示しておくと、レイアウトのがたつきを防ぎながら待機時間の体感を和らげられるでしょう。プレースホルダーのサイズは実際の画像と同じ縦横比で確保しておく必要があります。サイズが一致していないと、画像が読み込まれた瞬間に周囲の要素が動く現象（レイアウトシフト）が発生し、誤タップの原因になりかねません。

ファーストビューの画像は遅延読み込みの対象から外す

Web領域の知見にはなりますが、画面を開いた直後に見える範囲（ファーストビュー）の画像まで遅延読み込みの対象にすると、かえって表示が遅れるという指摘があります^*3。この考え方はアプリにも当てはまり、起動直後に表示される画像は先に読み込み、スクロールしないと見えない画像だけを遅延読み込みの対象にする切り分けが必要です。

メモリキャッシュとディスクキャッシュの二段構え設計

同じ画像を何度も表示する場面では、キャッシュ（一度取得したデータを再利用のために保持する仕組み）の設計が転送量とCPU負荷を左右します。キャッシュは役割の異なる2つの階層に分けて考える必要があります。

メモリキャッシュは検索順序の一番手

Android公式ドキュメントは、最近使用したビットマップをメモリ上に保持するLruCache（最も使用頻度の低いデータから自動的に破棄する仕組み）の活用を推奨しています^*4。キャッシュサイズの目安としてアプリに割り当てられたメモリの1/8程度を挙げており^*4、割り当てすぎるとアプリ全体の動作を圧迫する点に注意が必要です。画像を表示する際は、まずメモリキャッシュを確認し、なければディスクキャッシュ、それもなければ新たにデコードするという優先順位で処理する設計が基本です^*4。

ディスクキャッシュはアプリ再起動後も残る永続層

メモリキャッシュはアプリを終了すると消えるため、再起動後にも画像を再利用したい場合はディスクキャッシュ（端末のストレージに保存する仕組み）を併用します。Android公式は、ディスクキャッシュへの読み書きはI/O処理のため、バックグラウンドスレッドで実行する必要があると説明しています^*4。メインスレッドでディスクアクセスを行うと、処理待ちの間に描画が止まり、ANRの一因になりかねません。

SoftReference/WeakReferenceは非推奨とされている

古い実装例では、メモリキャッシュの代わりにSoftReference・WeakReference（ガベージコレクションの対象になりやすい弱い参照）を使う方法が紹介されることがあります。Android公式ドキュメントは、Android 2.3以降でガベージコレクションの挙動が変わったことを理由に、これらの利用を推奨しないとしています^*4。新規実装ではLruCacheベースの設計を採用するのが妥当です。

WebP・AVIF・HEIC — フォーマット選定の判断軸

画像フォーマットの選び方も、転送量とデコード負荷に直結します。JPEG・PNGに代わる新しいフォーマットが複数登場しており、それぞれ対応状況と特性が異なります。

WebPはPNG・JPEGより小さいサイズで同等品質を狙える

Google公式は、WebP（Googleが開発した画像フォーマット）のロスレス圧縮でPNG比26%、ロッシー圧縮で同等画質のJPEG比25〜34%のファイルサイズ削減が見込めるとしています^*5。透明度（アルファチャネル）が必要な場合も、ロッシー形式でPNG比おおむね3分の1のサイズに収まるとされています^*5。Android公式ドキュメントもAndroid 4.2.1以降でのWebP対応を明記しており^*1、対応OSバージョンの範囲が広いことが実務上の採用しやすさにつながっています。

AVIFはさらに新しく、対応OSバージョンの確認が前提になる

Android公式ドキュメントは、AVIF（新しい世代の画像フォーマット）についてAndroid 12以降で対応し、従来のJPEGと同等のファイルサイズでより高い画質を実現できるとしています^*1。ただし対応がAndroid 12以降に限られるため、旧バージョンの端末を主要な対象に含む場合は、フォールバック用のフォーマットを別途用意する設計が必要です。

写真はJPEG系、単色領域が多い画像はPNG系が向く

Android公式は、細部の多い写真的な画像にはJPEG系のフォーマットが、単色の領域が多いイラストやアイコンにはPNG系のフォーマットが圧縮効率の面で適していると整理しています^*1。両方の特性を1つのフォーマットで済ませたい場合の選択肢としてWebPを位置づけている点も特徴です^*1。写真とアイコンを同じ設定で一律に圧縮すると、どちらか一方で画質劣化かサイズ超過が起こりやすくなります。

圧縮品質の値は代表サンプルで検証してから決める

Android公式は、圧縮品質の設定について、サムネイル用途では品質35%程度、標準的な表示用途では75%程度を目安として挙げつつ、画像ごとに劣化の見え方が異なるため代表的なサンプルで検証したうえで値を決める必要があるとしています^*1。一律の数値を全画像に適用するのではなく、写真・イラスト・スクリーンショットなど画像の種類ごとに検証する工程を挟むことが望ましいでしょう。

サーバー側リサイズとCDN配信で転送量を削る

フォーマットや圧縮の工夫だけでは、根本的な転送量の問題は解決しません。端末側でリサイズする方式ではなく、サーバー側で用途に応じたサイズをあらかじめ用意しておく設計が必要です。

単一解像度をサーバーに置く方式の問題点

Android公式ドキュメントは、サーバーに単一解像度の画像だけを保存し、端末側でスケールダウンして表示する方式について、ユーザーに不要なデータのダウンロードを強いる設計だと指摘しています^*1。一覧のサムネイル表示にフルサイズ画像を使い回すと、実際に画面に表示される面積の何倍ものデータを毎回転送することになりかねません。

複数解像度を用意しキャッシュを備えたバックエンド画像サービスで配信する

推奨されるのは、複数解像度の画像バリアントをサーバー側で用意し、サムネイル・一覧・詳細画面それぞれの用途に応じたサイズを配信する設計です^*1。Android公式は、こうした配信を実現する手段として、リサイズ機能とキャッシュ機能を備えたバックエンド画像サービスの活用を挙げています^*1。CDN（コンテンツ配信ネットワーク。地理的に分散したサーバー群経由でコンテンツを配信する仕組み）を経由させると、画像処理の負荷分散に加えて、ユーザーの利用地域に近い拠点から配信できるため、転送にかかる時間の短縮も期待できます。

自社でサーバー側リサイズ基盤を持つには相応の設計知識が要る

サーバー側リサイズとCDN配信を自前で構築するには、画像変換処理の実装に加え、キャッシュの無効化戦略、オリジン（元画像の保管場所）とCDNエッジの整合性維持といった運用設計の知識が必要です。既存のクラウドサービスが提供する画像変換・配信機能を利用する選択肢もありますが、料金体系や対応フォーマットの範囲を要件と照らし合わせて選定する判断が求められます。

外注時に確認すべき計測方法と引き継ぎの論点

画像最適化の実装をアプリ開発会社に外注する場合、体感速度の改善が実際に効果を上げたかを確認する計測の仕組みまで含めて発注範囲を確認しておく必要があります。

自社で内製するには何が必要か

画像最適化を内製で行うには、遅延読み込み・キャッシュ設計・フォーマット変換・サーバー側配信という4つの領域それぞれの知識に加え、実機での計測・検証を担える人材が必要です。特にキャッシュ設計はメモリとディスクの両方にまたがる領域のため、片方だけを実装して満足してしまうと、想定した速度改善が出ないまま工数だけがかかる事態になりかねません。社内にモバイルアプリの画像処理を専門に扱うエンジニアがいない場合、要件定義の段階で対応範囲を明確にしておくことが実務上重要です。

発注先に計測方法を具体的に確認する

提案書に「画像を最適化します」とだけ書かれている場合、どの指標をどう計測するのかまで確認する必要があります。画面表示までの時間、スクロール中のフレーム落ち、メモリ使用量の推移など、改善前後で比較できる指標を発注前の打ち合わせで具体的に質問し、回答の解像度を見ることが技術力を見極める手がかりになります。実機、それも低スペック帯の端末での検証を計画に含めているかどうかも確認しておきたい点です。

圧縮設定と配信基盤の引き継ぎ範囲を契約に明記する

開発会社との契約が終了した後、別の会社に保守を引き継ぐ可能性がある場合は、採用したフォーマットごとの圧縮品質設定、キャッシュの有効期限設計、CDN・画像配信サービスの設定情報を納品物に含めるよう契約段階で明記しておく必要があります。これらの資料がないまま引き継ぐと、後任の開発会社が既存の画像処理パイプラインを解析するところから作業を始めることになり、追加の調査コストが発生しかねません。

画像最適化の技術選定そのものを丸投げにせず、自社側が最低限の論点を把握したうえで発注先と対話する体制を整えることが、外注を成功させる実務上のポイントです。

まとめ：画像の表示速度を機能させる3つの判断軸

本稿では、アプリの画像最適化と読み込み高速化における遅延読み込み・キャッシュ設計・フォーマット選定・サーバー側配信の勘所を整理しました。要点を3つに集約すると次の通りです。第一に、画像の体感速度は遅延読み込み・キャッシュ・フォーマット・配信という役割の異なる4つの技術要素の組み合わせで決まり、単一の打ち手だけでは不十分だという点が挙げられます。第二に、フォーマット選定と圧縮品質は写真・イラストなど画像の種類ごとに検証する必要があり、一律の設定では画質劣化かサイズ超過のどちらかが起こりやすいことです。第三に、外注する場合も計測方法と引き継ぎ資料の範囲を発注前に確認する姿勢が、改善効果の検証と長期的な保守性の両方を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Reduce image download sizes」（Android Developers）https://developer.android.com/develop/ui/views/graphics/reduce-image-sizes
2. *2　出典：Apple「Asynchronously loading images into table and collection views」（Apple Developer Documentation）https://developer.apple.com/documentation/uikit/asynchronously-loading-images-into-table-and-collection-views
3. *3　出典：Google「Lazy-loading images」（web.dev）https://web.dev/articles/lazy-loading-images
4. *4　出典：Google「Manage bitmap memory」「Caching bitmaps」（Android Developers）https://developer.android.com/topic/performance/graphics/cache-bitmap
5. *5　出典：Google「A new image format for the Web」（WebP公式）https://developers.google.com/speed/webp

Tweet