導入：「通信が遅い」と言われた瞬間に頭が真っ白になる
テスト担当やクライアントから、突然こう言われます。
「この画面、通信が遅くないですか？」
「前よりモッサリしてる気がします」
ここでありがちなのが、
「サーバーが悪いんじゃ…？」で思考停止するパターン。
結論から言うと、Android側だけで原因が完結しているケースはかなり多いです。
この記事では、
「通信が遅い」と言われたときにAndroidエンジニアが順番に見るべき場所を、
チェックリスト形式で整理します。
先に結論です。
- まず「本当に通信が遅いのか」を切り分ける
- 次にOkHttp / Retrofitの設定を見る
- 最後にUIスレッド・実装ミスを疑う
まず最初にやること：本当に「通信」が遅いのか？
ここ、かなり重要です。
体感で「遅い」と言われても、
実際に遅いのが通信とは限りません。
よくある勘違い
- 通信後のJSONパースが重い
- 画像読み込みで止まっている
- UIスレッドで重い処理をしている
まずは、通信開始〜レスポンス受信までの時間をログで分けます。
// リクエスト開始時間
val start = System.currentTimeMillis()
// APIコール
api.getUser()
// レスポンス受信
val elapsed = System.currentTimeMillis() - start
Log.d("API", "通信時間: ${elapsed}ms")
ここで速いなら、「通信は速い」です。
チェック① OkHttpの設定を見る
通信系で一番多い原因は、
OkHttpのデフォルト設定のまま使っているケースです。
タイムアウト設定
val okHttpClient = OkHttpClient.Builder()
.connectTimeout(10, TimeUnit.SECONDS)
.readTimeout(10, TimeUnit.SECONDS)
.writeTimeout(10, TimeUnit.SECONDS)
.build()
タイムアウトが長すぎると、
「待たされている感」が強くなります。
Interceptorが増えすぎていないか
ログ用・認証用・共通ヘッダ用など、
Interceptorを盛りすぎると確実に遅くなります。
Retrofit / OkHttp の安定構成については、
以下の記事で詳しく書いています。
Retrofit・OkHttpを使ってAPI通信を安定化させるベストプラクティス
チェック② Retrofitの使い方
毎回インスタンスを作っていないか
画面ごとに Retrofit を new していると、
接続確立コストが毎回かかります。
Retrofit / OkHttpClient は基本シングルトンです。
レスポンスをそのままUIで処理していないか
巨大なレスポンスを受け取って、
そのままUIスレッドで処理すると体感は最悪になります。
チェック③ 通信スレッドとUIスレッド
「通信が遅い」と言われる原因の中で、
実はかなり多いのがこれです。
onResponseで重い処理をしている
override fun onResponse(...) {
// JSON整形・DB保存・リスト生成など
}
ここで重い処理をすると、
通信完了後に固まって見えるだけです。
チェック④ 画像・ファイル通信
APIは速いのに画面が遅い場合、
画像読み込みが原因のことも多いです。
- 画像サイズが大きすぎないか
- キャッシュが効いているか
- 毎回DLしていないか
チェック⑤ 実機・回線依存の確認
エミュレータは参考程度にしましょう。
- 低速回線（4G）
- 古い端末
- バックグラウンド通信が多い端末
このあたりで試すと、
「特定条件だけ遅い」問題が見つかります。
デバッグ用チェックリスト（保存版）
- 本当に通信時間が遅いか計測したか
- OkHttpのtimeout設定は適切か
- Interceptorを盛りすぎていないか
- Retrofitを使い回しているか
- 通信後の処理が重くないか
- 実機・低速回線で確認したか
よくある質問
Q. サーバー側に原因がある場合は？
もちろんあります。ただし、
Android側の切り分けをしてから話すと調査が一気に進みます。
Q. 「体感が遅い」と言われたら？
ログ・時間計測で数値を出しましょう。
感覚の話から、事実の話に変えられます。
まとめ
- 「通信が遅い＝APIが遅い」とは限らない
- OkHttp / Retrofitの設定は最初に見る
- 通信後の処理こそ要注意
迷ったら：まず時間を測る。
これだけで無駄な調査を減らせます。
コメント