パフォーマンスと安定性

アプリの「重い・遅い」は、端末や OS によって大きく違います。手元の新しい端末では再現しないことが多いので、本番の数字と、遅い端末での再現から始めます。

報告は「起動時間（コールドスタート）の p90 が 2.8 秒 → 1.6 秒。原因は起動時の分析 SDK の初期化」のように、指標・前後の数字・原因をセットにします。

起動の速さは、アプリの第一印象と継続率に直結します。起動には3種類あり、改善の中心は一番遅いコールドスタートです。

コールドスタートの計測

• Android：adb shell am start -S -W パッケージ名/.MainActivity（-S で先に止めてから起動）で TotalTime を見られます。これは最初の1コマまで（TTID）で、データが出て使えるようになるまで（TTFD）を計るには reportFullyDrawn() を呼びます。継続して計るなら Macrobenchmark の StartupTimingMetric。Play Console の Android vitals は、コールドスタート 5 秒以上・ウォームスタート 2 秒以上・ホットスタート 1.5 秒以上を「遅すぎる」としています（TTID で計る）。
• iOS：Xcode の Organizer で、実際の利用者の起動時間の分布を見られます。アプリの中からは MetricKit で集められます。Apple は WWDC 2019 の講演「Optimizing App Launch」で、最初の1コマを 400ms 以内に描くことを目標に挙げています。また、起動に長くかかりすぎると OS にアプリを終了させられます。

計るときは、リリース版・性能の低い実機・何回か計った中央値で比べます。デバッグ版やシミュレーターの数字は当てになりません。

遅いと分かったら、推測で直さず、プロファイラーで何に時間がかかっているかを見ます。

何に時間がかかっているかは、プロファイラーで見ます。iOS は Instruments の App Launch や Time Profiler、Android は Android Studio の Profiler（CPU の記録）や Perfetto でトレースを取ります。よく見つかる原因は次のとおりです。

スクロールやアニメーションのカクつきは、1コマの描画が時間内に終わらないことで起きます。

描画は、60Hz の画面なら 1 コマ 16.7ms、120Hz なら 8.3ms に収まらないとカクつきます。一覧のスクロールのもたつきも、同じプロファイラーでメインスレッドの重い処理を探します。

Android は Play Console の Android vitals で遅いフレームの割合を、iOS は Xcode Organizer でスクロールのもたつき（Hitch rate）を、実際の利用者のデータで見られます。

スマホはメモリが少なく、使いすぎると OS にアプリを終了されます（iOS では Jetsam、Android では Low Memory Killer）。電池も、使いすぎると利用者に消されたり、OS に裏の動きを止められたりします。

循環参照

Swift は参照の数を数えてメモリを解放します（ARC）。2つのものがお互いを強く持ち合うと数が 0 にならず、ずっと解放されません。これが循環参照です。よくあるのは、ViewModel が持つクロージャーの中で self を強く持つ形です。

api.onUpdate = { [weak self] value in
  self?.items = value     // weak にしないと self とクロージャーが持ち合う
}

デリゲートは weak var delegate にします。見つけるには Xcode の Memory Graph Debugger や Instruments の Leaks を使います。Android（Kotlin）はガベージコレクションなので持ち合いは解放されますが、寿命の長いもの（シングルトンや static）が Activity や Context を持ち続けると漏れます。LeakCanary を入れると、デバッグ中に漏れを知らせてくれます。

電池を減らすアプリは、利用者に消されるだけでなく、OS にも裏の動きを止められます。iOS も Android も、裏の処理に強い制限をかけています。

電池を減らすコツは、通信をまとめて送る、位置情報は必要な精度と頻度だけにする、裏でのポーリングをやめてプッシュにする、ことです。Android Studio の Energy の表示や Xcode の Energy の項目で確かめます。

Android の WorkManager では、最小の間隔が15分の定期の処理や、「Wi-Fi のとき」「充電中」などの条件を付けた処理を頼めます。実行の時刻は OS が決めるので、ずれる前提で使います。

アプリのメモリ不足の原因で一番多いのが画像です。画像は表示のときに縦 × 横 × 4バイト（色の情報）に広げられるので、ファイルが小さくても、ピクセル数が多いとメモリを大きく使います。

Android の Coil・Glide、iOS の Kingfisher・SDWebImage などのライブラリは、これらをまとめてやってくれます。iOS で自前で縮めるなら、ImageIO の縮小画像の作成（CGImageSourceCreateThumbnailAtIndex）を使うと、元の大きさに広げずに縮められます。

アプリのサイズが大きいと、ダウンロードをやめる人が増え、端末の容量が少ない人には入れてもらえません。ストアで見えるダウンロードの大きさと、入れた後の大きさの両方を見ます。

大きくなる原因の多くは、ライブラリ（特に広告・分析の SDK）と画像・動画・フォントです。プルリクエストごとにサイズを記録して、急に増えたら気づけるようにしておくと、後から削るより楽です。

アプリは一度落ちると、利用者の評価やストアの順位にすぐ響きます。サーバーと違って手元でログを見られないので、落ちた情報を集める仕組みが必須です。

Crashlytics など

Firebase Crashlytics や Sentry などの SDK を入れると、落ちたときのスタックトレース（どの関数で落ちたか）・機種・OS の版・アプリの版が集まります。ストアの管理画面（App Store Connect・Xcode Organizer、Play Console）でも見られます。

目安として、クラッシュしなかった利用者の割合（クラッシュフリーユーザー率）は 99.9% 前後を目標にするチームが多いです。

落ちてはいないが画面が固まって動かない状態も、利用者にとってはクラッシュと同じくらい悪い体験です。

ANR（Application Not Responding）は Android の「アプリが応答していません」のことで、メインスレッドが長く止まると起きます。タップなどの入力に 5 秒ほど応答しないのが代表的な条件です。原因は、メインスレッドでの DB・ファイル・通信、ロックの待ち、重い計算です。iOS でも同じようにメインスレッドが止まると「ハング」として記録され、起動などで長く止まると OS にアプリを終了させられます。

Google Play は、実際の利用者の端末から集めた品質の数字を Android vitals として見せ、悪いアプリはストアで不利になるようにしています。

Google Play は Android vitals で、利用者が気づいたクラッシュ率と ANR 率に基準を設けています（全端末の平均でクラッシュ率 1.09%・ANR 率 0.47%、機種ごとではどちらも 8%。直近 28 日の平均で判定）。基準を超えると、ストアで見つけてもらいにくくなったり、ストアのページに警告が出たりします。App Store にはこうした公開の基準はありませんが、落ちるアプリは低い評価やレビューにつながります。新しい版を出したら、最初の数日はこれらの数字を毎日見ます。

アプリは一度配ると古い版が長く残るので、遅くなる変更を出す前に気づく仕組みが大事です。

SDK（広告・分析など）を足すときは、起動時間とサイズへの影響を計ってから入れる決まりにしておくと、少しずつ重くなるのを防げます。