なぜ120Hzでもカクつく？

まず、同じ処理を120Hzにしてみる

初期状態の60Hzでは、メイン処理8ms・GPU 3ms・合成1msの合計12msが、約16.7msの予算に収まります。120Hzに切り替えると予算は約8.3msになり、同じ処理が締切を超えます。これらの処理時間は説明用の仮定です。特定のチップを計測した値ではありません。

次に、120Hzのままメイン処理を1msへ下げてみてください。合計5msが予算内に収まり、表示までの遅延も短くなります。120Hzが遅いのではなく、高い更新頻度を活かすには各フレームを短時間で準備する必要があります。描画時間とリフレッシュレートの関係（出典1）

入力が、そのまま画面に出るわけではない

入力を受けたアプリは、メインスレッドで状態やレイアウトを更新します。その結果を描画し、画面の各レイヤーを合成して、表示のタイミングを待ちます。AndroidのSurfaceFlingerはバッファを受け取り、合成してディスプレイへ送ります。合成処理の役割（出典3）

VSyncの縦線は表示更新の区切りです。締切の直後に準備が終わっても、このモデルでは次のVSyncまで表示を待ちます。Appleの描画ループにも複数の段階と締切があり、処理が間に合わなければ画面の動きが一時的に途切れる「hitch」が生じます。Appleの描画ループ（出典2）

実機では別々のフレームを並列に処理し、バッファを使って受け渡します。この図は締切と待ち時間を理解するため、1枚を表示してから次の入力を受け取る直列モデルです。走査時間、入力の待ち行列、可変リフレッシュレートは再現しておらず、実際のFPSや入力遅延の予測には使えません。

平均が同じでも、止まり方は違う

説明用にメイン処理の3フレームを考えると、6・6・6msも、0・0・18msも平均は6msです。後者は1枚だけ重い処理が集中します。このモデルのGPU・合成分を加えると、60Hzでは前者はすべて間に合い、後者は1回の表示更新を逃します。平均のベンチマーク値だけで、その偏りは判断できません。

図の「ドロップ（更新なし）」は、新しい画面を出せず前の画面を保ったVSyncの数です。遅れたフレーム自体を破棄した数ではありません。長い停止が複数の締切をまたぐと、締切超過が1枚でも更新なしは複数回になります。表では各フレームの入力・締切・表示時刻を確認できます。

一時停止は、GCだけが原因ではない

「一時停止を挿入」は3枚目に12msの説明用待ち時間を加えます。これはGCの標準的な停止時間ではありません。重い同期処理など、メインスレッドを長く占有する仕事も描画を遅らせます。メインスレッドと応答性（出典4）

GCは不要になったオブジェクトを回収する仕組みで、発生タイミングや処理量はアプリの割り当て方などに左右されます。停止トグルだけから、Android全体の滑らかさを決めることはできません。メモリ管理とGC（出典5） GCとARCのメモリ管理モデルで、解放のタイミングの違いも確かめられます。

iOSとAndroidを、ひとつの設定値で比較しない

比較すべきなのは、描画経路の各段階をいつ実行し、どの仕事を優先する設計か、そして端末とアプリに合わせた調整です。Androidにもメインスレッドの優先度や処理の分離があり、iOSにもアプリ側と描画側それぞれの締切があります。Androidのスレッド設計（出典4）、Appleの描画段階（出典2）

最新のハイエンド機でも、OS名だけでは同条件での差を説明できません。「両OSの差が縮まった」という世代間の評価には、端末・アプリ・負荷を揃えた実測が必要です。ここで参照した資料は仕組みの説明であり、その比較実験ではありません。このモデルにはOS別の遅延設定を置いていません。

購入時は、ピーク値の次に確かめる

• よく使うアプリやゲームが、そのリフレッシュレートに対応しているか。
• 平均スコアだけでなく、重い場面のフレーム時間や長時間使用時の安定性を確認できるか。
• 測定に使った端末・設定・温度条件が、自分の使い方に近いか。

出典付きのチップ比較へ戻るときも、CPUやGPUの構成差だけから滑らかさを断定せず、実機と計測条件を一緒に確認してください。