開発におけるモツモツ—その正体、原因、および最適化方法

モバイル開発における“モツモツ”とは

モツモツは、ユーザーが主観的に遅いアプリケーションを記述するために使用する非正式な用語です。一定の遅延として現れるラグとは異なり、モツモツは不規則なフリーズから構成されます：アプリは数秒間完璧に動作したあと、突然1–3秒間“考えて”いるようになることがあります。

現象の技術的説明

プロファイリングの観点からは、モツモツは、ピーク遅延が100msを超える一連のフレームドロップ（jank）として現れます。FPSグラフでは、これは急激なドロップとして見えます：60→20→55→10フレーム/秒。一定的にFPSが低いラグとは異なり、モツモツには時間変動があります。

ユーザーの知覚

アプリがモツモツすると、ユーザーには遅くなった理由がわかりません。画面が滑らかにスクロールしていたかと思うと、突然一秒間停止することがあります。これは節になるもので、アプリへの信頼を損ないます。Googleによると、ローディングに3秒以上かかる場合、53%のユーザーがサイトまたはアプリを離れます。

アプリにおける突然の動作遅延の原因

モツモツの閃発的性質は、問題が一定的な過負荷ではなく、イベント驅動因子によって引き起こされていることを示しています。具体的なシナリオを見てみましょう。

オブジェクト割り当て時のGCポーズ

AndroidのARTランタイムでは、ガベージコレクションはすべてのアプリスレッドを停止します。コードが多くの一時オブジェクトを作成する場合、例えば毎回のonBindViewHolderコールで結合によって新しいStringを作成する場合、GCはより頻繁に実行されます。ポーズは、ヒープサイズとオブジェクトの生成世代によって、5–50msの間続することがあります。ユーザーはこれを突然の“考え深げ”として感知します。

UIスレッドでの同期SQLクエリ

AndroidのRoomやiOSのCore Dataは非同期クエリをサポートしていますが、開発者はよく簡単さのためにgetValue()を呼んだり、runBlockingを介してクエリを実行したりします。10,000行のテーブルに対するJOINを伴う重いSELECTは200–500msかかり、その間UIを完全にブロックします。

縮小なしの画像デコード

カメラ画像(12MP、4000x3000px)を縮小せずにロードすると、Bitmapへのデコードに200msまでかかります。画像を非同期的にロードしていても、制限のないスレッドプールを使用している場合、5–6のデコードを同時実行するとCPUに過負荷がかかり、移動的な動きの遅さが生じる可能性があります。

• Android — ループ内での文字列結合、ホットパスでのオブジェクト生成、inSampleSizeなしのBitmap
• iOS — 多くのオブジェクトを含むオートリリースプール、縮小なしのimageWithContentsOfFile、同期URLSession
• クロスプラットフォーム — UIスレッドでのJSON解析、サーバー応答を待つ間のメインスレッドでのデータ読み込み

AndroidおよびiOSでのフリーズの診断方法

閃発的な動作遅延の診断は、一定的なラグの診断よりも難しいです。なぜなら、問題が毎回の実行で再現するとは限らないからです。長期的な統計データの収集が必要です。

GCイベント記録付きMemory Profiler

Android Studio Memory Profilerは、メモリ使用量だけでなく、GCイベント（頻度、タイプ（Concurrent、Full）、期間）も表示します。アイドル状態で5秒に1回以上GCが発生する場合から、これは過剰な割り当てのサインです。モツモツの瞬間にヒープダンプを取ると、どのオブジェクトがメモリを占用しているかがわかります。

Allocation Tracking付きXcode Instruments

iOSでは、InstrumentsのAllocationsテンプレートを使用して、オブジェクトの作成と解放をトレースします。Generationsを有効にすると、アクションの間にヒープのスナップショットを取り、メモリに残っているオブジェクトを確認できます。解放されない永続オブジェクトは、メモリの蓄積とその後のポーズの原因となります。

AndroidのJankStats API

JankStatsは、リアルタイムでフレームドロップメトリクスを収集するAndroidライブラリです。各jankを現在のシナリオ（例えば「リストスクロール」「画面開封」）に結びつけることで、どのアクションがモツモツを引き起こすのかを特定できます。

AndroidでJankStatsを組み込んでフリーズをトレースする例：

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

動作が遅いアプリを改善する方法

モツモツを解消するには、各原因に対して目的を持った取り組みが必要です。万能の解決策はありません。診断には、個々のパフォーマンスプロファイルの解析が必要です。

Paging 3によるページネーションの導入

リストに1000+の項目があり、すべてを一度にロードする場合、それは確実にモツモツを引き起こします。AndroidのPaging 3やiOSのNSFetchedResultsControllerは、ユーザーがスクロールするにつれデータを分割って読み込みます。ユーザーには最初の10–20項目のみが表示され、残りはバックグラウンドで読み込まれます。

SQLクエリとインデックスの最適化

Roomは、Android StudioのInspection Toolを介してクエリのプロファイリングを可能にします：実行時間、戻された行数、クエリプランが表示されます。WHEREやORDER BY列にインデックスを追加すると、クエリ時間を300msから5msに減らせます。iOSでは、InstrumentsのCore Data Profilerが同様の検査を行います。

WorkManagerへのタスクの移行

バックグラウンド同期、ファイルダウンロード、データ処理—これらはすべてWorkManager（Android）またはBackground Tasks（iOS）を介して実行すべきです。同期がUIスレッドで実行される場合、実行中にアプリがモツモツします。WorkManagerは、バッテリーおよびネットワークの状態を考慮した上で、バックグラウンドスレッドでの実行を保証します。

AndroidでWorkManagerを介したバックグラウンド同期の例：

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("シンク", "バックグラウンドスレッドでデータをシンク中")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

開発階階でのモツモツ予防

効率的なメモリおよびスレッド管理の原則に従うことで、コーディング階階でモツモツを予防できます。

AOTコンパイルのためのBaseline Profiles

Baseline Profilesは、AndroidがJITではなく事前にコンパイル（AOT）するクラスとメソッドのリストです。プロファイルがない場合、新しい画面は初回開いた時にコンパイルされ、100–500msの遅延が生じます。主な画面のBaseline Profileを作成し、baseline-profile-gradle-pluginを介してGradleで生成を有効にします。

ホットパスでの割り当ての最小化

ホットパスは、毎フレームで実行されるコードです：onBindViewHolder、draw、layoutSubviews。これらのメソッドでオブジェクトを作成するのを避けます：オブジェクトプールを使用し、結合の代わりにStringBuilderを使用し、フォーマットされた文字列とフォーマッターをキャッシュします。余計な割り当ては次のGCを近づけます。

CIでのBaseline Profilesによるプロファイリング

CIパイプラインに、リストスクロールと画面開封のシナリオを含むMacrobenchmarkを追加します。スレッショルドを設定します：フレーム時間の99パーセンタイルは16msを超えないものとします。この値を超えた場合、ビルドは最適化が完了するまで拒否されます。

• Android — Baseline Profiles、Macrobenchmark、JankStats、penaltyDeath付きStrictMode
• iOS — MetricKit、os_signpost、XCTMetric、DebugスキームのMain Thread Checker
• 一般的なアプローチ — 定期的なプロファイリング、ホットパスでの割り当てに注目したコードレビュー