Core DataとCloudKitの動作を最適化する

Core DataとCloudKitの動作を最適化する

Core DataとCloudKitの実装の最適化に有効な、 3 つの開発サイクルについてご紹介します。Appのアーキテクチャと機能セットを分析して仮定を検証し、大規模なデータセットを取り込んだ後の動作の変化を調べ、ワークフローを改善するための実用的なフィードバックを得る方法を紹介します。このセッションを最大限に活用するには、ご利用のデータモデルとCloudKitとの同期に関する知識を習得しておくとよいでしょう。

リソース
関連ビデオ

WWDC22
- Core Dataスキーマを進化させる
WWDC21
- CloudKitとCore Dataでデータを共有するAppの構築
WWDC20
- Xcode Organizerでパフォーマンス問題を診断する
WWDC19
- CloudKitでCore Dataを使用する
- Instrumentsの概要
ダウンロード

私はNick Gillett Core Dataチームのエンジニアです NSPersistentCloudKitContainer を使うAppについて開発者ツールを使用して説明します生産的かつ教育的な方法でAppを探索する方法について詳しく見ていきます
次にいくつかのツールを使って Appの動作を分析します最後はNSPersistentCloudKit Containerについて詳細かつ実用的なフィードバックを提供する方法です
エンジニアリングを水の循環のようなものと考えています私は機能が存在する空間を探索することから作業を始めます学んだことをもとにツールやテストを組み合わせ再現性のある環境で自分の作品を解析します最後に同僚と結果を確認しフィードバックを集めますこのサイクルの目的は仕事をしながら学んだことを永続的に記録することです Appleのプラットフォームには Xcode Instruments XCTest といった素晴らしいツールが揃っていますこれらのツールは実用的なフィードバックを提供する豊富な診断情報を収集することを可能にします
ここでは過去の多くの知識を参照します NSPersistentCloudKitContainerと紹介する Core Data CloudKit Sample Appについての詳細は「CloudKit と Core Data でデータを共有する App の構築」と「CloudKit で Core Data を使用する」で解説してます XcodeとInstrumentsを使いテストを実行する方法や Device organizerの使い方も紹介します「Instruments の概要」と「Xcode Organizer でパフォーマンス問題を診断する」を復習してツールチェーンの2つの重要な部分について学ぶことをお勧めしますサイクルの最初の部分である「探索」を始めましょう探索の第一の目的は学ぶことです Appがどのように機能するか私が仮定するすべてに挑戦し検証したいと思いますこのボタンをタップするとどうなるか？永続ストアにデータを保存すると NSPersistentCloudKitContainer は同期されるか？大きなデータセット操作時にメモリが不足してないか？ Core Dataから見ればこれらの質問はすべて Appが処理するデータの影響を受けますサンプルの CoreDataCloudKit Appはこのデータモデルを使います
タイトルとコンテンツのテキストフィールドを持つ一連の投稿を管理します投稿には添付ファイル通常は画像が添付されることがありこれは非常に大きくなる可能性があるため
ImageDataはオンデマンドでロードできるように 1対1の関係で保存されます今回はデータセットに焦点を当てて調査していきますデータの形状構造分散を変更すると Appに何が起こるのか
サンプルにはリリース以来それを調査するための方法が組み込まれています「The Generate 1000 Posts」ボタンはラベル記載通りに機能しますタップすると短いタイトルの1000件の投稿のサンプルデータセットが生成されます投稿テーブルビューはこのレベルのデータを簡単に処理します次にAppで異なる形状サイズのデータセットをどのように探索できるかという質問です「The Generate 1000 Posts」ボタンはアルゴリズムデータジェネレータを実行します 1000個のオブジェクトを挿入すべてのフィールドに値があることまたはどのフィールドにも値がないこと等のルールに従います私たち自身がデータのジェネレータでもありますコードやSQL Appと直接やりとりすることで特定のデータセットを手作りすることができこれらの生成されたデータセットは後で使用または分析するために保存できます大きなデータセットを探索するために LargeDataGeneratorを定義し単一のメソッドgenerateDataを指定して新しいデータセットを構築できます 2つのforループで 11の画像添付ファイルが関連付けられた 60個の投稿セットを生成できます全部で660枚の画像です画像あたり平均10〜15メガバイトのサイズでデータセットはほぼ10GBのデータを消費しますシンプルなインターフェースを使ってこのようなテストでデータジェネレータを簡単に呼び出せますこの1行のコードでテストで使用する10GBを超える典型的なデータを生成します
さらにデータジェネレータが正しく動作することを確認する検証メソッドをテストに組み込むこともできますたとえば各投稿に本当に 11 個の画像が添付されていることを確認するメソッドです
これには NSPersistentCloudKitContainer を同期させる必要がありますそれでは新しいテストを作成します
NSPersistentCloudKitContainer のインスタンスを使います簡単にするためにヘルパーメソッドを作成しました次に LargeDataGenerator を使ってコンテナに目的のデータセットを入力しますデータのエクスポートを完了するのを待ちますこのテストでは大きなデータセットをアップロードする時間として最大で20分間待ちます
このテストではさまざまな種類のイベントに対して多くの待ち時間が発生していますここではコンテナを作成した時にコンテナのセットアップが終了するのを待っていますヘルパーメソッドを使ってエクスポートイベント用に XCTestExpectationsを作成します詳細を見ていきましょう
このメソッドは希望するイベントタイプと NSPersistentCloudKitContainer のインスタンスを引数として受け取ります NSPersistentCloudKitContainer の eventChanged 通知を受け取りために XCTestCase の expectationForNotification メソッドを使用してコンテナ内の永続ストアごとに期待値を作成します通知ハンドラブロックでは受信したイベントが期待値が対象とするストアに対して正しいタイプであることを確認し endDate が nil でないことを確認して終了しますこのテクニックを使うことで NSPersistentCloudKitContainer のイベントとテストの制御点を強く関連付けることができますテストに戻ってデータをインポートするコンテナを追加しますこれはある仕掛けを利用したテクニックです NSPersistentCloudKitContainer の新しいインスタンスを空のストアファイルで作成するのですこれにより NSPersistentCloudKitContainer の初回インポート時にこのデータがデバイスにダウンロードされる際何が起こるかを調査することができます Appの中でデータセットがどのように動作するのか見ていきましょうそのためにデータジェネレータをユーザーインターフェースにバインドします「Generate Large Data」ボタンをタップするとデータジェネレータがデータセットにデータを入力します 2番目のデバイスでは NSPersistentCloudKitContainer がデータのダウンロード中にテーブルビューが表示されます個々の投稿をタップすると添付ファイルのダウンロードと入力が段階的に行われていることを確認できますこのユーザーインターフェイスはアラートコントローラが駆動します LargeDataGenerator のシンプルなインターフェイスにより 2行のコードで新しいアラートアクションを追加できます明瞭かつ簡潔でわかりやすくなっています
データジェネレータの概念を使用して Appの動作を見てきましたデータジェネレータはテストやカスタムUI コマンドライン引数など特定のユースケースに適した方法で Appの中で動かすことができます Appにデータを入力する方法がわかったので Appの動作の変化について分析する準備ができましたこのセクションでは大規模なデータセットで Appがどのように動作するか分析するためのツールやテクニックについて学びます
具体的には Instrumentsを使用して LargeDataGeneratorで作成されたデータセットの時間とメモリの複雑さを分析しますそしてシステムログから得られる豊富な情報を見ていきます NSPersistentCloudKitContainer CloudKit システムスケジューラプッシュ通知からのアクティビティの記録があります Instruments を見ていきましょう私が気に入っているのは Xcode を使用するとテストの動作を簡単に分析できることです実行ボタンのクロージャから「Profile」を選択するだけです Xcodeはテスト用のビルドを行い Instrumentsを自動的に起動します Time Profiler Instruments をダブルクリックして処理に時間がかかっている部分を調べることができます
記録ボタンをクリックすると Instruments は App を起動し選択したテストを実行しますこのテストの実行にはかなり時間がかかっているようですスキップして理由を見てみましょう Instruments は既にメインスレッドを選択しており右側にテスト実行の最も重いスタックトレースが表示されます
もう少し読みやすくします
これでよしとしましょう LargeDataGenerator がサムネイルを生成するのに多くの時間を費やしていることがわかりますバグなのか機能なのかどうすれば判断できるでしょう？
LargeDataGenerator は添付ファイルごとに新しいサムネイルを生成するためにこんなコードを書いています App のデータモデルを見るとサムネイルは特殊で imageData からオンデマンドで計算されますつまりこの行は不要ですデータジェネレーターはこれに時間を浪費していますこれを取り除くことができますテストのパフォーマンスはどのように変わるでしょうか更新後のデータジェネレータで App をリビルドした後 Instruments でテストを再度実行します正直なところあまり変化は見られませんが数秒後にテストが完了します前回のテスト実行よりもはるかに高速ですそれではどこに一番時間がかかったのか見ていきましょう
右側のドロワーで最も重いスタックトレースが永続ストアに画像を保存する所だとわかりますこれだけのデータ量を管理するテストではまさに想定内のことです
1つの変更により generateData テストの実行時間を短縮しました 10分の1の時間で実行しますテストを分析することで常にバグを発見できるわけではありませんが特定のデータセットを扱う際に App がどこに時間を費やしているか詳しく知ることができる場合もありますいずれにしても貴重な学習です
Time Profilerを使えば App がデータセットのどこに時間を費やしてるか調べることができますデータセットの大きさからテスト実行でどれくらいメモリを消費するかも気になるところです Allocations instrument を使って実行しましょう Xcode を使って Instruments を起動し測定を行います Time Profiler Instrumentを選択する代わりに Allocationsをダブルクリックします
そして「Record」をクリックします
テストは高速に実行しているにもかかわらず 10GB以上のメモリを使っていますテスト実行中はほぼ全てのデータセットがメモリに保持されていることが分かりますその理由を探ってみましょう
確認したいアロケーションの範囲を選択します下のペインに大きなアロケーションが多数ありますこのディスクロージャをクリックしてテスト用にアロケーションされた大きなデータブロックの一つをクリックすれば調べることができます特定のブロックがアロケーションされて約２秒間解放されませんでしたテスト時間にしては長すぎですなぜそうなるのでしょうか
右のスタックトレースを展開して調べます
経験上アロケーションとリリースのスタックトレースから Core Data によってフォルトが発生し管理対象オブジェクトコンテキストが作業を終了したときに解放されていますこれはオブジェクトがフェッチオートリリースプールまたはテスト内のオブジェクトによって保持されたことを示しています
コードの問題のある部分は投稿のベリファイアにあります添付ファイルから画像を読み込んで検証していますでも添付ファイルと関連する画像データはマネージドオブジェクのトコンテキストに登録されたままです問題を解決するためにはいくつかの方法があります例えばテーブルビューではバッチフェッチを使用してテーブルが投稿をスクロールする時に画像を解放できますただしテストの実行速度が速すぎて効果がありませんアプローチを変える必要があります投稿をフェッチ確認する代わりに添付ファイルをフェッチできます objectIDのみをフェッチした場合マネージドオブジェクトコンテキストは要求されるまでロードされたオブジェクトをキャプチャしません
NSManagedObjectContext の objectWithID メソッドを使い検証をしながら添付ファイルをフェッチすることができます 10個の添付ファイルを検証するたびにコンテキストをリセットしキャッシュされた状態と関連するメモリを全て解放します
変更してテストを再実行すると想定内の対応可能なレベルのメモリ消費になったことがわかります実際ベリファイアがオブジェクトを挿入する際に使用するメモリは LargeDataGenerator よりもさらに少なくなっています
この修正がどのように機能するかを知るために特定のアロケーションを掘り下げてみましょう
まず対象のアロケーションの範囲を選択します次に検証するサイズを選択します
解放されたオブジェクトを見つけるために破壊されたオブジェクトを有効にしておき解析するアロケーションを選択します
右側にアロケーションスタックのトレースが表示されますがどこで解放されたかアロケーションリリースイベントを選択しますこのスタックトレースは NSManagedObjectContext が非同期的にアロケーションをリリースし消費されたメモリを解放していることを意味していますこの手法でテストのメモリ消費の最大値を確認しメモリの少ないシステムで実行できるようになります
テストを Instruments と組み合わせることにより望ましくない動作を発見しましたその動作に直接対処するために対象を絞った変更を加えて結果を確認しましたシステムログには Appや CloudKit スケジューリングプッシュ通知など Appが依存するシステムサービスに関する豊富な情報も含まれています MacBookPro と iPhone の間で 1つの投稿を同期してみます Macで短いタイトルを付けて新しい投稿を行い iCloudにアップロードするとシステムログにさまざまなイベントが記録されます
iPhone と同期させると中間状態となることもありシステムログは対応する一連のイベントをキャプチャします MacBook Proでは NSPersistentCloudKitContainer は Appのプロセス内で動作します（CoreDataCloudKitDemo）データが永続ストアに書き込まれると DASD というシステムサービスに今そのデータを CloudKit にエクスポートするのに適したタイミングか尋ねます適切であれば DASD は NSPersistentCloudKitContainer にアクティビティを実行するように指示します NSPersistentCloudKitContainer は cloudd というプロセスでの作業をスケジュールし変更したオブジェクトを CloudKit にエクスポートしますコンソール App を使ってログを観察できますアプリケーションのログは CoreDataCloudKitDemo というプロセスを探しますここではエクスポートが完了しているものを選びましたスケジューリングはプロセス dasd と App のストアからのログを見たいと思いますここでは Appのプライベートストアのエクスポートアクティビティ開始を選択しましたログをもう少し詳しく見てみましょう NSPersistentCloudKitContainer が dasd で作成するアクティビティは特定のフォーマットに従いますアクティビティ識別子は NSPersistentCloudKitContainer が使う特定のプレフィックスとアクティビティが属するストアのストア識別子で構成されています dasd のログにはアクティビティを実行できるか決定する方法に関する情報が含まれています Appの実行に影響を与えるポリシーは最終的な判断とともにログに記載されます
最後に cloudd というプロセスが CloudKit からの情報をログに記録するのですが私は作業中のコンテナ識別子でログをフィルタリングするのが好きですここでは先ほどのエクスポートに対応するレコードの修正操作を選択しました
受信側のデバイスで変更をインポートする場合もう一つのプロセスを観察する必要があります apsd というプロセスがプッシュ通知を受信して App に転送しますこれにより NSPersistentCloudKitContainer はエクスポートプロセスと同様の一連のアクティビティを開始します dasd にインポートを実行する時間を要求し cloudd と連携して更新されたすべてのオブジェクトを CloudKit からフェッチしローカルストアにインポートします
Apsd は App のプッシュ通知を受信してログに記録しますこのログにはいくつかの重要な詳細が記録されますログメッセージにはコンテナ識別子とプッシュ通知をトリガーしたサブスクリプション名とゾーン識別子が含まれます NSPersistentCloudKitContainer によって管理され com.apple.coredata.cloudkit のプレフィックスを持ちます
今のコンソールAppは素晴らしいです Mac で開発中はターミナルで log stream コマンドを使って App と一緒にこれらのログを表示するのが好きです
次の条件ごとに1つのターミナルウィンドウまたはタブを開きます最初は App ですログを見て CloudKit サーバーで起きていることを確認します次にプッシュ通知ログの apsd です最後に dasd を使用して NSPersistentCloudKitContainer のアクティビティで何が起きてるか確認します検索条件はコンソール App でクエリをガイドする為にも使います
使用するデバイスについて多くの情報を利用できます課題は分析するためにどのツールを使うべきかです instrument だけでランタイムやメモリのパフォーマンスなどさまざまなトピックについて学ぶことができますシステムログは App の実行とバックグラウンドでのシステムの実行を説明するイベントをキャプチャします開発サイクルの最後のフェーズは役に立つフィードバックを収集して提供することですこのセクションではデバイスから診断情報を収集する方法を説明しますこの情報を使用して問題に対処可能で特定の目標に沿ったフィードバックを生成する目的ですこれらの手法はあらゆるデバイスからフィードバックを収集するのに役立ちます診断情報を収集するには 3つのステップがあります CloudKitlogging プロファイルをインストールします問題を特定して効果的にトリアージするためのロギングが有効になります次にデバイスから sysdiagnose を収集します最後はデバイスに物理的にアクセスできる場合 Xcode から永続ストアファイルを収集しますロギングプロファイルをインストールするには開発者ポータルの「Profile and Logs」で CloudKit Profile をダウンロードします Profile をインストールする通知が表示されるデバイスもありますただし iOS では設定 App から手動でインストールする必要があります
設定 App の「Downloaded Profile」でダウンロードしたプロファイルをタップします手順に従ってインストールを完了しますインストールした後デバイスを再起動すると有効になります
デバイスが再起動したらキャプチャしたい動作を再現し sysdiagnose を実行します sysdiagnose の取得はキーコードを使用して行います詳細はプロファイルの説明ページをご覧くださいたまたま気づいたのですが iPhone の場合音量ボタンとサイドボタンを数秒間押し続けてから放しますすると「設定App」から「sysdiagnose」を利用できますやり方については Profile の説明ファイルに記載されています「設定App」で「プライバシー」「Settings」で「Privacy and Security」「解析および改善」に移動し「Analitics and Improvements」に移動し「解析データ」を選択して「Analitics Data」を選択して sysdiagnose が見つかるまでログをスクロールします
「sysdiagnose」をタップしてから共有ボタンをタップすると共有する方法をいくつか選択できます私は分析するために Mac に AirDrop します最後にデバイスオーガナイザを使用して Xcode からストアファイルを収集できます iPhone からファイルを収集するにはインストール済み App のリストでサンプル App をクリック Disclosure ボタンをクリック「Download Conntainer」を選択しダウンロードディレクトリに保存します
これでシステムログとストアファイルの両方を分析できるようになりました log stream コマンドについてすでに説明しましたが sysdiagnose で logshow コマンドを使うと sysdiagnose からログを出力できます前に説明した apsd ログの predicate をコピーしました
log show コマンドの最後の引数は logarchive です何も指定しない場合は実行中のマシンのシステムログを表示しますここでは sysdiagnose で取ったログを読み込むように system_logs.logarchive を指定しています例えば、時間範囲を詳細に指定することで気になるイベントが発生した時間帯にフォーカスできます
先ほど説明した多くの条件を組み合わせて App に関連するすべてのアクティビティの統一されたログを形成することもできますこの強力なコマンドを使ってフィードバックレポートに含めチームメイトと共有することで誰もが特定のログの分析に集中することができます
このセッションでは次のことをお話ししましたデータジェネレーターを使用して App の動作を調査 Instrument とシステムログを使用して App を分析 NSPersistentCloudKitContainer を使用する App から実用的なフィードバックを提供または収集する方法です
私はNick Gillett このプレゼンテーションをお届けできて光栄ですご視聴ありがとうございます WWDCをお楽しみください

class LargeDataGenerator {
    func generateData(context: NSManagedObjectContext) throws {
        try context.performAndWait {
            for postCount in 1...60 {
                //add a post               
                for attachmentCount in 1...11 {
                    //add an attachment with an image
                    let imageFileData = NSData(contentsOf: url!)!
               }
            }
        }
    }
}

5:07 - Testing a large data generator

class TestLargeDataGenerator: CoreDataCloudKitDemoUnitTestCase {
    func testGenerateData() throws {
        let context = self.coreDataStack.persistentContainer.newBackgroundContext()
        try self.generator.generateData(context: context)
        try context.performAndWait {                     
            let posts = try context.fetch(Post.fetchRequest())
            for post in posts {
                self.verify(post: post, has: 11, matching: imageDatas)
            }
        }
    }
}

5:33 - Sync generated data in test

func testExportThenImport() throws {
    let exportContainer = newContainer(role: "export", postLoadEventType: .setup)
    try self.generator.generateData(context: exportContainer.newBackgroundContext())
    self.expectation(for: .export, from: exportContainer)
    self.waitForExpectations(timeout: 1200)
}

6:35 - Expectation helper method

func expectation(for eventType: NSPersistentCloudKitContainer.EventType,
                 from container: NSPersistentCloudKitContainer) -> [XCTestExpectation] {
    var expectations = [XCTestExpectation]()
    for store in container.persistentStoreCoordinator.persistentStores {
        let expectation = self.expectation(
            forNotification: NSPersistentCloudKitContainer.eventChangedNotification,
            object: container
        ) { notification in
            let userInfoKey = NSPersistentCloudKitContainer.eventNotificationUserInfoKey
            let event = notification.userInfo![userInfoKey]               
            return (event.type == eventType) &&
                (event.storeIdentifier == store.identifier) &&
                (event.endDate != nil)
        }
        expectations.append(expectation)
    }
    return expectations
}

7:18 - Import data model in test

func testExportThenImport() throws {
    let exportContainer = newContainer(role: "export", postLoadEventType: .setup)
    try self.generator.generateData(context: exportContainer.newBackgroundContext())
    self.expectation(for: .export, from: exportContainer)
    self.waitForExpectations(timeout: 1200)
    
    let importContainer = newContainer(role: "import", postLoadEventType: .import)
    self.waitForExpectations(timeout: 1200)
}

8:23 - Data generator alert action

UIAlertAction(title: "Generator: Large Data", 
              style: .default) {_ in
    let generator = LargeDataGenerator()
    try generator.generateData(context: context)
    self.dismiss(animated: true)
}

10:50 - Eagerly generating thumbnail in data generator

func generateData(context: NSManagedObjectContext) throws {
    try context.performAndWait {
        for postCount in 1...60 {
            for attachmentCount in 1...11 {
                let attachment = Attachment(context: context)
                let imageData = ImageData(context: context)
                imageData.attachment = attachment
                imageData.data = autoreleasepool {
                    let imageFileData = NSData(contentsOf: url!)!
                    attachment.thumbnail = Attachment.thumbnail(from: imageFileData,        
                                                                thumbnailPixelSize: 80)
                    return imageFileData
                }
            }
        }
    }
}

11:13 - Lazily generating thumbnail in data generator

func generateData(context: NSManagedObjectContext) throws {
    try context.performAndWait {
        for postCount in 1...60 {
            for attachmentCount in 1...11 {
                let attachment = Attachment(context: context)
                let imageData = ImageData(context: context)
                imageData.attachment = attachment
                imageData.data = autoreleasepool {
                    return NSData(contentsOf: url!)!
                }
            }
        }
    }
}

14:14 - Problematic verifyPosts implementation

func verifyPosts(in context: NSManagedObjectContext) throws {
    try context.performAndWait {
        let fetchRequest = Post.fetchRequest()
        let posts = try context.fetch(fetchRequest)

        for post in posts {
            // verify post

            let attachments = post.attachments as! Set<Attachment>
            for attachment in attachments {

                XCTAssertNotNil(attachment.imageData)
                //verify image
            }
        }
    }
}

14:49 - Efficient verifyPosts implementation

func verifyPosts(in context: NSManagedObjectContext) throws {
    try context.performAndWait {
        let fetchRequest = Attachment.fetchRequest()
        fetchRequest.resultType = .managedObjectIDResultType
        let attachments = try context.fetch(fetchRequest) as! [NSManagedObjectID]

        for index in 0...attachments.count - 1 {
            let attachment = context.object(with: attachments[index]) as! Attachment

            //verify attachment
            let post = attachment.post!
            //verify post

            if 0 == (index % 10) {
                context.reset()
            }
        }
    }
}

20:41 - Display logs using `log stream`

# Application
log stream --predicate 'process = "CoreDataCloudKitDemo" AND 
                        (sender = "CoreData" OR sender = "CloudKit")'

# CloudKit 
log stream --predicate 'process = "cloudd" AND
                        message contains[cd] "iCloud.com.example.CloudKitCoreDataDemo"'

# Push
log stream --predicate 'process = "apsd" AND message contains[cd] "CoreDataCloudKitDemo"'

# Scheduling
log stream --predicate 'process = "dasd" AND 
                        message contains[cd] "com.apple.coredata.cloudkit.activity" AND
                        message contains[cd] "CEF8F02F-81DC-48E6-B293-6FCD357EF80F"'

24:36 - Display logs with `log show`

log show --info --debug
    --predicate 'process = "apsd" AND
                 message contains[cd] "iCloud.com.example.CloudKitCoreDataDemo"'
    system_logs.logarchive

log show --info --debug
    --start "2022-06-04 09:40:00"
    --end "2022-06-04 09:42:00"
    --predicate 'process = "apsd" AND 
                 message contains[cd] "iCloud.com.example.CloudKitCoreDataDemo"'
    system_logs.logarchive

25:17 - Provide a predicate to `log show`

log show --info --debug
    --start "2022-06-04 09:40:00" --end "2022-06-04 09:42:00"
    --predicate '(process = "CoreDataCloudKitDemo" AND
                      (sender = "CoreData" or sender = "CloudKit")) OR
                 (process = "cloudd" AND
                      message contains[cd] "iCloud.com.example.CloudKitCoreDataDemo") OR
                 (process = "apsd" AND message contains[cd] "CoreDataCloudKitDemo") OR 
                 (process = "dasd" AND
                     message contains[cd] "com.apple.coredata.cloudkit.activity" AND
                     message contains[cd] "CEF8F02F-81DC-48E6-B293-6FCD357EF80F")'
    system_logs.logarchive

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

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

リソース

関連ビデオ

WWDC22

WWDC21

WWDC20

WWDC19