ヒープメモリの分析

ヒープメモリの分析

アプリのダイナミックメモリであるヒープの基本を解説します。InstrumentsとXcodeを使用して、ヒープに関する一般的な問題を測定、分析、修正する方法を確認しましょう。一時的な増加、永続的な増加、リークをアプリで診断するための手法とベストプラクティスもご紹介します。

関連する章
- 0:00 - Introduction
- 1:05 - Heap memory overview
- 3:45 - Tools for inspecting heap memory issues
- 7:40 - Transient memory growth overview
- 10:34 - Managing autorelease pool growth in Swift
- 13:57 - Persistent memory growth overview
- 16:00 - How the Xcode memory graph debugger works
- 20:15 - Reachability and ensuring memory is deallocated appropriately
- 21:54 - Resolving leaks of Swift closure contexts
- 24:13 - Leaks FAQ
- 26:51 - Comparing performance of weak and unowned
- 30:44 - Reducing reference counting overhead
- 32:06 - Cost of measurement
- 32:30 - Wrap up
リソース
関連ビデオ

WWDC24
- Swiftでのコピー不可な型の使用
- Swiftのパフォーマンスの詳細
WWDC22
- ゲームのメモリをプロファイリングして最適化する
WWDC21
- メモリ問題の検出と診断
WWDC18
- iOSメモリについて理解を深める
ダウンロード

「ヒープメモリの分析」へようこそこちらがBenですそしてこちらがDanielです今日はヒープメモリとアプリについてお話ししますヒープメモリはアプリによって直接的および間接的に使用されデベロッパとしてそれを制御し最適化することができますヒープメモリはアプリの参照型が格納される場所であり通常は書き込みによってダーティになるためアプリのメモリ制限に影響する重要なものですそのため本セッションではヒープメモリの測定と削減に焦点を当てます
グラフィックメモリやメモリ制限などほかの種類のメモリについて詳しく知りたい場合はこれらを詳しく解説しているほかのセッションをご覧くださいアプリがメモリを使いすぎている場合や私のように好奇心で内容を確認したいという方もぜひご覧ください本セッションでは5つのトピックを扱いますヒープの測定一時的な使用量増加への対処持続的な使用量増加の追跡メモリリークの修正そして実行時のパフォーマンスの向上です最初のトピックはヒープメモリの概要とアプリで使用中のヒープメモリを測定するためのツールについてですヒープを理解するにはアプリの仮想メモリ全体でどこに位置するのかを知る必要がありますアプリは起動時に仮想メモリ内に空のアドレス空間を取得しますシステムはアプリ起動時にメインの実行可能ファイルとリンクされたライブラリフレームワークをロードしディスクから読み取り専用リソースの領域をマップします実行時アプリはスタック領域も使用してその領域に各スレッドのローカル変数と一時変数を格納し長期間存続する動的なメモリを複数のメモリ領域に配置しますこれらの領域を総称してヒープと呼びます本セッションではこの領域に注目します拡大しましょうヒープは1つのメモリブロックではなく複数の仮想メモリ領域で構成されていますもう少し拡大し各領域レベルで見てみます各領域は個別のヒープの割り当てに分割されます詳細に見るとこれらの領域はオペレーティングシステムの 16KBのメモリページで構成されていますただし各割り当てのサイズは増減しますこれらのメモリページの状態は3つありクリーンダーティスワップ済みのいずれかですクリーンページはまだ書き込みのないメモリです割り当て済みであるけれど未使用の領域やディスクから読み取り専用でマップされたファイルが含まれますこれらのページはシステムがいつでも破棄し再度フォールトできるため低コストですダーティページはアプリによって最近書き込まれたメモリですダーティページはしばらく使われていなくても破棄できませんメモリ不足になるとシステムはこれらをスワップし圧縮するかディスクに書き込みますこれにより必要な時にメモリを解凍するかディスクからフォールトできます 3種類のページのうちダーティとスワップ済みのみがアプリのメモリフットプリントにカウントされほとんどのアプリではメモリフットプリントの大部分をヒープが占めます
ヒープ領域は関数mallocやそれと類似する割り当てプリミティブであるcallocや reallocにより作成されるメモリです多くの場合これらの関数は直接呼び出しせずコンパイラとランタイムにおいて SwiftやObjective-Cクラスのインスタンス作成などによく使用されますアプリはmallocにより存続期間の長いメモリを動的に割り当てできます割り当ては明示的に解放されるまで存続しますつまりこれらを作成したコードのスコープの終了後も存続しますこれらの関数は数個のルールを適用します例えば割り当てサイズとアライメントの最小値は16バイトですそのため 4バイトを指定すると 16に切り上げられますまたセキュリティ機能としてほとんどの小さい割り当ては解放時にゼロになります言語のランタイムはヒープにより存続期間の長いメモリを割り当てます例えば Swiftはこのクラスイニシャライザを展開し一連のSwiftランタイム関数を呼び出しますその最後にmallocが呼び出されます
また mallocにはデバッグ機能がありますその1つがMallocStackLoggingであり各割り当てのコールスタックとタイムスタンプを記録します MallocStackLoggingを有効にするとメモリを割り当てた場所と時点の追跡が大幅に容易になります
Xcodeではスキームのタブのチェックボックスで MallocStackLoggingを有効にできます mallocのスタックログ作成を有効にしたので本セッションの全デモで利用できますメモリの使用状況を追跡するための1つ目のツールは Xcodeのメモリレポートですアプリのフットプリントを経時的に示すツールですアプリのフットプリントはヒープだけではありませんがメモリレポートではメモリに関する主な問題と最近の履歴を把握できます残念ながらメモリ使用量の増加の理由は表示されませんこれを調査するには別のツールが必要です今回ご紹介するもう1つのツールも Xcodeに含まれていますメモリグラフデバッガはメモリグラフを取得しますこれはすべての割り当てとそれらの間の参照のスナップショットです MallocStackLoggingを使えば各割り当てのバックトレースが得られます特定の割り当てに注目する場合メモリグラフデバッガは最適であり Xcodeのデバッグバーから直接アクセスできます
Xcodeにはメモリ分析用の強力なコマンドラインツールもあります leaks、heap、vmmap、malloc_historyは macOSとSimulatorのプロセスの直接の分析や取得済みのメモリグラフによる問題の調査に使用できますこれらのツールのmanページを参照して高度な機能を確認することをおすすめします
メモリ使用量を経時的にプロファイルする場合 Instrumentsアプリでは数種のテンプレートを利用できます「Allocations」instrumentは割り当てと解放の全イベントの履歴を経時的に記録し統計とコールツリーを集約するためコードをさかのぼる際に役立ちます「Leaks」instrumentはアプリのメモリのスナップショットを定期的に取得しメモリリークを検出します次にサンプルアプリである Destination Videoの問題を「Allocations」で調査する方法を確認します
新しい機能にメモリの問題がありますこの機能はDanielと私がこのアプリ用に開発しましたこの機能ではビデオの新しい背景画像を選択できます何度か背景画像のギャラリーを開いたり閉じたりするとアプリがクラッシュしました大量のメモリを消費したためです Xcodeのメモリレポートによるとギャラリーを開くたびにメモリ使用量が約1GBに急増していますこれを「Allocations」instrumentで分析できます私のデバイスで試してみます
Instrumentsでのプロファイル作成は > から行いますアプリのリリースビルドを実行しそれをターゲットに選択して Instrumentsを開きます開く時にプロファイリング用のテンプレートの選択を求められますこの例ではヒープのプロファイルを作成するのでを選択します「Allocations」と「VM Tracker」の2つの instrumentがこのテンプレートに含まれます「Allocations」はヒープとVMイベントをライブで記録し動きをリアルタイムで確認できるようにします「VM Tracker」ではスナップショットを定期的に取得し全仮想メモリを測定できますこの例ではヒープだけに注目するのでこれは利用しませんトレースはトレースドキュメントの左上のボタンで開始しますトレースが始まるとアプリのデータストリーミングが始まりますアプリは読み込み済みのためトラックビューではメモリ使用量は一定ですギャラリービューを開いて閉じ使用量の急増時に何が起きているか確認します
前回よりも少し遅くなりますがこれは予想通りです mallocとfreeすべてのスタックトレースを取得しますこのデータはこの後すぐに非常に役に立ちます
左上の停止ボタンをクリックしてトレースを止めます「Allocations」トラックを見るとスパイクパターンが再現されていますトレースファイルができたのでメモリバグが大好きなパートナーに送りましょうメニューで > を選択しトレースを保存しますここからはDanielの出番です
一時的なメモリ増加の診断について説明してもらえますかもちろんです Benが記録したメモリスパイクの詳細を見て対策を考えてみましょうアプリに現れるメモリスパイクは一時的なメモリ増加の一種ですこのような増加が好ましくない理由は 3つあります
メモリスパイクでメモリが圧迫されるとシステムが対処しますダーティメモリのスワップおよび圧縮や読み取り専用メモリの破棄バックグラウンドタスクの終了を行います最悪の場合メモリスパイクによってアプリが停止することもありますメモリスパイクには長期的な観点でも問題がありますヒープメモリ領域に断片化やホールが発生するためですこれを追跡する方法は2つです特定のスパイクで低点から高点までの間に作成されまだ存在している割り当てを見つけますまたは広い範囲をまとめて選択しその範囲内で作成され破棄された全割り当てに着目します Benが作成したトレースで試してみましょう
タイムラインでスパイクのある区間を1つ選びますトラックビューでスパイクの低い点から最高点までクリックしてドラッグしますすると下の統計情報の詳細に原因に関する情報が表示されます行を総バイト数の順に並べ替えて上位の原因を見てみましょうこの例ではヒープメモリに注目していますが上位のカテゴリには仮想メモリのIOSurfaceなどがありますこれはここでの一時的なメモリの問題が背景画像の処理方法に関連することを示す有力なヒントです持続時間の順に並べ替えるとスパイクの頂点に達したオブジェクトの中で目立つのは @autoreleasepool contentのノードです自動解放プールにしてはかなりの数が作成されていますこれについては後ほど説明します一時的なメモリの問題を調べるもう1つの方法はオブジェクトが作成され破棄される原因となったコードをより広い範囲で探すことですウインドウ下部のライフスパンのフィルタをに変更しますタイムラインで 3つのスパイクすべてを選択します次に中央のJump Barで詳細ビューをに切り替えますはバックトレースによる割り当ての詳細確認に適した方法ですメモリが最も割り当てられているコードがわかります合計を見ると 8GBの一時割り当てがありますこれはどこから来るのでしょう右のを見るとどこを調べるべきかわかりますもう少し幅を広げましょう
コードのフレームが強調表示されておりこのリストを見ると makeThumbnail()のコードから始めるのがよさそうです 1回クリックした場合が表示されダブルクリックした場合ソースを確認できます
これが適用していた画像フィルタですある行の項目で数GBにおよぶ膨大な量のメモリが作成され破棄されていることがわかりますこれは一時的なメモリのはずですがスパイクの頂点に達するまで増加しその後全部一度に解放されています数フレーム上を見るためにクリックして Jump Barのに戻ります数フレーム上を見ると今度は ThumbnailLoaderの loadThumbnailコードが気になります
ループでサムネールをフォールトしていてループの実行中にメモリが増えており最後に減少します先ほどの自動解放プールのヒントと合わせると何が起きているのかわかります自動参照カウント機能を持つ Swiftを使っていますが自動解放プールはよく一時的なメモリ増加の原因になります Objective-Cはこのプールによって関数の戻り値用にオブジェクトの寿命を延長します自動解放プールは解放を遅らせることでこれらの戻り値を存続させますがこれは Swiftが Objective-C APIを使用または公開するフレームワークを呼び出す時に自動解放オブジェクトを生成できることも意味しますこの簡単な例では現在の日付を出力しますが自動解放文字列も作成しますこの文字列は現在の自動解放スコープの終了までヒープに維持されるため一定の期間存続します
スレッドには通常最上位の自動解放プールがあるものの頻繁には整理されずプールがオブジェクトで一杯になる時問題が生じますこれはループ内で簡単に発生します
反復のたびにオブジェクトが同じプールに自動解放され必要以上に存続する場合がありますループのすべてが終了するまで存続するのです内部的には自動解放プールがコンテンツページを割り当ててオブジェクトを参照しますこれらは「Allocations」に表示されるためこの種の問題の発生に容易に気づけます後で自動解放プールが破棄される時に遅延された解放をプールが送信し多くのオブジェクトが一度に解放されます
これを修正するには通常ネストされたローカルの自動解放プールのスコープを定義し期間を絞り込みますこの例では自動解放されたオブジェクトは内部のループごとのプールに保持され反復のたびに解放されますつまり蓄積されるオブジェクトの数が減り参照の追跡に必要なコンテンツページが減ります前に戻って問題を解決できるか見てみましょう Instrumentsからソースビューの右上のメニューを使って Xcodeでファイルを開きます
修正のためにループの本文に autoreleasepoolのスコープを追加しますこれにより反復ごとにオブジェクトが破棄されます
さてうまく機能するでしょうか
おっと開発用のスマートフォンを忘れました Ben テスト用にあなたのを貸してもらえますかだめですよ私のですから Simulatorを使ったらどうですかなるほどそうしますプロファイリングではタイミングが正確になるよう通常実機でリリースビルドを実行しますしかしヒープ分析では Simulator環境が実際の動作と近いためメモリのプロファイリングに使えますメモリゲージに切り替え Benがお見せした機能を試してみましょう
Simulatorでギャラリーを一度開いてから閉じます
ゲージは改善したようでメモリは増えたものの大きなスパイクはありません
2回目も同様ですが今回はあまり良くないパターンが見えてきました
シートを3回表示した後メモリスパイクが解消されたことが確認できます 1ギガバイトに届きそうになっていませんしかしメモリ使用量が毎回増加し階段状になるという問題がありますこれはおかしいですねサムネール作成に大量のメモリが使われてもギャラリーを初めて開く時だけ増えるはずです自動解放プールの修正をすぐにプッシュします楽しみを独占したくはありません Xcodeのデバッグバーからメモリグラフデバッガで一時停止しますこれによりアプリのヒープのすべての割り当てがキャプチャされます増加の原因となった型がわかっている場合すぐに探せますまたは右側で共有できますこのメモリグラフはInstrumentsで直接インポートできますが AirDropでBenに渡しましょう干草の山から針を見つけるようなこの難題に彼ならきっといいアイディアがあるでしょうがんばれ Ben！ Daniel 面白いけどそんな釣りにはもうひっかかりませんよ自分のメモリグラフを使ってこのな増加について調べます持続的なメモリとは割り当て解除されないメモリのことです持続的な増加は大抵このようになります時間の経過とともにメモリが増えますこの増加は複数の割り当てによるものです「Allocations」instrumentの Mark Generation機能では増加を期間に基づいて区分できますボタンを押すと割り当ての新しいグループが作成されますこの世代はこの時点より前に作成されトレースの最後まで存続しているすべての割り当てを収集しますこれより後の時点を選択して再度を押すと新しいグループが作成されますこの次世代は前の世代の後から新しいタイムスタンプまでに作成された持続的な割り当てをすべて収集します Xcodeで独自のメモリグラフを生成し
Instrumentsにインポートしました「Allocations」「Leaks」「VM Tracker」にデータが示されます「Allocations」トラックに注目しますトラックビューでは Danielの指摘と同じ階段状のパターンがメモリレポートにあります Mark Generation機能を使って増加のある期間に作成された持続的な割り当てを分離します増加のある期間のいくつかの時点を選択してボタンを押します
Instrumentsに3つの世代が表示されましたギャラリーを開くことで生じた持続的な増加が B世代とC世代でみられますいずれかの世代を展開してその割り当てを表示し増加のサイズが大きい順に並べ替えて最も増加の原因になった型を確認しますこの増加の大半はデータストレージが原因のようですこのタイプのエントリを展開すると個々の割り当てとそのアドレスを確認できます探し物が見つかりました
これらすべてのデータストレージの割り当ては ThumbnailLoaderコードで作成されたようですでは何がデータを保持しているのでしょうアドレスの1つをInstrumentsから取得しメモリグラフデバッガに入れるとその参照元がわかりますこれによりギャラリーを閉じた後も存続している理由がわかります拡張詳細ビューからアドレスをコピーしメモリグラフデバッガのフィルタバーに貼り付け割り当てを選択します
メモリグラフデバッガの示す内容をより理解するために仕組みを少し説明します
メモリ使用量の増加の調査では割り当てが存続する理由や何がそれを保持しているのかを特定することが重要ですこれらを特定する上でメモリグラフデバッガが役立ちますこれを最大限に活用するには型情報と参照のスキャンについて理解する必要があります参照には主に4つのタイプがあります 1つ目は強い参照です当然ながらこれはポインタで ARCで管理される場所にあり所有権が明示的に保証されています 2つ目の弱い／非所有の参照もポインタですが所有権がないことが明示的に保証されています 3つ目の非管理対象の参照はランタイムが認識している場所にあるポインタで自動的には管理されません手動で所有される参照が含まれますがそれ以外の場合もあります最後は不確定または保守的な参照ですスキャンするメモリの種類をツールが認識しておらず生のメモリを確認する場合に記録されます値がポインタに見える場合はそうかもしれませんが型情報がない場合それを確かめる方法はありませんツールはプロセスのヒープのスキャン時に各割り当てに使用できる最適な型情報を使用しますこのSwift Swallowの例では最初の2つのフィールドは標準で参照のスキャンにとって重要なものは含みませんその後 coconut参照をスキャンしますこのフィールドはヒープ割り当てへのポインタを含むため Coconutオブジェクトへの強い参照です SwiftとObjective-Cの型情報は強力ですが CやC++には参照の所有権情報がないため保守的な参照のみが使用されますツールで実行できる最善の方法は仮想メソッドによるC++の型名の検索ですこのクラスのインスタンスは Coconutとみなされます仮想メソッドやその他の割り当てを持たない型の場合スタックトレースを使えば名前がわかります MallocStackLoggingデータではこのクラスのインスタンスに malloc in PalmTree::growCoconut() のようなラベルがつけられておりこれが何であるかについてのヒントになります型情報と参照について説明できたので前に戻ってデータストレージが持続的である理由を確認しましょうメモリグラフデバッガを見ると選択した割り当ては __DataStorageオブジェクトが保持しそれをPhotoThumbnailが保持しさらにそれを辞書が保持していますさらにさかのぼるとこれを保持しているのは静的プロパティである ThumbnailLoader.globalImageCacheとわかります MallocStackLoggingを有効にしているため右のインスペクタに割り当てのバックトレースが表示されますインスペクタを使ってこの割り当てのソースに移動しますデータを保持している PhotoThumbnailを選択しますコードのクロージャの1つがその割り当てを実行しているようですスタックトレースを使ってコードに移動します
見たところこのfaultThumbnailメソッドがサムネールをキャッシュしキャッシュミスの場合は新しく作成していますこのサムネールは先ほど見た globalImageCacheに保存されているようですコメントによると URLとcreationDateに基づいてキャッシュしていますこれは妥当に思われますがバグがあります明らかにファイル作成時のタイムスタンプではなく現在時刻になっていますこのためキャッシュ内に何も見つからずメソッドを呼び出すたび PhotoThumbnailを新しくキャッシュしていますサムネールの持続的な増加はこれが理由ですファイル作成日に基づいてキャッシュするよう修正しましょうタイムスタンプを間違えたコードを削除します次はファイル作成時のタイムスタンプを取得します Xcodeが必要なコードを提案してくれました Tabキーを押して決定します再びアプリを実行して問題が解決したことを確認しましょう階段状のパターンがXcodeメモリレポートに現れないことを確認します
機能を再度試してみます
サムネールを生成しましたもう一度やってみます
増加はありません念のためもう一度やってみます
メモリグラフデバッガ内で終了しその他の問題がないことを確認します
メモリリークがいくつかありました横に黄色の三角形のアイコンがある割り当てです Daniel またコードでリークを起こしたんですかはい次のトピックはリークしたメモリなので丁度いいでしょうリークしたメモリを理解して修正するにはまず到達可能性の説明が必要ですプログラム内のすべてのメモリは将来使用する予定の場所から弱くない参照で到達可能である必要がありますヒープには3種類のメモリがあります 1つ目は有用なメモリですプログラムによって到達可能で将来再び使用されます 2つ目は見捨てられたメモリです到達可能で使用もできますが実際に再び使われることはありませんこのメモリはアプリのフットプリントに影響し無駄です過度なキャッシュや高負荷データのシングルトンでの保持などにより簡単に発生します 3つ目のタイプのメモリはリークしたメモリですこれは到達不能なメモリであり二度と使用できません多くの場合手動で管理される割り当てやオブジェクトの循環参照により最後のポインタが失われた時に生じますほとんどのリークでは 1回の循環に 1つの参照を特定し修正することが目標です例えば誤った参照を削除したり所有権の修飾子を強から弱または非所有に変更したりしますこれらのリークの調査をより簡単にするにはフィルタバーのボタンを使用しますこの場合も三角アイコンが表示されます
型がアプリのバイナリごとにグループ化されナビゲータに表示されますコードがシステムバイナリから型をリークする可能性もありますが通常リークの直接の原因はプロジェクト内の問題ですフィルタバーの別のボタンをクリックし自分のプロジェクトの型に絞り込みます見やすくなりましたリークは ThumbnailLoaderクラスに3つと ThumbnailRendererに3つありますそのうち1つを選択しますこれは ThumbnailRendererと ThumbnailLoader およびクロージャコンテキストの間の小規模な循環参照のようですまずはこのクロージャコンテキストの用途を手短に確認しましょう Swiftクロージャは値を取得する必要がある場合キャプチャを保存するためにヒープにメモリを割り当てますメモリグラフデバッガはその割り当てにクロージャコンテキストのラベルをつけますヒープ内の各クロージャコンテキストは存続するクロージャと1対1で対応しますデフォルトではクロージャは強い参照をキャプチャするため循環参照が生じ得ます弱いまたは非所有のキャプチャを使えば循環を解消できます例えば完了ハンドラを持つ Swallowオブジェクトがありツバメがココナツを運ぶと呼び出されるとします気をつけないと Swallow自身が強い参照としてキャプチャされ循環参照が生じますメモリグラフデバッガには強いキャプチャとして参照が表示されますがクロージャのメタデータには変数名は含まれませんクロージャコンテキストからの参照はすべて「capture」のラベルのみがつけられます戻ってリークを解決できるか確認しましょうインスペクタを開いていくつかの参照をクリックします
ThumbnailRendererには Loaderへの cacheProvider参照があります Loaderにはクロージャコンテキストを参照するcompletionHandlerがあります captureを選択してRendererに戻ると強い参照であるとインスペクタに示されていますこの循環を解消するにはクロージャを作成したコードを探す必要がありますクロージャコンテキストのスタックトレースから PhotosViewのコードに移動します
このコードは ThumbnailLoaderオブジェクトを作成し完了ハンドラを割り当ててロードを開始するよう指示しますしかし先ほどの問題はクロージャがThumbnailRendererを強い参照としてキャプチャしそれが循環参照を起こしていることですどう修正すべきでしょうかコードを変更し完了クロージャの代わりに Swiftの並列処理を使用できますしかしここではキャプチャリストを指定します弱または非所有にすれば循環を解消できます Rendererのキャプチャを弱にして
オプションの弱い参照があるのでこのguard letを追加することで参照先であるRendererが使用時にまだ存在するようにします今行ったのは3ノードの循環の修正ですがこのような小さな変更が大きな効果をもたらしますこの機能をもう一度試しメモリグラフデバッガで停止すると
リークした型は表示されなくなりました型フィルタをオフにすると驚いたことにその他のリークも解決しています先ほど修正したリークはほかの型も参照していたのでそれらの型の割り当ても解除されましたこの例のリークの特定と修正は非常に簡単でしたコードリークには様々な形があるためリークの特定はおそらく最も多くの疑問が生じる領域ですいくつかお話しするとまずリークチェックで見つからないものがあるのはなぜでしょうかリークを意図的に作った場合も必ずしもツールで検出できないのはなぜでしょう対応する型情報がツールにないメモリは多数ありますし C言語などでは管理されていないポインタを使えますつまりツールは一見ポインタのようで実際はそうでない可能性があるものを許容せざるを得ませんツールの保守的なスキャンではポインタを探して参照と思われる値を1バイトずつチェックし割り当てのリストと照合します値が一致すればツールはブロックへの不明確で保守的な参照を記録しますただしそれらの値は数値やフラグのほかに有効なポインタのようなランダムなバイトの場合もありますそのためこの疑問への回答としては「保守的な参照では実際のリークが見逃される可能性があるため」です意図的なリークを作成してそれを見つける場合これを100回実行するループに入れても問題ありません実際のアプリでのリークコードは通常複数回実行されるためツールはすべてのリークを検出するわけではありませんがその原因のバグを検出しますこれに関連する疑問がレポートされたリーク数が経時的に変動するのはなぜかというものですリークはバグにより経時的に増えますヒープはかなりノイズがありランダムですこのノイズは保守的な参照を非決定論的にするため参照が現れたり消えたりしますそのためプログラム起動時オブジェクトが5つリークしツールが最初5つリークを検出しても後で4つになることもありますもう1つのよくある疑問は返されない関数がメモリをリークすることがあるのはなぜかです例えば noreturn属性を持つC言語の関数や Never型を返すSwift関数の場合ですこれらの関数は決して戻されないため最適化されたコンパイラは通常行うクリーンアップを省略できますこれにはコンパイラが作成するローカルの割り当てや参照の解放が含まれますこの種の関数は非常に重要なアサートに使用しても問題ありませんプログラムがクラッシュするためですただしスレッドを停止するのに使われることもありますこの例の Serverオブジェクトのような noreturn関数の呼び出しからのリークとしてローカルステートがレポートされた場合明示的にグローバルに格納することで解決しますオブジェクトをローカル関数のスコープ外に格納すると参照はツールが認識できる場所に置かれますツールが参照を認識できるためローカル変数がコンパイラによって保持されない場合でもオブジェクトはリークしているのではなく到達可能であるとみなされますリークの説明は以上です再びBenに交代しランタイム速度とココナツについて説明してもらいましょうありがとうメモリを減らすとパフォーマンスを大幅に強化できますそれをさらに強化できるようにランタイムの詳細を確認しましょう
weakとunownedは強い循環参照の発生を防ぐために Swiftでよく使用されるツールです 2つの間の違いといつ使用するかを説明します弱い参照は常にoptional型ですが宛先が初期化解除された後はnilになります弱い参照の使用はソースおよび宛先の存続期間に関わらず常に許可されますツバメとココナツの場合を考えてみましょうココナツはツバメに運んでもらえますがツバメを所有してはいませんココナッツにツバメを参照させる場合強い参照の使用は避けるべきです代わりに弱い参照を使用できますただしオーバーヘッドが生じます Swiftでは弱い参照を実装する場合弱い参照の最初の実行時に参照先オブジェクト用の Swiftの弱い参照ストレージを割り当てますこの割り当ては Swallowと Swallowへのすべての弱い参照の間にありますこれにより Swallowがいなくなった後に弱い参照を遅延的にnilにできます弱い参照と異なり非所有の参照は参照先を直接保持しますつまり余分なメモリを使わず弱い参照よりもアクセスにかかる時間が短くなります optional以外の型にすることも定数にすることもできますしかし非所有の参照の使用は常に有効とは限りません例えば Coconutのholderの参照を弱ではなく非所有にします参照する前にSwallowがいなくなるとどうなるでしょうか Swallowは初期化解除されますが割り当て解除はされませんそのため非所有の参照は安全です非所有の参照は何かを指している必要がありこれによりランタイムは「元オウム」や「ツバメ」を存続させておくことができます（比喩を混ぜて話してます）この時点で Coconutの非所有の参照を使用して Swallowにアクセスを試みると決定的なクラッシュが発生します非所有の参照はこの点で強制的にアンラップする弱い参照に似ています非所有の参照にアクセスしない場合も放っておくのはよくありません非所有の参照が存在する限りその参照先の割り当ては解除できずメモリを浪費します参照先の存続期間がわからない場合オーバーヘッドの小さい弱い参照は有用です
メモリグラフに弱い参照や非所有の参照がレポートされない場合は Xcodeでプロジェクトのビルド設定のを確認してみてください可能な場合デフォルトのレベルの使用を推奨しますこの設定にはツールに必要な全メタデータが含まれツールにおける Swiftの精度を大幅に向上させます
具体例を見てみましょうこのByteProducerクラスには generatorプロパティがありますこれは defaultActionメソッドに最初に割り当てられるクロージャです問題はこれによって強い参照による循環が生じることですこれは defaultActionメソッドが暗黙的にselfを使用するためですメソッドをクロージャとして使う時は注意が必要です
修正するには defaultAction()を呼び出すクロージャを定義します selfのキャプチャは実行されますが今度はキャプチャが明示的でありキャプチャリストを使用して強い参照を回避できます参照の修飾子を指定する必要がありますここでは weakが適切なデフォルトとして機能しますこの場合はunownedも使用できますこれはジェネレータクロージャが参照先であるByteProducerインスタンスと同じ存続期間を持つためですクロージャはほかのコードに渡されることも非同期的にディスパッチされることもないためキャプチャされたselfより長く存続できませんこれらの選択肢によってパフォーマンスに大きな差が出る場合がありますこのByteProducerを100万個割り当ててメモリグラフをエクスポートするとヒープのコマンドラインツールによりコストの概要をすばやく把握できます ByteProducerごとに1つの弱い参照ストレージが割り当てられますこれらはByteProducer自体と同じくらいメモリを消費します unownedではこのメモリは必要ありません重要なのは weakが参照の適切なデフォルト値であることと unownedでは参照がその参照先よりも長く存続しないことが保証できる場合にメモリと時間を節約できることです CPUオーバーヘッドの発生領域を特定するにはプロファイルを作成し swift_weakLoadStrong() などのランタイム関数の呼び出しを探します
Swiftの参照カウントの詳細に関するおすすめの資料は「Automatic Reference Counting」の「Swift Programming Language」の章です
弱い参照と非所有の参照のほかに時々自動の保持と解放の呼び出しがプロファイルのホットスポットになります ARCの回避は魅力的かもしれませんが控えましょう管理されていないポインタを使ったりパフォーマンスに影響しやすいコードをメモリが安全でない言語に移したりするよりも良い方法があります -whole-module-optimizationを有効にしましょうインライン展開を増やしてオーバーヘッドを削減できるためです明示的な特殊化が必要なジェネリックをプロファイルを作成して探しましょう
また最も頻繁にコピーする構造体には単純なフィールドを含めるようにしましょうプロファイル作成は高コストな構造体のコピーの特定に有用ですこれらの構造体では参照型やcopy-on-write型および anyの使用を最小限に抑えてください
Swiftのパフォーマンスに関するヒントは「Explore Swift Performance」と「Consume noncopyable types in Swift」を参照してください Objective-Cコードにも保持と解放のオーバーヘッドを削減する方法がいくつかあります
繰り返しますが ARCは回避しないでください手動の参照カウントからのリークはデバッグが極めて困難になり得るためですメソッドをobjc_directとしてマークし Objective-Cメソッド呼び出しのインライン展開を可能にすると保持と解放のトラフィックを軽減できますインライン展開ができない場合はパラメータの存続期間が保証されている場合にコンパイラに知らせるために objc_externally_retained属性を使用すれば保持と解放をなくせるため効果的です
パフォーマンスの一部は監視のコストを反映します MallocStackLoggingとAllocationsはライブデータを追跡しますがこれにはすべての割り当てに関する情報を記録するためのメモリとCPUが必要です Leaks VM Tracker　メモリグラフはスナップショットベースであり分析中にターゲットアプリを一時停止する必要がありますそのためスナップショット処理中にアプリに一時遅延やハングが発生します本セッションの内容をまとめます Instrumentsでのヒープ測定方法と一時的および持続的な増加のパターンの探し方を説明しました個々の割り当てに問題が見つかったら Xcodeのメモリグラフデバッガと MallocStackLoggingで割り当てがヒープに存続している理由を特定しますとはいえ何よりも予防が重要ですアプリのヒープメモリを分析し最適化しましょうリークと持続的な増加を見つけることでユーザーはアプリをより長く楽しめますご視聴ありがとうございました

10:01 - ThumbnailLoader.makeThumbnail(from:) implementation

func makeThumbnail(from photoURL: URL) -> PhotoThumbnail {
  validate(url: photoURL)
  var coreImage = CIImage(contentsOf: photoURL)!

  let sepiaTone = CIFilter.sepiaTone()
  sepiaTone.inputImage = coreImage
  sepiaTone.intensity = 0.4
  coreImage = sepiaTone.outputImage!

  let squareSize = min(coreImage.extent.width, coreImage.extent.height)
  coreImage = coreImage.cropped(to: CGRect(x: 0, y: 0, width: squareSize, height: squareSize))

  let targetSize = CGSize(width:64, height:64)
  let scalingFilter = CIFilter.lanczosScaleTransform()

  scalingFilter.inputImage = coreImage
  scalingFilter.scale = Float(targetSize.height / coreImage.extent.height)
  scalingFilter.aspectRatio = Float(Double(coreImage.extent.width) / Double(coreImage.extent.height))
  coreImage = scalingFilter.outputImage!

  let imageData = context.generateImageData(of: coreImage)

  return PhotoThumbnail(size: targetSize, data: imageData, url: photoURL)
}

10:23 - ThumbnailLoader.loadThumbnails(with:), with autorelease pool growth issues

func loadThumbnails(with renderer: ThumbnailRenderer) {
  for photoURL in urls {
    renderer.faultThumbnail(from: photoURL)
  }
}

10:33 - Simple autorelease example

print("Now is \(Date.now)") // Produces autoreleased .description String

11:08 - Autorelease pool growth in loop

autoreleasepool {
  // ...
  
  for _ in 1...1000 {
    // Autoreleases into single pool, causing growth as loop runs
    print("Now is \(Date.now)")
  }
  
  // ...
}

11:50 - Autorelease pool growth in loop, managed by nested pool

autoreleasepool {
  // ...
  
  for _ in 1...1000 {
    autoreleasepool {
      // Autoreleases into nested pool, preventing outer pool from bloating
      print("Now is \(Date.now)")
    }
  }
  
  // ...
}

12:16 - ThumbnailLoader.loadThumbnails(with:), with nested autorelease pool growth issues fixed

func loadThumbnails(with renderer: ThumbnailRenderer) {
    for photoURL in urls {
        autoreleasepool {
            renderer.faultThumbnail(from: photoURL)
        }
    }
}

17:27 - C++ class with virtual method

class Coconut {
  Swallow *swallow;
  virtual void virtualMethod() {}
};

17:40 - C++ class without virtual method
```
class Coconut {
  Swallow *swallow;
};
```

18:41 - ThumbnailRenderer.faultThumbnail(from:), caching thumbnails incorrectly

func faultThumbnail(from photoURL: URL) {
  // Cache the thumbnail based on url + creationDate
  let timestamp = UInt64(Date.now.timeIntervalSince1970) // Bad - caching with wrong timestamp
  let cacheKey = CacheKey(url: photoURL, timestamp: timestamp)

  let thumbnail = cacheProvider.thumbnail(for: cacheKey) {
    return makeThumbnail(from: photoURL)
  }
  images.append(thumbnail.image)
}

19:28 - ThumbnailRenderer.faultThumbnail(from:), caching thumbnails correctly

func faultThumbnail(from photoURL: URL) {
  // Cache the thumbnail based on url + creationDate
  let timestamp = cacheKeyTimestamp(for: photoURL) // Fixed - caching with correct timestamp
  let cacheKey = CacheKey(url: photoURL, timestamp: timestamp)

  let thumbnail = cacheProvider.thumbnail(for: cacheKey) {
    return makeThumbnail(from: photoURL)
  }
  images.append(thumbnail.image)
}

22:19 - Code creating reference cycle with closure context

let swallow = Swallow()
swallow.completion = {
  print("\(swallow) finished carrying a coconut")
}

23:11 - PhotosView image loading code, with leak

// ...
let renderer = ThumbnailRenderer(style: .vibrant)
let loader = ThumbnailLoader(bundle: .main, completionQueue: .main)
loader.completionHandler = {
  self.thumbnails = renderer.images // implicit strong capture of renderer causes strong reference cycle
}
loader.beginLoading(with: renderer)
// ...

23:40 - PhotosView image loading code, with leak fixed

// ...
let renderer = ThumbnailRenderer(style: .vibrant)
let loader = ThumbnailLoader(bundle: .main, completionQueue: .main)
loader.completionHandler = { [weak renderer] in
	guard let renderer else { return }

  self.thumbnails = renderer.images
}
loader.beginLoading(with: renderer)
// ...

24:24 - Intentional leak of manually-managed allocation

let oops = UnsafeMutablePointer<Int>.allocate(capacity: 16)
// intentional mistake: missing `oops.deallocate()`

25:12 - Loop over intentional leak of manually-managed allocations

for _ in 0..<100 {
  let oops = UnsafeMutablePointer<Int>.allocate(capacity: 16)
  // intentional mistake: missing `oops.deallocate()`
}

26:11 - Nonreturning function which can see leaks of allocations owned by local variables

func beginServer() {
  let singleton = Server(delegate: self)
  dispatchMain() // __attribute__((noreturn))
}

26:22 - Fix for reported leak in nonreturning function

static var singleton: Server?

func beginServer() {
  Self.singleton = Server(delegate: self)
  dispatchMain()
}

27:21 - Weak reference example
```
weak var holder: Swallow?
```
27:43 - Unowned reference example
```
unowned let holder: Swallow
```

29:07 - Implicit use of self by method causes reference cycle

class ByteProducer {
  let data: Data
  private var generator: ((Data) -> UInt8)? = nil

  init(data: Data) {
    self.data = data
    generator = defaultAction // Implicitly uses `self`
  }

  func defaultAction(_ data: Data) -> UInt8 {
    // ...
  }
}

29:25 - Break reference cycle cause day implicit use of self by method, using weak

class ByteProducer {
  let data: Data
  private var generator: ((Data) -> UInt8)? = nil

  init(data: Data) {
    self.data = data
    generator = { [weak self] data in
      return self?.defaultAction(data)
    }
  }

  func defaultAction(_ data: Data) -> UInt8 {
    // ...
  }
}

29:41 - Break reference cycle cause day implicit use of self by method, using unowned

class ByteProducer {
  let data: Data
  private var generator: ((Data) -> UInt8)? = nil

  init(data: Data) {
    self.data = data
    generator = { [unowned self] data in
      return self.defaultAction(data)
    }
  }

  func defaultAction(_ data: Data) -> UInt8 {
    // ...
  }
}

31:14 - Struct with non-trivial init/copy/deinit

struct Nontrivial {
  var number: Int64
  var simple: CGPoint?
  var complex: String // Copy-on-write, requires non-trivial struct init/copy/destroy
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース

関連ビデオ

WWDC24

WWDC22

WWDC21

WWDC18