アプリが原因不明のクラッシュ（OOM: Out of Memory）を起こし、ユーザーレビューが荒れる。ログには何も残っていない。これはiOS開発者が直面する最悪の悪夢です。私はかつて、画像処理アプリでわずか10分間のスクロール後にクラッシュするバグに3日間悩まされました。原因は、たった一行のクロージャによるSwift循環参照（Retain Cycle）でした。この記事では、私が本番環境で実際に使用しているXcode Instrumentsによる解析手法と、メモリリークを根絶するための修正コードを共有します。
1. なぜ「ARC」環境でもリークするのか？
iOSのメモリ管理システムであるARC（Automatic Reference Counting）は優秀ですが、万能ではありません。特に「循環参照」が発生した場合、ARCは無力化されます。これは、2つのオブジェクトが互いを「強く（Strong）」参照し合い、永遠にメモリ解放されなくなる状態です。
- 画面を閉じてもメモリ使用量が下がらない（Allocationsが増え続ける）。
- 特定の操作を繰り返すとアプリが重くなる（iOSパフォーマンスの低下）。
- バックグラウンド移行時やメモリ警告時にクラッシュする。
2. 犯人を特定する：Instruments vs Memory Graph
多くの開発者がいきなりコードを見直そうとしますが、それは時間の無駄です。まずは計測です。
Step 1: Memory Graph Debugger（最速の一次診断）
Xcodeに標準搭載されている「Memory Graph Debugger」は、視覚的に循環参照を見つけるのに最適です。
- アプリを実行し、リークが疑われる画面に遷移してから戻る操作を行います。
- Xcode下部のデバッグバーにある「3つの丸が繋がったアイコン」をクリックします。
- 左側のナビゲーターで、本来存在しないはずのViewControllerやクラスが残っていないか確認します。
- もし紫色の「！」マークが表示されていれば、Xcodeが循環参照を自動検知しています。
Step 2: Xcode Instruments（詳細解析）
Memory Graphで見つからない「隠れリーク」や、画像データなどの「肥大化」にはInstrumentsを使います。
- Leaks: 参照カウントがおかしいオブジェクトを自動検出（赤色のバツ印が表示されます）。
- Allocations: メモリ使用量の推移をグラフ化。画面を閉じたのにグラフが下がらない場合、そこでリークが起きています。
MyApp）を入力してください。システムライブラリのノイズが消え、自作クラスのインスタンス数だけを追跡できます。画面を閉じた後に「Persistent」カウントが0に戻らなければ、それがリーク源です。
3. 修正パターン：[weak self] の正しい使い方
最も一般的な原因は、クロージャ（Closure）内でのselfの強参照です。以下に、本番コードでよくある間違いと修正版を示します。
❌ 悪い例：典型的な循環参照
class UserProfileViewController: UIViewController {
var onUpdate: (() -> Void)?
func fetchData() {
// selfがクロージャを保持し、クロージャがselfを保持している
// 結果：相互に離さない「デッドロック」状態
APIClient.shared.getProfile { result in
self.updateUI(with: result)
self.showSuccessMessage()
}
}
}✅ 修正例：weak self + guard let
[weak self]を使用し、クロージャ内で一時的に強参照に戻すパターン（Dance of the Weak-Strong）が鉄板です。
class UserProfileViewController: UIViewController {
func fetchData() {
// [weak self] で循環を断ち切る
APIClient.shared.getProfile { [weak self] result in
// selfが解放済みならここで処理を終了
guard let self = self else { return }
// ここでは self は安全に強参照として扱える
self.updateUI(with: result)
self.showSuccessMessage()
}
}
}unowned self は使わないでください。unownedは参照先が解放された後にアクセスすると即クラッシュします。現代のiOS開発において、わずかなパフォーマンス差のためにunownedのリスクを冒す価値はほとんどありません。常にweakを使用し、Optional Bindingで安全に処理するのがアプリデバッグの定石です。
4. 見落としがちなリークポイント
クロージャ以外にも、iOSメモリリークの温床となるパターンがあります。
| パターン | 解説 | 対策 |
|---|---|---|
| Delegate | プロトコル準拠のプロパティがweakでない場合、親子間で循環参照が発生する。 |
weak var delegate: SomeDelegate? とする。 |
| Timer | Timer.scheduledTimerはターゲット（self）を強参照する。 |
invalidate()を必ず呼ぶか、ブロックベースのTimerで[weak self]を使う。 |
| Lazy Var | 遅延初期化プロパティ内のクロージャでselfを参照すると循環する。 |
クロージャ定義の冒頭に[unowned self]または[weak self]を追加する。 |
特に危険な Lazy Property の例
// これもリークします
lazy var updateHandler: () -> Void = {
self.doSomething() // 暗黙的にselfをキャプチャ
}
// 修正版
lazy var updateHandler: () -> Void = { [weak self] in
self?.doSomething()
}結論
iOSメモリリークの修正は、単なるバグ修正ではなく、アプリの寿命を延ばすための必須のメンテナンスです。InstrumentsやMemory Graph Debuggerを使いこなし、[weak self]を呼吸するように書く習慣をつけてください。メモリ管理が適切に行われているアプリは、古いデバイスでもサクサク動き、ユーザーからの信頼を勝ち取ることができます。
Post a Comment