メモリリークと肥大化 — その原因と回避方法

メモリリークとアプリの肥大化とは？

メモリリーク — アプリに不要になったオブジェクトが、GCルートセットからのアクティブな参照がまだ存在するためにヒープに保持され続ける状態。ガベージコレクタはそのようなオブジェクトを生存していると見なし、削除しません。

メモリ肥大化 — アプリが現在のタスクを実行するために必要な以上にメモリを消費する、より広範な問題。原因：過剰なキャッシュ、オブジェクトの重複、非効率なデータ構造、ヒープの断片化。

Androidでは、各アプリに制限付きのヒープが割り当てられます（通常、デバイスとOSバージョンに応じて64–512MB）。iOSでは制限はそれほど厳しくありませんが、上限に近づくとシステムがメモリ警告を送信します。

Facebook Engineering Blogによると、メモリリークはモバイルアプリのクラッシュレポートの約15%を占めています。Androidでは、メモリ不足時の頻繁なGCポーズによるANRも加わります。

AndroidとiOSにおける一般的なメモリリークパターン

Activityへの静的参照 — 古典的なAndroidリーク。静的フィールドやシングルトンがActivityへの参照を保持している場合、シングルトンが生存している限り、finish()後もGCによって収集されません。Activityはビュー階層、リソース、Contextを含む重いオブジェクトです。

object LeakHolder {
    var activityRef: Activity ?= null // leak: static reference to Activity
}

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        LeakHolder.activityRef = this // ❌ MainActivity will never be GC'd
    }
}

匿名クラスとラムダ — 外部クラスへの参照を暗黙的に保持します。RunnableやCallbackが外部サービスに渡され、Activityが破棄された場合でも、匿名クラスのオブジェクトはキューに残り、Activityのガベージコレクションを妨げます。

• Handlerと遅延 — Activityが破棄されたがHandler.postDelayedがまだ実行されていない場合、Activityがリークする
• ThreadとAsyncTask — 画面回転時にActivityは再作成されるが、古いThreadは古いActivityへの参照を保持し続ける
• Retrofit/Callback — 匿名Callbackがプレゼンターやフラグメントへの参照を保持する
• オブザーバー — onDestroyで購読解除しないLiveDataやRxJavaのサブスクリプション

iOSでは、主な問題はリテインサイクルです：2つのオブジェクトが互いに強参照を保持し、ARCがいずれの参照カウントもゼロにできません。典型的なケース：selfを強くキャプチャするクロージャと、クロージャへの参照を保持するself。

メモリリークを検出する方法

LeakCanary — Androidでの自動リーク検出のためのSquareのライブラリ。ActivityやFragmentが破棄された後、オブジェクトがGCによって収集されたかどうかを確認します。収集されていない場合、ヒープダンプを取得し、リークトレースを表示します。

// LeakCanary 2.x — auto-integration via Application
class ExampleApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // LeakCanary auto-installs in debug build
        // via ContentProvider — zero code setup
    }
}

// Force check invocation
AppWatcher.objectWatcher.watch(watchedObject, "leak description")

Android Studio Profiler — リアルタイムメモリ監視のための組み込みツール。ヒープダンプの記録、疑わしいオブジェクト（Retained Size > 1MB）の発見、各オブジェクトへのGCルートパスの追跡が可能です。

iOSにはXcode Memory Graph Debuggerを使用します。メモリ内のオブジェクトグラフを可視化し、リテインサイクルを表示し、循環参照を即座に検出できます。Instruments > Allocationsも長期監視に利用可能です。

防止戦略

WeakReference — ガベージコレクションを妨げるべきでない参照のための基本メカニズム。GCがオブジェクトを収集することを決定した場合、WeakReferenceはnullを返します。コールバック、リスナー、バックグラウンドスレッドからのUIコンポーネントへの参照に使用されます。

Lifecycle-awareコンポーネント — Android Jetpack（Lifecycle、LiveData、Flow、coroutines）で実装されたアーキテクチャアプローチ。サブスクリプションはonDestroyで自動的にキャンセルされ、主要なリーククラスを排除します。

class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<List<User>>()
    val data: LiveData<List<User>> get() = _data

    fun loadData() {
        viewModelScope.launch {
            val result = repository.fetchData()
            _data.postValue(result)
            // coroutine auto-cancels on onCleared()
        }
    }
}

viewModelScopeとlifecycleScope — Androidに組み込まれたCoroutineScopeで、対応するライフサイクルイベントでキャンセルされます。これにより、現代のAndroid開発で最も一般的なシナリオであるコルーチンを介したリークを排除します。

• 使用しない：Context、Activity、View、Fragmentへの静的参照
• キャンセルする：onDestroyでdisposeBag / CompositeDisposable内のすべてのRxJavaサブスクリプション
• 使用する：iOSクロージャで[weak self] / [unowned self]によりリテインサイクルを防止
• 確認する：Bitmapや大きなオブジェクトはリサイクルまたはnull化する必要がある

メモリプロファイリングツール

Android StudioのMemory Profiler — ヒープ監視のための主要ツール。ライブアロケーション、ヒープスナップショット、タイプ別のオブジェクト数を表示します。ダンプを記録し、MAT（Memory Analyzer Tool）で分析して疑わしいオブジェクトを見つけることができます。

Eclipse MAT — デスクトップヒープダンプアナライザ。Android StudioからHPROFファイルをロード後、MATは支配ツリーを構築し、各オブジェクトのretainサイズを表示し、Leak Suspects Reportを通じて自動リーク分析を提供します。

Xcode Memory Graph — ビジュアルリテインサイクルデバッガ。Memory Graph Debuggerボタンをクリックすると、Xcodeはアプリを停止し、メモリ内の完全なオブジェクトグラフを構築し、リテインサイクルを赤色で強調表示します。

Google I/O 2023によると、デバッグビルドでLeakCanaryを使用するアプリは、導入後最初の2ヶ月でメモリ関連のクラッシュが30–50%減少します。プロジェクトのオンボーディング段階でLeakCanaryを追加することを推奨します。