Instrumentsによるハング分析

Instrumentsによるハング分析

ユーザインターフェースの要素は、リアルタイムの応答など、現実世界でのインタラクションを模倣することがよくあります。ユーザーのインタラクションに顕著なハングがあるアプリは、その期待に添えず、フラストレーションを生み出します。Instrumentsを使って、すべてのAppleプラットフォームでアプリのハングを分析、理解、改善する方法を紹介します。Instrumentsのトレースドキュメントを効率的に操作し、トレースデータを解釈し、さらにデータプロファイリングを記録して、特定のハングをより深く理解する方法を紹介します。 Instrumentsの使い方に不慣れな場合は、まず「Getting Started with Instruments」をご覧ください。また、アプリのハングを発見するのに役立つ他のツールについては、「Track down hangs with Xcode and on-device detection.」をご覧ください。

関連する章
- 1:56 - What is a hang?
- 3:51 - What is instant?
- 4:39 - Event handling and rendering loop
- 8:25 - Keep main thread work below 100ms
- 9:15 - Busy main thread hang
- 14:26 - Too long or too often?
- 21:46 - LazyVGrid still hangs on iPad
- 24:31 - Fix: Use task modifier to load thumbnail asynchronously
- 25:52 - Asynchronous hangs
- 32:38 - Fix: Get off of the main actor
- 35:57 - Blocked Main Thread Hang
- 39:19 - Fix: Make shared property async
- 40:35 - Blocked Thread does not imply unresponsive app
リソース
関連ビデオ

WWDC23
- RealityKit Traceについて
- SwiftUIのパフォーマンスを解明
WWDC22
- Swiftの並行処理を視覚化して最適化する
- Xcodeとオンデバイスでのハングの検出と追跡
WWDC21
- Appのハングアップの理解と解消
- Swiftの並行処理: 舞台裏
WWDC20
- SwiftUI の Stack, Grid, Outline
Tech Talks
- UIアニメーションの滞りおよびレンダーループに対する検討
WWDC19
- Instrumentsの概要
WWDC16
- System Trace in Depth
ダウンロード

♪ ♪
「Instrumentsによるハング分析」にようこそ Joachim Kurzです Instrumentsチームのエンジニアです今日はハングについて詳しく見ていきますまずハングの概要を説明しますそのために人間の知覚について説明します次にイベント処理とレンダリングループについて簡単に説明しますレンダリングループはハングの原因を理解する基礎となりますこの理論的知識を武器に Instrumentsで 3つの異なるハングの例を見てみましょうビジーなメインスレッドのハング非同期のハングそしてブロックされたメインスレッドのハングですそれぞれについて見分け方を説明します分析する際に何を見るべきか他のInstrumentを追加するタイミングを詳細に学ぶことができますセッションの一部を理解する上で Instrumentsついて多少理解しておくと役に立ちます Instrumentsでアプリのプロファイリングをしたことがあれば大丈夫ですそうWWDC19「Getting Started with Instruments」をご覧ください
ハングに対処する場合通常は3つのステップがありますハングを見つけ次にハングを分析しどのように発生するかを理解しますそして修正します（実際に修正されたことをご確認ください）今日はハングをすでに見つけたと仮定します分析することに集中しましょういくつかの修正点についても説明しますハングの見つけ方について詳細を知りたい場合は WWDC22のセッション「Track down hangs with Xcode and on-device detection」をご覧ください Instrumentsを含むハングを見つけるためのツールをすべて網羅していますデバイス上でのハング検出は iOSデベロッパ設定と Xcodeのオーガナイザで有効にできます今日は Instrumentsを使ってすでに見つけたハングを分析しますハングをより理解するために人間の知覚について話します電気をつけてみましょう
電球とケーブルが必要ですずっと良くなりましたケーブルをコンセントに差し込むとランプのように点灯しましたそれをまた抜くと一瞬で電源が切れますでも遅延があったらどうでしょうか？差し込みます電源が入るまで少し時間がかかりましたさらに奇妙なことにもう一度ケーブルを抜いても同じですケーブルが差し込まれてから電気が点灯するまでの遅延はわずか500ミリ秒でしたこの箱の中で何が起こっているのかすでに気になりますランプが直接ついたり消えたりしないのは違和感がありますしかし他の状況では500ミリ秒の遅延は問題ないかもしれませんどの程度の遅延が許容されるかは状況によります例えばこのような会話を耳にしたとします「カメはどうやってコミュニケーションをとるの？」「貝殻電話」ここでは質問と回答の間に 1秒の遅れがありましたそれが全く自然に感じられましたしかしこれは違います
なぜでしょう？亀とユニコーンの会話はリクエスト・レスポンス形式のインタラクションですしかしランプを差し込むことは実際の物体を直接操作することになります実際の物体は瞬時に反応します本物をシミュレートするなら瞬時に反応する必要もありますそうしないと幻想が壊れてしまいます
ケーブルが差し込まれてからランプがつくまでに何の遅延もないのに実際のランプがここにあると主張しても何の問題もなかったでしょうしかし大幅な遅延が発生すると脳は突然「ちょっと待ってそうはいかない」と言うのです瞬時とはどのくらいでしょうか？どの程度の遅延なら気づかないのでしょう?
これが遅延なしの基準値です
100ミリ秒くらいでしょうか？
私には電源を入れた時にわずかに遅れているように感じましたただし電源を切る時ではなくよく見た時だけです皆さんの経験とは違うかもしれません 100ミリ秒はおおよそのしきい値です著しく小さい遅延は実際には知覚できません 250ミリ秒で試してみましょう
250ミリ秒はもはや瞬間ではありません遅くはありませんが遅延は明らかに目立ちます
このような知覚のしきい値はハングレポートにも反映されますボタンのタップなどの個々の操作における遅延は約100ミリ秒未満であれば通常瞬時に感じられますそれ以下にしたい特殊なケースでは目指すには良い目標ですそれ以上は状況によります 250ミリ秒までは何とかなるかもしれませんそれ以上長くなると目立ちます少なくとも無意識のうちにですスケールは連続的なものですが 250ミリ秒を超えると確かにもう瞬時ではありませんほとんどのツールはデフォルトで 250ミリ秒からハングを報告し始めますこれは無視しやすいので「マイクロハング」と呼んでいますコンテキストによっては問題ありませんがそうでないこともよくあります 500ミリ秒を超えるものはすべて適切なハングとみなしますこれに基づいてこのしきい値を大まかに使用できます何かを瞬時に感じたい場合は遅延は100ミリ秒以下を目指してくださいリクエスト・レスポンス形式のインタラクションがある場合は追加のフィードバックなしで 500ミリ秒で問題ないかもしれませんしかし実際にはインタラクションの中で両方があることがよくあります例を見てみましょう
このセッションの準備に協力してくれた同僚全員にこのメールを書き終え送信する準備ができていますマウスを送信ボタンに移動してクリックしますしばらくしてメールウインドウが表示され送信中であることを示しますここで何が起こったかというと 2つのことが起きていたことを実際に見たということですまずボタンが強調表示され 500ミリ秒のわずかな遅延が発生しその後メールウインドウが表示されましたリクエストが届いたことはすでに知っていたのでこの遅延は問題ないと感じましたボタンが強調表示されていたからですボタンを「リアル」として扱いますそして「リアル」タイムで瞬時に更新されることを期待します
インターフェイスの実際のUI要素については通常この「瞬時」更新を目指します UI要素を「瞬時に」反応させるにはメインスレッドをUI以外の作業から解放しておくことが重要ですその理由についてイベント処理とレンダリングのループを詳しく見てみましょう Appleのプラットフォームでイベントがどのように処理されユーザー入力がどのように画面更新につながるか見てみましょう
ある時点で誰かがデバイスとやり取りしますそれがいつ起こるかをコントロールできませんまず通常は何らかのハードウェアが関与しますマウスやタッチスクリーンなどですインタラクションを検出しイベントを作成してオペレーティングシステムに送信しますオペレーティングシステムはどのプロセスがイベントを処理するかを判断しそのプロセス例えばアプリに転送しますアプリではメインスレッドがイベントを処理しますここでUIコードのほとんどが実行されます UIの更新を決定します次にこのUI更新がレンダリングサーバに送信されますこれは個々のUIレイヤを合成する別のプロセスで次のフレームをレンダリングしますディスプレイドライバはレンダリングサーバが用意したビットマップを取得しそれに応じて画面上のピクセルを更新しますこの仕組みついて詳しく知りたい場合は「アプリの応答性を向上させる」で取り上げています何が起きているのかを理解するにはこの大まかな概要で十分ですさてこの間に別のイベントが入ると通常は並行して処理できますしかし 1つのイベントがパイプラインをどのように通過するかを見るとすべてのステップを順番に見ていく必要がありますメインスレッドに到達する前のイベント処理のステップとレンダリングおよび更新表示後のステップは通常その時間はかなり予測可能ですインタラクションに大幅な遅延が生じるとほとんどの場合メインスレッドに時間がかかりすぎたからですまたはイベント発生時にメインスレッドで他の何かがまだ実行されているためです従ってイベントを処理する前にイベントの終了を待つ必要があります UI要素を更新するたびにメインスレッドで時間が必要だと仮定すると更新が100ミリ秒以内に行われリアルに感じられるようにしたいです理想的にはメインスレッドでの作業が 100ミリ秒を超えないことですもっと速くできればさらに良いですメインスレッドで長時間実行される作業も不具合を引き起こす可能性があります不具合を避けるためにより低いしきい値が適用されます不具合に関する詳細は「UIアニメーションの不具合とレンダリングループを調査する」と「アプリの応答性を向上させる」をご覧ください今日はハングに焦点を当てます同僚の一人がアプリのBackyard Birdsでハングに気づきました新しい機能に取り組んでいた時です Instrumentsでアプリをプロファイリングしてみましょう
ここにアプリの Xcodeプロジェクトがあります Instrumentsでアプリのプロファイリングに必要なことはすべて「プロダクト」メニューをクリックし「プロファイル」をクリックしますそして Xcodeがアプリをビルドしてデバイスにインストールしますしかし起動はしません
XcodeはInstrumentsも開き Xcodeで構成したのと同じアプリとデバイスをターゲットに設定します Instrumentsのテンプレート選択で Time Profilerテンプレートを選択しますこれは何を探しているかまだ分からない場合やアプリが何をしているのかをより理解したい場合には良い出発点になることがよくあります Time Profilerテンプレートから新しい Instrumentsのドキュメントが作成されます特にこの新しいドキュメントには Time Profilerとハングの instrumentsが含まれどちらも分析に役立つでしょうツールバーの左上にある「録画」ボタンをクリックして録画を開始します Instrumentsが設定されたアプリを起動しデータのキャプチャを開始します
ここにBackyard Birdsアプリがあります最初の庭をタップすると詳細図に移動しますすぐに「背景を選択」ボタンをタップすると下のシートが出て背景写真の選択が表示されます今それをやってみますボタンは押されていますが動かないようですシートが表示されるまでかなり時間がかかりました深刻なハングです
Instrumentsがすべてを記録していますツールバーで「停止」ボタンをクリックして録画を停止します Instrumentsもハングを検出しましたハング時間を測定しそして重大度に応じて対応する間隔にラベルを付けますこの場合Instrumentsは「重大なハング」が発生したことを示しますこれはアプリの使用中にも同様に当てはまります Instrumentsが応答しないメインスレッドを検出し対応する間隔をハングの可能性としてマークしますこの場合確かにハングが発生しましたメインスレッドが応答しない場合は主に2つのケースが考えられます最も単純なケースはメインスレッドが単に他の仕事でまだ忙しい時ですこの場合メインスレッドは大量のCPUアクティビティを表示しますもう1つのケースはメインスレッドがブロックされている場合ですこれは通常メインスレッドが他の場所で行われる他の作業を待っているためですスレッドがブロックされている場合メインスレッド上のCPUアクティビティは皆無かそれに近いですどのケースに該当するかによって何が起こっているのかを判断するために次に取るべきステップが決まります Instrumentsに戻りメインスレッドを見つけますドキュメントの最後のトラックはターゲットプロセスのトラックを表示します左側に小さな開示インジケータがありサブトラックがあることを示しますこれをクリックするとプロセス内の各スレッドに個別のトラックが表示されます次にここでメインスレッドのトラックを選択しますこれで詳細エリアも更新されプロファイル表示が示されますこれはすべての関数のコールツリーを示し全記録時間中にメインスレッドで実行されます
しかし興味があるのはハング中に何が起こったかだけですタイムラインのハング間隔をセカンダリクリックしコンテキストメニューを表示しますここで「Set Inspection Range」を選択できますがここではオプションキーを押しながら「Set Inspection Range and Zoom を代わりに選択します
これは間隔の範囲にズームインし詳細ビューに表示されるデータを選択された時間範囲にフィルタリングします
全ハング期間中のCPU使用率は 100%ではありませんがほとんどの場合 60%から90%と依然としてかなり高いですこれは明らかにメインスレッドがビジー状態である場合ですこのCPUの作業がどのようなものか調べてみましょう
コードツリーの様々なノードをすべて詳しく見てみましょうしかし右側には素晴らしい要約があります最も重いスタックトレース表示ですその最も重いスタックトレース表示のフレームをクリックするとコールツリービューが更新されこのノードが表示されますこの呼び出しメソッドはコールツリーのかなり深いところにあることもわかります
デフォルトで最も重いスタックトレースはソースコードに由来しない後続の関数呼び出しを非表示にしソースコードがどこに関与しているかを見やすくします同様のフィルタをコールツリービューに適用できます下のバーの「コールツリー」ボタンをクリックし「システムライブラリを非表示にする」チェックボックスを有効にしますこれでシステムライブラリからすべての関数が除外されコードに集中しやすくなりますコールツリー表示ではほぼすべてのバックトレースに「BackgroundThumbnailView. body.getter」呼び出しが含まれています bodyゲッタを早くした方が良さそうですよね？実はそうでもないのですメインスレッドがビジー状態であることがわかりますつまり CPUは多くの作業をしているということですまた CPUが多くの時間を費やしているメソッドも見つかりましたしかし今は2つの異なるケースがありますこのメソッドでは多くのCPU時間を費やしている可能性がありますメソッド自体が長時間実行されるからですしかし単に何度も呼び出されるからかもしれませんそれがここに表示される理由ですメインスレッドの作業をいかに減らすかはどのケースを想定しているかによります
典型的なコールスタックは次のような構造になっていますメイン関数からの呼び出しがあり UIフレームワークや他の多くのものを呼び出しますそしてある時点でコードが呼び出されますこの関数が1回だけ呼び出される場合ここでのタートル関数のように 1回の呼び出しには長い時間がかかります次に何を呼び出すかを見てみましょう多分多くの作業をするでしょう作業を減らすことができるかもしれませんしかし私たちが調査している方法がこのユニコーンのように何度も呼び出されている可能性もありますもちろんその作業も同様に何度も繰り返されますこれは通常呼び出し元がいてユニコーンという関数を何度も呼び出しているからです例えばループからです焦点を当てた関数ユニコーンが行うことを最適化するよりもどうすれば呼び出す頻度を減らせるかを調査する方が有益かもしれません
つまり次に見るべき方向は抱えているケース次第ですタートルのケースのように長く続く関数の場合その実装と呼び出し先を見たいと思いますもっと下を見る必要がありますただしユニコーンのように関数が何度も呼び出される場合呼び出しているものを調べる方が有益ですその頻度を減らすことができるかどうかを判断しますさらに上を見てみる必要がありますしかし Time Profilerではどのケースかわかりませんユニコーンとタートルへの呼び出しが次々に起こったと仮定しましょう Time Profiler はCPU上で一定間隔で何が実行されているかを確認してデータを収集しますそしてサンプルごとにCPU上でどの関数が現在実行されているかをチェックしますこの例ではタートルとユニコーンの両方を 4回獲得しますしかしこれは非常に速いタートルである可能性もありユニコーンにはもっと時間がかかりますがあるいは他の組み合わせもありますこれらの状況はすべてTime Profilerに同じデータを作成します
特定の関数の実行時間を測定するには os_signpostを使用しますこの方法についてはWWDC19の「Getting Started with Instruments」でも様々な技術に特化した Instrumentsもあり何が起きているかを正確に知ることができますその1つがSwiftUIのView bodyの instrumentです SwiftUI本体のinstrumentを追加するにはツールバーの右上のプラスボタンをクリックします Instrumentsライブラリが表示されますこれはInstrumentsアプリが提供するすべてのInstrumentsのリストですたくさんあります独自のカスタムinstrumentsを表示することもできます
フィルタ欄に「SwiftUI」と入力すると 2つのinstrumentsが表示されます「View body」instrumentsを選択しますドキュメントウインドウにドラッグして追加しますこのinstrumentは前回記録した時にはドキュメントにはなかったので表示するデータがありませんでも問題はありませんまた記録すればいいだけです時間を節約するためにすでに実行しました SwiftUIの「View Body」instrumentをドキュメントに記録したあとで View Bodyのトラックにもデータが表示されるようになりました SwiftUIのView Bodyトラックには多くの間隔があります少し狭いので Ctrl+Plusを押して高さを増やします SwiftUI View Bodyトラックは間隔をグループ化し実装されているライブラリによって行われます各間隔は1つのview bodyの実行です再びハングにズームインしてみましょう
第2レーンはオレンジの間隔が多くすべて「BackgroundThumbnailView」のラベルが付いていますこれで bodyが何回実行され各回どれだけの時間がかかったのか正確にわかりますオレンジ色は特定bodyの実行時間が SwiftUIで目指しているものよりも少し時間がかかったことを示していますしかしより大きな問題は間隔がいくつあるかということです詳細表示ではすべてのbody間隔の概要が表示されます Backyard Birdsの横にある開示インジケータをクリックすると Backyard Birdsで個々の表示タイプを明らかにすることができますこれはBackgroundThumbnailViewの bodyは 70回実行され平均実行時間は約50ミリ秒で合計実行時間は 3秒を超えることを示していますこれでハング時間のほぼすべてが説明されますしかし 70回は多すぎる気がします 6枚の画像を前面に表示するだけの場合ですこれは bodyを呼び出す頻度を減らすべきケースですしたがって bodyゲッタの呼び出し元を調べて頻繁に呼び出される理由を調べそれを減らす方法を考えるべきです関連するコードに簡単に移動するためにメインスレッドトラックを再度選択し BackgroundThumbnailView.body.getter ノードをセカンダリクリックし呼び出しツリーでコンテキストメニューを表示し「Reveal in Xcode」を選択します
これで Xcodeでbodyの実装が開きますタイプをセカンダリクリックして表示がどのように使用されるか見てみましょう次に「Find」を選択し「Find Selected Symbol in Workspace」を選択します検索ナビゲーターの最初の結果がすでに探しているものです
ここで「BackgroundThumbnailView」は GridRow内のForEach内で使用され Grid内の別のForEach内で使用されています Gridは生成された時点でコンテンツ全体をくまなく計算し全ての背景のサムネイルを計算します必要なのは最初の数枚だけですがしかし代替手段としてLazyVGridがありますこれは1画面を満たすのに必要な表示のみが計算されます SwiftUIの表示には多く遅延バリアントがあり必要な数の表示のみを計算しますこれはしばしば作業を減らす簡単な方法ですしかしイーガーバリアントは同じコンテンツをレンダリングする場合メモリ使用量が大幅に少なくなりますデフォルトで通常のイーガーバリアントを使用し遅延バリアントに切り替えましょう事前に過剰な作業に関連したパフォーマンスの問題が見つかった場合です
WWDC20の「Stacks, Grids, and Outlines in SwiftUI」でこの遅延バリアントを紹介しさらに詳しく説明していますこの更新されたコードをプロファイリングしてみましょう記録を開始します「Choose Background」ボタンをもう1度タップしてハングを再現しますこれでかなり良くなりましたわずかな遅延はありますが前ほどひどくはありません Instrumentsはこれを裏付けています今回記録したハング時間は 400ミリ秒未満でしたマイクロハングです「View Body」トラックでは BackgroundThumbnailのbody実行が 8回だけだったことが示されていますこれは予想通りですこれで十分かもしれませんマイクロハングはあまり目立ちません他のデバイスでもうまく機能しているか確認してみましょう iPadでBackyard Birds をプロファイリングして見ましょう
iPadでBackyard Birdsを実行していますすでに詳細表示になっています「Choose Background」ボタンをタップしますシートが表示されるのに時間がかかります一度表示されればその理由がわかります画面が大きくなったのでサムネイルがたくさんありより多くのスペースがあります Instrumentsもこのハングを記録しました
検査範囲をハング間隔に焦点を合わせます BackgroundThumbnailViewのbodyがまた増えています理にかなっています全画面表示には約40枚のレンダリングが必要ですさらに画面に適合させるためです従って同じコードでiPhoneではほぼ問題なく動作しても iPadでは単に画面が大きいため速度が遅かったのですこれがマイクロハングも修正すべき理由の1つです自分のデスクでのテスト中にマイクロハングと思われるものが様々な条件下では一部のユーザーにとって重大なハングの可能性があります現在画面いっぱいに必要な数の表示しかレンダリングしないのでこれを呼び出す頻度を減らすという点で最適化の可能性を使い果たしました個々の実行をより早くするために何ができるかを見てみましょう検査範囲を単一のBackgroundThumbnailView の間隔に設定しますそしてMain Threadトラックに戻ります Instrumentsは最も重いバックトレース表示でview bodyゲッタを示し「BackyardBackground.thumbnail」のプロパティゲッタを呼び出していることを示していますこれはサムネイル画像を提供するモデルオブジェクトでビューに表示しますこのサムネイルゲッタは「UIImageimageBy PreparingThumbnailOfSize:」を呼び出しますつまりここではオンザフライでサムネイルを計算しているようですこれには時間がかかりますこの場合は約150ミリ秒ですこれはむしろバックグラウンドで行うべき作業でメインスレッドを忙しくさせるべきではありませんよりよく理解するためにどのような変更を行うことができるかサムネイルゲッタの呼び出され方をコンテキストで見てみましょう「BackgroundThumbnailView.body.getter」をセカンダリクリックしこれは最も重いスタックトレース表示のフレームですそして「ソースビューアで開く」を選択しますこれによりコールツリー表示がソースビューアに置き換えられますこれはbodyゲッタの実装を示しています次に実装の行に注釈を付けます Time Profilerサンプルでコードがどこにどれだけの時間を費やしたかを示しますここでのbodyの実装は本当に単純で背景から返されたサムネイルで新しい画像表示を作成するだけですしかしこのサムネイルの呼び出しには時間がかかります別の書き方のアイデアがあります Xcodeにジャンプするには右上のメニューボタンをクリックしますそして「Open file in Xcode」を選択します
先ほどと同様に Xcodeのソースコードを示し変更を行う準備ができています今やりたいことはサムネイルをバックグラウンドで読み込むことです読み込み中に進捗インジケータに表示しますまず読み込んだサムネイルを保持するために状態変数が必要です
次に bodyにすでに読み込まれた画像があれば画像表示で使用しますそうでなければ進捗表示が示されます
後は実際のサムネイルを読み込むだけです表示が見えたら読み込みを開始しますこれが「.task」修飾子の目的です
表示されると SwiftUIがタスクを開始します「サムネイル」ゲッタを呼び出し結果を「画像」に割り当てますこれで表示が更新されます試してみましょう！それでは Instrumentsの記録で「Choose Background」ボタンをタップしますそしてシートがすぐに表示されます！素晴らしいです！進捗インジケータが表示され数秒後にはサムネイルが表示されましたうまくいきました！
しかし Instrumentsはまだ 2秒近くのハングを示していますここで起こったことはハングするのが少し遅くなりました Backyard Birdsアプリのどこでこれが起こるのか説明しましょうすでに詳細表示になっていますすぐにもう一度「Choose Background」ボタンをタップしますその後シートを直接閉じてみます完了ボタンをタップしてください「背景を選択」して「完了」です何度もタップしてしまいましたが読み込みが行われている間は私のタップは無視されましたこれがInstrumentsが教えてくれたハングですシートが表示されたあとに起こります
少し異なるタイプのハングですメインスレッドがビジー状態かブロックされているかの違いについてはすでに説明しましたハングを調べる別の方法もあります何が原因でいつ起こるのかこれらを同期ハングと非同期ハングと呼んでいます
ここではメインスレッドが作業をしていますイベントが発生した時そのイベントの処理に時間がかかるならそれはハングです仮にそれをコントロールできイベントが素早く処理されるとしますしかしメインスレッドで後でする作業を遅らせただけかもしれませんまたは他のメインスレッドの作業の後イベントが発生するかもしれませんそのイベントは処理される前に前の作業が終わるまで待たなければなりませんそれでもまだハングが発生します個々のイベント処理のコードはすぐに終了しますが私たちのプラットフォームでのハング検出の仕組みはメインスレッド上のすべての作業項目を見て長すぎないかを検査しますもしそうならハングの可能性があるとマークされますこれはユーザー入力の有無に関係なく行われますユーザー入力がいつでも入ってくる可能性があるため実際にハングすることになりますつまりハング検出はこのような非同期や遅延のケースも検出できるということですただし実際に発生した遅延ではなく潜在的な遅延を測定するだけです
非同期ハングを非同期と呼ぶのは頻繁に発生するためですメインキューでの「dispatch_async」による作業やメインアクタ上で非同期に実行される SwiftConcurrencyタスクで発生しますしかしメインスレッドでの作業を引き起こすものであれば何でも起こり得ます最初に見たハングは同期ハングでしたボタンをタップするとそのタップにより長時間の作業が発生し結果が表示されるのが遅くなります
この直近のハングは非同期または遅延ハングです完了ボタンをタップしてもそれ自体が高額な作業をするわけではありませんしかしメインスレッドにはまだ作業が残っていてタップの処理を妨げていますつまりアプリを使用している人は気づかないかもしれませんがこの間にアプリを操作しなければそうした場合に備えてこのようなケースを修正する必要があります今すぐそうしましょうさてここでInstrumentsに戻りますすでに選択範囲を非同期ハングに設定しズームインしていますビューボディトラックの概要表示で Instrumentsは現在75件の呼び出しがあったことを示しています BackgroundThumbnailViewの bodyゲッタにですこれはほとんどのサムネイルの bodyゲッタが2回実行されるからです SwiftUIはグリッドを満たす進捗インジケータを持つ40枚の表示を作成しますしかし実際に表示されるのは 35件だけですその35枚に対して画像の読み込みを開始します画像が読み込まれると表示が更新され bodyが再び呼び出されます合計75回のbodyゲッタが実行されます
合計75回のbodyゲッタでさえ 1ミリ秒よりはるかに短いですつまり bodyゲッタは今では速くなりましたその部分はうまくいきましたしかしまだハングがありますもう一度「メインスレッド」トラックを選択しますそして最も重いスタックトレース表示で Instrumentsはまだサムネイルゲッタであることを示しメインスレッドで長い時間がかかっています今度はクロージャで呼び出されます「BackgroundThumbnailView. body.getter」内で呼び出されます直接bodyゲッタではありませんこれをダブルクリックするとソースビューアを開くショートカットですこれはまさにバックグラウンドで実行されることを期待していたコードですタスク修飾子クロージャ内にあるためですこのコードは現時点で実行されるべきですがメインスレッドではそうではありませんこのような問題に対しては Swiftの並行処理タスクが期待通りに実行されない場合は別の便利なinstrumentがあります Swift Concurrency Tasks instrumentですすでに同じ動作を記録し Swift Concurrency task instrumentを追加しました Swift Tasks instrumentはドキュメントに概要トラックを追加しますしかし今回のケースでより興味深いのは各スレッドトラックに寄与するデータですメインスレッドトラックでは Swift Tasks instrumentから新しいグラフがあります 1つのトラックに複数のグラフを表示できますスレッドトラックヘッダの小さな下向き矢印をクリックするとどのグラフを表示するか設定できます Time ProfilerのCPU使用率グラフのように別のグラフを選択することもできますまたは Commandキーを押しながらクリックして複数を選択しますこれで InstrumentsはCPU使用率とこのスレッドのSwift Tasksグラフを一緒に表示しますハング間隔に再度ズームインします「Swift Tasks」レーンには明確に表示されメインスレッドでは大量のタスクが実行されます検査範囲をいずれかに設定しプロファイル表示で最も重いスタックトレースをチェックしこのタスクがサムネイルの計算作業をラップしていることを確認します
従ってこの作業は望んでいたようにタスクに正しくラップされていますしかしタスクはメインスレッドで実行されていますがこれは予期外ですここで何が起こっているのか説明しましょうまず bodyゲッタは @MainActor注釈を継承しています SwiftUIの表示プロトコルからです「表示」プロトコルで「body」は「@MainActor」と注釈されているのでこれを実装すると bodyゲッタも暗黙的に @MainActorとして注釈されます次に「.task」修飾子のクロージャは周囲のコンテキストのアクタ分離を継承するように注釈が付けられていますつまり bodyゲッタはMainActorに分離されているためですタスククロージャも同様です従ってこのクロージャで実行されるコードはすべてデフォルトではメインアクタ上で実行されます「サムネイル」ゲッタは同期しているためメインスレッド上で同期的に実行されます
Swiftの並行処理タスクはデフォルトで周囲のコンテキストのアクタの分離を継承します同じ動作は SwiftUIの .task修飾子も同じですメインアクタから離れる方法は2つありますメインアクタにバインドされていない関数を非同期的に呼び出しタスクがメインアクタから離れることができますしかしそれが不可能な場合もあるでしょう次に周囲のアクタのコンテキストからタスクを明示的に切り離すことができます「Task.detached」を使用しますがそれは強引なやり方です単に既存のものを中断するよりも別のタスクを作成するのはより高くつきます SwiftUIはタスク修飾子で作成されたタスクも自動的にキャンセルします対応する表示が消えた時ですしかしこのキャンセルは新しい非構造化タスクにはTask.detachedのように伝搬しません詳細については WWDC22の「Swiftの並行処理の可視化と最適化」とアプリの応答性の向上に関するドキュメントをご覧くださいこの場合すでに非同期コンテキストにいるためサムネイル関数を非分離で非同期にするのは簡単ですオプション1を選択しますサムネイルの読み込みコードです問題はこのタスクがメインアクタで実行されることです bodyゲッタのメインアクタの分離を継承するためですサムネイルゲッタは同期しているためメインアクタにも留まります修正は簡単ですサムネイルゲッタの定義に移りますゲッタを非同期にしそれから表示構造体に戻ります…
ゲッタは非同期になっているためその前にawaitを追加する必要があります
これで「サムネイル」ゲッタはメインスレッドの代わりに Swift Concurrencyの並行スレッドプールで実行されるようになります試してみましょう再び詳細表示にして「背景を選択」をタップしますすごく速いです！ハングがなかっただけでなく全体的に読み込みが速くなったように思われます進捗表示はほとんど見ていません Instrumentsでハングがないことが確認されましたここでは CPUの使用率が高いようです拡大してみましょうここでサムネイルの読み込みが行われますメインスレッドを確認するとすべてのタスク間隔が非常に短くなっていることが確認できます他のスレッドトラックまでスクロールダウンすると Swiftのタスクが他のスレッドで連続的ではなく並列に実行されていることがわかりますこれによりマルチコアCPUがより有効に活用されますこれですべてのサムネイルを約1.5秒ではなく数百ミリ秒で計算できますこの間もメインスレッドは応答し続けています従ってこれは完全に修正されました
応答しないメインスレッドを調査し修正しましたメインスレッドがビジー状態であることが原因でこれはハング中にメインスレッドが大量の CPUを使用していることから特定できましたハングがユーザーとのインタラクションの一部として直接発生する同期的な場合とメインスレッドで先に予定されていた作業が次のイベントの処理を遅れさせる非同期的な場合がありますそして Instrumentsがその両方のケースを検出できることも経験しました作業を減らしバックグラウンドで減らすことのできない他の作業をすることでハングを修正しましたメインスレッドに戻るのは UIを更新するためだけですしかしまだ見ていないケースが 1つありますブロックされたメインスレッドでこの場合メインスレッドは CPUをほとんど使用しません他の次元はブロックされたメインスレッドにも同様に適用されますがこのようなケースを分析するには他のInstrumentsが必要です例を見てみましょう
別のハングからのトレースファイルですこのハングをズームインしました数秒の長いものです「メインスレッド」トラックで CPU使用率のグラフを見ると初期のCPU使用率はありますがその後は何もありませんこれは明らかにメインスレッドがブロックされたケースです Time ProfilerがCPUで実行されているものを見本としてデータを収集する方法について説明しました
拡大すると CPU使用率グラフに個々の見本まで表示されますこの各マーカーは Time Profilerが取得した見本です右側にはいくつか見本がありますがそのあとは何もありませんしかし見本なしの時間範囲を選択すると Time Profilerでは何が起こっているのかわかりませんこの間はデータが記録されなかったためです従って別のツールつまりスレッドステイツのinstrumentが必要ですこれまでの他のinstrumentsと同様に Instrumentsライブラリから追加できますすでに同じハングを再度記録しましたが今回は「Thread State Trace」 instrumentが追加されましたこのinstrumentには新しいトラックが追加されましたしかし「Swift Concurrency」 instrumentのように興味深いデータは実際には「スレッド」トラックにありますつまりメインスレッドには非常に長い「ブロックされた」間隔があり 6秒以上でハング時間のほとんどがこれで説明されますその真ん中をクリックするとInstrumentsのタイムカーソルがそこに移動しこれにより詳細領域のナラティブ表示も更新されこのブロックされた状態のエントリを表示しますナラティブ表示ではスレッドのストーリーがわかりますいつなぜ何をしていたのかを示します
選択された時間ではスレッドは 6.64秒間ブロックされたことがわかりますシステムコールのmach_msg2_trapを呼び出していたためです右側には再びバックトレース表示がありますしかしこのバックトレースは最も重いバックトレースではありませんアグリゲーションでもありませんこれは mach_msg2_trapシステムコールの正確なバックトレースですそれが原因でスレッドがブロックされました関数の呼び出しは下部のリーフノードとして表示されますそのコールスタックが上に表示されますコールスタックは MLModelを割り当てた結果システムコールが発生したことを示していますこれは「ColorizingService」型のオブジェクトを割り当てたために発生しこのColorizingServiceの「shared」と呼ばれるシングルトンプロパティの一部として呼び出され次に bodyゲッタのクロージャによって呼び出されましたそのクロージャをダブルクリックすると再びソースビューアに移動し呼び出したコードを見つけることができますこの行は無害に見えますよね？詳しく見てみましょう
ColorizingServiceの共有プロパティにアクセスしそれをローカル変数に格納しますただし共有プロパティが生成するため無害ではありません共有ColorizingServiceインスタンスに初めてアクセスすると今度はモデル読み込み機構全体が起動しスレッドがブロックされますそれで次のように思われるかもしれません「これを『await』の後の非同期部分内に移動しよう」しかし直観に反してこれでは問題は解決されません「await」キーワードは後続のコードでの非同期関数呼び出しにのみ適用されますこの例では「colorize」関数は「async」ですしかし「shared」プロパティはそうではありません静的なletプロパティなので最初にアクセスされた時に遅延初期化されこれは同期的に起こります awaitキーワードを使っても変わりません従って同期呼び出しは引き続きメインスレッドで発生します前の例と同じ方法でこれを修正できます sharedプロパティも「async」にしメインアクタから離れることで解決できます自分のスレッドに代わって他の場所で前進する作業を待っている場合はこれは通常は問題ありませんしかしスレッドがブロックされる他の一般的な理由はロックまたはセマフォです留意すべきベストプラクティスと Swiftの並行処理でロックとセマフォを使う時に回避すべき事項については WWDC21の「Swift concurrency: Behind the scenes」をご覧ください
最後に次のことをお話ししたいと思いますブロックされたメインスレッドに関連するもう1つのケースですこれが先ほど見たトレースです右が先ほど調べたハングですメインスレッドがブロックされていますしかしその左側には他のケースもありますメインスレッドが何秒もブロックされるケースですしかし Instrumentsはこれをハングの可能性があるとは警告しませんここではメインスレッドはユーザー入力がないため単にスリープ状態になっていますオペレーティングシステムの観点からはブロックされていますしかし何もすることがない時に実行しないことでリソースを節約しているだけです入力データが入るとすぐに起動して処理します従ってブロックされたスレッドが応答性の問題かどうかを判断するにはスレッド状態のinstrumentではなくハングinstrumentを見てください
メインスレッドがブロックされていても応答していないとは限りません同様に CPU使用率が高いからといってメインスレッドが応答しないことを意味するものではありませんでもメインスレッドが応答しない場合はブロックされているかメインスレッドがビジーであることを意味しますハング検出ではこれらすべての詳細を考慮しますメインスレッドが実際に応答しなかった間隔にのみラベルを付けハングする可能性があると表示しますこのセッションで覚えていることが1つだけあるとすればそれは次のとおりですメインスレッドで行っている作業が何であれ 100ミリ秒未満で終了しメインスレッドを解放して再びイベント処理に使えるようにすべきです短ければ短いほど良いですハングを詳細に分析するには Instrumentsが最適ですメインスレッドがビジーかブロックされた状態かの区別を覚えておいてくださいハングはメインスレッドでの非同期作業でも発生することを覚えておいてくださいハングを修正するには作業を減らすか作業をバックグラウンドに移すことです時には両方の場合もありますそして作業量を減らすということは作業に適切なAPIを使うことを意味します一般的にはまず測定し最適化する前に実際にハングがあるかどうかを確認します確かにベストプラクティスはありますがただし並列と非同期コードのデバッグもさらに困難ですすべてのことに驚くことがよくあります実際にはとても速いですそして実は何が遅くなるのかすべてのハングを見つけて分析し修正することを楽しんでくださいご視聴ありがとうございました ♪ ♪

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    
    var body: some View {
        Image(uiImage: background.thumbnail)
    }
}

19:58 - BackgroundSelectionView with Grid

var body: some View {
        ScrollView {
            Grid {
                ForEach(backgroundsGrid) { row in
                    GridRow {
                        ForEach(row.items) { background in
                            BackgroundThumbnailView(background: background)
                                .onTapGesture {
                                    selectedBackground = background
                                }
                        }
                    }
                }
            }
        }
    }

20:03 - BackgroundSelectionView with Grid (simplified)

var body: some View {
    ScrollView {
        Grid {
            ForEach(backgroundsGrid) { row in
                GridRow {
                    ForEach(row.items) { background in
                        BackgroundThumbnailView(background: background)
                    }
                }
            }
        }
    }
}

20:26 - LazyVGrid variant

var body: some View {
    ScrollView {
        LazyVGrid(columns: [.init(.adaptive(minimum: BackgroundThumbnailView.thumbnailSize.width))]) {
            ForEach(BackyardBackground.allBackgrounds) { background in
                BackgroundThumbnailView(background: background)
            }
        }
    }
}

24:05 - BackgroundThumbnailView

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    
    var body: some View {
        Image(uiImage: background.thumbnail)
    }
}

24:59 - BackgroundThumbnailView with progress (but without loading)

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
        }
    }
}

25:26 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

29:59 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

31:41 - BackgroundThumbnailView with async loading on main thread (simplified)

struct BackgroundThumbnailView: View {
    // [...]
    
    var body: some View {
        // [...]
        ProgressView()
            .task {
                image = background.thumbnail
            }
        // [...]
    }
}

33:40 - BackgroundThumbnailView with async loading on main thread

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = background.thumbnail
                }
        }
    }
}

33:59 - synchronous thumbnail property

public var thumbnail: UIImage {
    get {
        // compute and cache thumbnail
    }
}

34:03 - asynchronous thumbnail property

public var thumbnail: UIImage {
    get async {
        // compute and cache thumbnail
    }
}

34:08 - BackgroundThumbnailView with async loading in background

struct BackgroundThumbnailView: View {
    static let thumbnailSize = CGSize(width:128, height:128)
    
    var background: BackyardBackground
    @State private var image: UIImage?
    
    var body: some View {
        if let image {
            Image(uiImage: image)
        } else {
            ProgressView()
                .frame(width: Self.thumbnailSize.width, height: Self.thumbnailSize.height, alignment: .center)
                .task {
                    image = await background.thumbnail
                }
        }
    }
}

38:52 - shared property causes blocked main thread

var body: some View {
    mainContent
        .task(id: imageMode) {
            defer {
                loading = false
            }
            do {
                var image = await background.thumbnail
                if imageMode == .colorized {
                    let colorizer = ColorizingService.shared
                    image = try await colorizer.colorize(image)
                }
                self.image = image
            } catch {
                self.error = error
            }
        }
}

39:00 - shared property causes blocked main thread (simplified)

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                let colorizer = ColorizingService.shared
                result = try await colorizer.colorize(image)
            }
    }
}

39:10 - shared property causes blocked main thread + ColorizingService (simplified)

class ColorizingService {
    static let shared = ColorizingService()
   

    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                let colorizer = ColorizingService.shared
                result = try await colorizer.colorize(image)
            }
    }
}

39:25 - shared synchronous property after await keyword still causes blocked main thread

class ColorizingService {
    static let shared = ColorizingService()
   

    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                result = try await ColorizingService.shared.colorize(image)
            }
    }
}

39:39 - shared synchronous property after await keyword still causes blocked main thread (+colorize function)

class ColorizingService {
    static let shared = ColorizingService()
   
    func colorize(_ grayscaleImage: CGImage) async throws -> CGImage
    // [...]
}

struct ImageTile: View {
    // [...]
    
    // implicit @MainActor
    var body: some View {
        mainContent
            .task() { // inherits @MainActor isolation
                // [...]
                result = try await ColorizingService.shared.colorize(image)
            }
    }
}

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

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

関連する章

リソース

関連ビデオ

WWDC23

WWDC22

WWDC21

WWDC20

Tech Talks

WWDC19

WWDC16