カスタムInstrumentsの作成

(音楽)

(拍手) おはようございます チャド･ウルフです Appleのエンジニアです このセッションでは― カスタムinstrumentの 話をします

作りたくなる理由も 少し触れましょう 盛りだくさんの内容を 入門 中級 上級の― ３つに分けてお届けします ベストプラクティスを 本日 最後に紹介します

では まず作りたい理由です Instrumentsには 有益なツールがあります アプリケーションとの互換性を 確認するSystem Trace Metal System Traceと組み合わせた ビデオゲームのテンプレートは― アプリ上の機械的な画像の不具合や フレームの消失などを解消しました

Network Connections Instrumentを お持ちであれば アプリ間の TCP/IPの交信ができます そして おなじみの Time Profilerです アプリ内の 時間がかかる処理を調べ 原因がネットワーク階層なのか ゲームエンジンなのかなど探ります 当たり前のことですが― コードが分かれば とても有益です IPアドレスやコールスタックの 仕組みを理解することで Time Profilerを 簡単にすることができます ではコードに不慣れだと どうなるでしょう？ アプリの ネットワークレイヤの― 処理時間があまりにも かかっていたら どう解決します？ カスタムinstrumentの 出番です アプリケーションやレイヤの 状況について― コード初心者が分かるように 示せるのです

Expert System技術の 有用性について― 上級編で話します これによって 自動で悪いパターンを探し― アンチパターンを検出する instrumentを作れます

ではアーキテクチャを 見てみましょう そのために―

振り返ってみます Instrumentsは 当時も今も― 単なるドキュメントの ライブラリです レコードを押すと ツールが実行されます 以前との主な違いは Instrumentsはその組織構造上 コードを書く速度を 上げられなかったのです 当時は問題ありませんでした アセットやパフォーマンスツールを 引き継いでいたからです 独自のレコード技術や 論理解析がありました トレースからデータを得るために カスタムstorage mechanismを作り アプリケーションに組み込むのに カスタムUIを作る必要がありました Instrumentsと 該当モデルの― 維持費が急上昇しました その理由は毎回 各７個のカスタムUIと カスタムstorage mechanismの 作成が必要で それを変更する 新たな機能を加えたかったのです 従来型のモデルを持続し メンテナンスにかかるコスト負担を 皆さんに続けてほしくありません 新しい機能より コスト問題の解決を― 優先したのです 新しいInstrumentsは― カスタムUIなどの代わりに ２つの標準化要素を使います Standard UIと Analysis Coreです Standard UIは 現代のInstrumentsのUIで― Analysis Coreと 組み合わせます Analysis Coreは データベースと― エキスパートシステムの 中間です そしてInstrumentsの 重要な基盤となります 現代の構造でInstrumentを 作ると― Standard UIとAnalysis Coreの custom configurationが必要です こちらの画面をご覧ください System Traceと― ゲームテンプレート ネットワークコネクション テンプレートと― Time Profilerの画面です 全ドキュメントの Instrumentは― Standard UIとAnalysis Coreで ビルドされました 同様に皆さんも作れます Xcode 10とInstruments 10で 同じツールを提供しています Xcodeと皆さんの Instrumentsの違いは― 作成者だけです

ライブラリにInstrumentsが 表示されます トップは アクティビティモニタです ドラッグ＆ドロップで レコードを残します Analysis Coreに データを入れると― Standard UIがグラフと Table Viewを表示します トップにグラフがあり ２通りで表示されています １つ以上のグラフで 定義できます 定義するグラフを 選ぶ方法は― Instrumentsアイコンの この部分を使います CPUからネットワークに 変更できます

どのグラフにも 一定のレーンがあります CPUの使用率で ３つレーンを定義しました

レーンはAnalysis Coreの テーブルに結びつきます 同テーブル内の別カラムの 場合もあります

Instrumentsの下部は― Detail Viewと呼ばれる 重要な部分です event-by-event listや― データのアグリゲーションや サマリも見られます

グラフと同じように― Instrumentsの項目数を 定義できます ジャンプバーで 項目を選び― 自分で定義づけるタイトルの 詳細を選択します グラフのレーンと同じく― 全項目がAnalysis Coreの テーブルに結び付いています データを受け取って レコードします 特別なコードは 必要ありません

Analysis Coreは すべて テーブルで表示されます テーブルとは― ローの集合体で 構造は定義されています データベースに似ています スキーマはカラムや その名前を定義します 新しいAnalysis Coreは engineering typeという システムを使っています 標準UIの中でも データの保存 視覚化 解析の方法が分かります

テーブルの構造を スキーマが説明し― コンテンツの説明に 属性を使用できます 何がテーブルに入るか 分かります Objective-CかSwiftでは スキーマはクラスで ローはインスタンスです スキーマの名称は固有です Objective-Cの クラスの名前や― Stringの代わりの NSStringと同じです 上級編で 重要な点ですが― 先に触れます スキーマの例として tickがあります Instrumentsの スキーマの１つです 統計計算で使用する― 総合的なClock Tickの テーブルを維持していました カラムは１つで Sample Timeを使う― シンプルな構造です さらにテーブルの特徴である― 周波数に属する可能性のある 視覚属性を定義づけます 10属性でtickスキーマに テーブルを作るとしましょう １秒10タイムスタンプで データ入力が必要だと― プロバイダは分かります こうしてテーブルに書き込んだ データと情報伝達ができるのです 入門編の情報は これで十分でしょう XcodeでのInstrumentsの 作り方をお示しします また tickを Detail Viewで示す― Instrumentの作り方も お伝えします では同僚のキャスパーが― 実演します (拍手) ありがとうございます カスタムinstrumentを作り 実行する方法を説明します tickスキーマを使って― 一定の頻度で Instrumentを作ります パッケージを説明したり― Instrumentsで テストする方法を学びます 始めましょう

Xcodeと同じように― 新しいパッケージを作ります New Xcode Projectに飛び― Instrumentsパッケージを 選びます

Instrumentsパッケージの デフォルト名を入力します “Ticks”とします

“Next”をクリック “Create”をクリック

Xcodeが package definitionと package targetを持つ― プロジェクトを作成しました

中を見てみます

パッケージは XMLのシンタックスです ID タイトル オーナーが 含まれています パッケージをインストールすると これらのフィールドが見られます

スキーマとモデラを 定義して―

開始します 先に定めたtickスキーマを 使うのでガイドを消します

ベースパッケージからスキーマの 要素とfirst nameを特定して―

インポートします

Instrumentsの 準備が整いました

複雑な要素を 簡単に定義するため― Xcodeで スニペットを利用します 要素名を 例えばInstrumentと書き込み― リターンを押します

Instrumentに ユニークIDと―

後でInstrumentsライブラリに 出現するプロパティをいくつか入力

10ミリ秒ごとに―

tickを書き込む Instrumentです

このInstrumentがライブラリから trace documentにドロップした時 テーブルが作成されます テーブルIDは Instrumentの 定義内で固有でなければなりません “tick-table”とします

schema-refの中に― すでにtickにインポートされている スキーマのリファレンスが必要です

Track Viewと Detail Viewでの― 表示を定義します グラフ要素を使います

グラフの中のタイトルを “Ticks”とします

レーンのタイトルです

事前に作成した テーブルとして― tickテーブルの リファレンスが必要です

これでグラフの プロッティングを特定します プロット要素を使います 基本的に― カラムのmnemonicを パスする必要があります グラフ化します

タイムスタンプが 見られるようにするため― リスト要素を使います

レーン要素と同じく table refで表示される―

リストのタイトルを パスします

見たいカラムも同じです

Instrumentsを 実行する準備ができました Xcodeスキーマを使います やってみます

ビルドエラーが出ました IDサポートが 表示されています エラーはここです カラムのタイムスタンプが ないという内容です “time”にしないと いけません 修正して―

実行します

確認できるのは― Instrumentsの コピーだからです アイコンが違うので 分かります 一時的にパッケージを 取り込みます もっと簡単に繰り返せます

取り込みを確認するには― New Package Management UIで 分かります “Instruments”の “Preferences”から― 確認できます

新しく作成された パッケージを見られます 一時的に取り込まれています

システムパッケージも あります ここに表示される リンクを使えます

Ticksパッケージは Ticks Instrumentを含みます テストしましょう

空のテンプレートです ターゲットを MacBookにします

ライブラリで Instrumentを探します

“Ticks”と入力

package definitionから入力された 全プロパティが表示されます

ドラッグ＆ドロップし―

すぐにレコードします

下位ペインを見ると10ミリ秒ごとに データが生成され増えています

detailとグラフは 調整し合っています ローをクリックすると inspection headが移動します グラフをズームインします Optionを押してクリックし ドラッグします

tickが刻まれています

パッケージの作り方でした ではチャドが Standard UIの話をします (拍手) ありがとう 初めての プロジェクトとして― 基本のInstrumentの 作り方を説明しました 次はグラフと 詳細について― また実際のデータでの対応を 説明します グラフレーンからです キャスパーは プロット要素を使って― グラフとレーンを 定義しました プロット要素は― Standard UIへの 指示方法です テーブルの 全コンテンツを― レーンに割り当てるよう 指示します グラフの作り方やその扱いを プロット要素が決めるには カラムとスキーマの両方を 確認することです インターバルスキーマは 継続時間があり― ポイントスキーマは タイムスタンプと同じです カラムがマグニチュードを ターゲットとした時は― このように 棒グラフを作れます もう１つは ライフサイクルレーンで― インターバルスキーマですが stateのカラムを選択します stateはマグニチュードがないので 棒グラフは作成しません Standard UIは インターバルを 関連づけることができ― state style treatmentを 自動的に選びます そして丸長方形型に分類されるので 平らな棒グラフとは異なります Standard UIは こうした調整が可能です それでInstruments UIを 安定させます 私たちが 状態図を定義する場合― Standard UIは 同じ処理を行います それがInstrumentsのユーザの 利便性を高めています

グラフや多くのレーンを 作りたいなら― プロットテンプレートを 定義できます テーブルでカラムを選べる 要素を除いて― プロットに類似しています そしてカラムで値ごとに ローを分けて作ります

スパイクまたはアクティビティの 停止区間を限定して見たい場合は ヒストグラムがあります 100ミリ秒ほどタイムラインを 休ませることができます COUNT SUM または 最大値 最小値で― バケットのマグニチュードを 増やすことができます 一番よい方法は― アクティビティのスパイクを System Traceで探すことです

UIの下半分にある Detailsの話をします “List”の画面です UI内のテーブルと Analysis CoreとTable Viewの― シンプルなマッピングです “アグリゲーション”です タイムコンポーネントを 減じたり― テーブルの中の統計を 取りたいですよね アグリゲーションを 定義する時― カラムは関数です SUM 平均値 COUNTなど 異種の統計計算機能を使い― 望みどおりの アグリゲーションviewを― 作ることができます

アグリゲーションの利点は 階層を定義することです ここで 仮想メモリ階層の中に プロセススレッドを定義しました プロセスや その中の 各スレッドによって― 分析された全体を 見ることができます 該当するプロセス内でです アグリゲーションは 大量の データの概要を見るのに最適です

Call Treeは 新しいアグリゲーションです Call Treeは backtraceカラムがあれば有用です Time Profiler同様 weighted backtrace または― weighted Call Tree viewを 作ることができます

ナラティブと呼ばれる 形式があります 専門用語に関する情報を 伝える時に― ナラティブが有益です 例えば エキスパートシステムの 出力などが narrative engineering typeに 円滑に伝達されます

最後はtime sliceです これはListに似ています 青色の線で 二分した区間を含めて― コンテンツを絞り込む点が 違います 青いライン つまり inspection headを動かし リストのコンテンツが 比較されます

Analysis Coreのテーブルに ３つのUIが関連づけられます レコードを押すと― Instrumentsにデータが入り Analysis Coreが埋まります プロセスがどう働くか 説明します

レコードを押す前に― Analysis Coreが テーブルを取ります マッピングして ストレージを割り当てます テーブルがまったく同じスキーマで 属性を持てば― 定義上 同じデータなので 同じストアでマップされます

次に 各ストアに データ用プロバイダを探します ターゲットのデータストリームから 直接レコードすることも可能ですし モデラを使って データを統合できます モデラは独自の入力を 要求することができます これらは他のモデラの 出力にもなり 直接レコードする方法が分からない 残りのデータを統合し データストリームより 直接レコード可能です Analysis Coreの中にストアされた すべてのデータソースを得られます このbinding solutionですが binding solutionを可視化します Instrumentsがbinding solutionを見られるようにします thread narrativeと呼びます

binding solutionは― トレース全体に渡ります ドラッグ＆ドロップで Instrumentをトレースします Instrumentsは 最大限にレコード 演算し― ターゲットへの影響を 最小限に抑えます

テーブルや テーブルインスタンスを作る時 Instrumentsは スキーマを必要とします すでに100スキーマを 超えています Package Management UIの中に 含まれる全スキーマが使えます 自分のパッケージに インポート可能です スキーマが基本パッケージに 含まれていない場合― Xcodeの設定で 関連づけが必要です 他のパッケージを 探せるように設定します

スキーマはすべて 他の パッケージ内でも定義されるので レコードを押すと テーブルが スキーマと共に情報入力されます モデラが定義するか データストリームから レコードする方法が分かれば 自身のモデラに書き込む 優れた出力を作るよりも 優れたビルディングブロックを 作ることができます これでモデラエレメントと― Instruments Packageの中に 書くか定義することができます モデラに カスタム出力スキーマを― 作ることができます 点にはポイントスキーマを 点と区間の複合の場合は インターバルスキーマを使えます

モデラは どの入力が必要か定義でき― 残りのデータフロー･グラフを 埋めることができますが― これをデータバインディング ソリューションと呼びます

モデラはCLIPS言語で書かれた 小型のエキスパートシステムです つまりパワフルで 進化しているのです モデラの作り方の詳細は上級編で 後ほど扱います 独自のスキーマを 定義できることと― Instrumentsに入れるデータを得る 最適な方法 新しいos signpost APIを 持つことが最重要でした ショートカットも 作っています

パッケージ内に os-signpost- interval-schemaという― スキーマを定義できます スキーマを定義し　モデラを代理で 作成する方法を説明してくれます os signpost callsのメタデータに 自分でレコードしたデータを 内部から 取り込むことができます そして取り込んだ メタデータを使い― スキーマのカラムの埋め方を 定義できます シンプルな例です JSONのデコードを 例にしましょう デコードの始まりと終わりを マークするsignpostがあります 最初はメタデータを 取り込み― 解析するJSONオブジェクトの 容量を示します これで Instruments Package definitionに os-signpost-interval-schemaを 作れます スキーマの名前も定義します レコードしたいsignpostと その名前を選びます これでシンタックスを使って メタデータメッセージの最初から 各メタデータを取り込みます さらに取り込んだ値を 使って― 定義したカラムのデータ容量を 入力する方法を教えてくれます

セッション405ではロギングを使い 計測法を紹介していましたね その時 Trailblazerの 実演を行い― signpostを基に書き込める Instrumentをお見せしました カスタムinstrumentへの 書き込みについてでした ではキャスパーに― パッケージの作り方を 実演してもらいます (拍手) ありがとう チャド

TrailblazerはiOSの アプリケーションで― 身近なハイキングコースを 紹介するものです UITableViewを使用します 各セルで画像を取り込みます 欠陥を防ぎ 最適化するため― セルの再利用時は ダウンロードを中止します 流れを可視化するため― データを os signpost callに まとめます ご覧ください

セルの表示中に 画像が取り込まれます OSログハンドルやダウンローダ オブジェクトから取得する― downloader signpost IDを 作ると UITableViewの セルのアドレスを入手します

signpost ネットワークから― OSログより始まる os signpostを呼び出します このログが カテゴリー別に サブシステムと ネットワークの アプリケーションIDを取ります

背景画像の名前と関連せず― 画像名が含まれたsignpost IDと メッセージ形式が作られました

stringやcallerは セルのアドレスなので― public specifierに まとめます

２通りで ダウンロードできました ご覧ください

このように完了すると デリゲート方が最適です 先にsignpost IDを作って os signpost endを呼び出します 今回はステータスとサイズを パスします

ステータスの値が 完了しています サイズは画像に 合わせます

次にoverwriteの準備を ご覧ください

実行中のダウンローダを キャンセルします signpost IDを作り 呼び出します 同じフォーマットですが 値はキャンセルです ダウンロードに失敗したので サイズはゼロです

os signpostインターバル スキーマを見てみます どのようにパッケージを 取り込むのでしょうか

signpostインターバルスキーマを ユニークID タイトルと共に定義 そしてサブシステムと カテゴリを定義します OSのlogハンドルを作った際 パスしたものです

os signpostの呼び出しや startとendでパスした― 名前要素とスタート･エンド パターンを作ります 両方が os signpostのbeginとendの セルを通過したものと一致してます

メッセージ要素は 書式のstringと同じです format argumentの 代わりに― os signpostを呼びこむ時 値を 取り込むために変数をパスします

カラムに値を入力する方法を 説明します

ここにステータスのカラムが あります 完了か中止なので stringです ステータス変数を入力します

式要素は Clipsの式を取るので― もっと高度なこともできます 容量によりイベントインパクトを 演算することができます 3.5MBを超えるとイベント インパクトは高いです オペレーションインパクトは 逆に低いです

os signpostインターバル スキーマの定義でした 次にテーブル作成です

os signpostインターバル スキーマのIDをパスし― テーブルに ユニークIDを作ります そしてUI definitionで 参照します

グラフ用にレーンを作ります テーブルを取得し プロット テンプレートでグラフにします プロットテンプレートは グラフ作成に最適です エレメントによって パスされたカラムを― 認識するのです そしてカラムの値に 固有のプロットを作ります

Label formatエレメントで プロットタイトルを作れます これがimgカラムと 画像名からの値です

プロットの値として 画像名をパスします 各図形は カラムの インパクトに応じて色がつけらます 各図形のラベルは 画像の容量に関連します

次はlistです

tickの紹介で お見せしました

見たいカラムを すべてパスします

次はアグリゲーションです 完了したダウンロードを すべて追跡します テーブルには完了及び中止した ダウンロードも含まれるので― データにフィルタをかける sliceエレメントが必要です sliceエレメントで カラムを特定し― 合う値を断定します テーブルから 完了したローを拾います 階層を定義します 画像名と 可視化された カラムがある― １つのレベルの階層です 画像名ごとに 数や容量を特定します

そして画像の容量を 合計します

次にtime sliceです 可視化されたカラムを 特定します

Instrumentを もっと簡単に使うため― カスタムテンプレートを 特定できます

ではパッケージを実行します

テンプレートが 表示されましたね

iPhoneとTrailblazerを 対象にします

レコードします

TrackViewのデータが 増えたと分かります

プロットは画像名ごとに 作成されます

package definitionで パスした書式と照合します ダウンロードが 3.5MBを超えたら― 図形は赤色になります 容量も表示されます

では詳細を見てみましょう

リストがあります ダウンロードした すべてのデータです

アグリゲーションを選びます

画像名で 区分されています ダウンロードした 12の画像がトップにあります

７番目の画像は ２回ダウンロードされました

次はActive requestsです

inspection headを つかむと―

ディテールビューの データの数値が変化します 多数のActive requestを 追跡でき― inspection headの 持続時間を確認できます

異なった方法でのデータ Storeやモデラを確認したい場合 Instrument Inspectorで 次のようにしましょう カスタムinstrumentの デバッグ方法です これはStoreの手順です os signpostのStoreが 作成されています ネットワークカテゴリと― com apple trailblazer subsystemを認識してます ローの値は24ですね 作成したテーブル画像では ローは12です

全コンテンツが 底部に表示されます

次はモデラです 自動生成するos log モデラを確認できます 24から12のローを 出力します

binding solutionが 右に表示されます 生成した os logモデラは― os signpostテーブルから データを移します その後 Instrumentで 使われます

os signpostの呼び出しと UIの作成― Instrument Inspectorで 使われたデータを見てきました ではチャドから 上級モデリングの紹介です (拍手)

ありがとう

os signpostと カスタムinstrumentを― 結び付ける方法を お見せしました この２つの組み合わせを― 引き離すことができます 少し上級のトピックを お話しします モデラを作成し 定義する方法です 入力を行う シンプルなマシンです 入力を論証し 出力を生みます 入力は常に 完全な時間順です 異なる要求をしても― 最初のオーダーとなり 時間順に並びます ワーキングメモリを 供給します 処理の１つ１つが ワーキングメモリに入ります ワーキングメモリの展開から モデラは推測します 出力を生みだす パターンを見て― 出力テーブルに 書き込みます

モデラの楽しい使い方を ご紹介しましょう “マッチ遊び”の スキーマを定義します os signpostインターバル スキーマです 危険な処理を行うことを 定義したos signpostが― 対象です “アプリケーション炎上”の スキーマも定義します これもsignpost スキーマですが― 状態が悪いことを意味します 出力スキーマを作ります “マッチ遊び”オブジェクトと 炎上時間を記録します 炎上開始スキーマを 呼び出します

モデラは このような感じです すべての入力を 時間順にすると― 左の点線を モデラクロックと呼びます メモリに最初の入力を 入れると モデラのクロックが インターバルの最初の地点に移動し 次の入力をつかむと― またクロックが最初に戻り ワーキングメモリに入れます モデラは 両方とも認識します “マッチ遊び”は アプリケーションの前に すでに炎上しています アプリケーションが先に炎上し 順番が逆でも結果に大差ありません “炎上の原因”という ロジカルな結論を― ワーキングメモリに 盛り込めます

第３の入力をつかむと クロックの動きが― ２つの入力とは 交わらないと気づきます その２つはワーキングメモリから 削除されます “炎上の原因”に logical supportがあれば― これも削除されます

クロックの設定は入力時の タイムスタンプです ワーキングメモリの中に 入力を残すために― モデラの現在のクロックは 交差します こうして一致させ 古いデータを取り除きます そして入力が時間と 互換性があるかも分かります

モデラがワーキングメモリを 論証する方法は― production systemで 定義します Production systemは ワーキング メモリ内のファクトに基づき作動し オペレータの左辺と 右辺で定義されます 左辺はルールを アクティブにするパターンで― 右辺はルールが集中した時に 起こるアクションです 出力テーブルに ローを加えます また モデリングプロセスの 進歩として― 新たなファクトを 含めたりします

ファクトのソースは２つです １つは テーブル入力です 先に説明したモデリングクロックの ルールをファクトとして使用し― 自動的に組み込みます さらに 右辺プロダクションから 自動組み込みによって作られます

自分のファクトを 作るなら― Clipsにファクトの構成を提供する ファクトテンプレートがあります Clipsでルールを見てみます まず“原因”を見つけます 解読します t1が“誰がマッチで遊ぶか” というオブジェクトで― “アプリケーション炎上”が t2 t1がt2の前に 起きたとします すると“炎上の原因” という― 新たなファクトを 右辺に主張できます ワーキングメモリに入ります 第２のルールは― “原因のレコード”です “アプリケーション炎上”が あって原因が分かれば― アペンド側を関連づける テーブルがあります モデラの出力側です 定義する“炎上開始”スキーマに テーブルが該当すれば― テーブルにローを作れます そして炎上を起こした人と 時間を値に設定します

さらに最初のエキスパート システムを作って― ２つのルールに沿って 悪いパターンを調べます

モデラかレコーダに ルールが付加されています これらは modules in Clipsといい 両グループのルールに従いつつ― 実行順を制御したりします 出力を維持した場合は― レコーダモジュールの中の テーブル出力が 新たに生成される出力を ルールするので その場合 検証の途中で― 出力を書こうとは しないはず モデラのルールの実行が レコーダより先だからです

logical supportの期間に ついて説明します logical supportとは― 推論規則に関連します “AとBならCだ”のような ルールです logical supportを 加えたとします AとBがワーキングメモリに 存在しない場合― Cは自動的に削除されます つまりAとBがCを論理的に 裏付けています ワーキングメモリの膨張を 制限することと ワーキングメモリから無効な ファクトを削除することが重要です AもBも無効なら Cも削除されます logical supportを 加えるために― keyword logicalと一緒に パターンをまとめ ルールの右辺に 示すものは― 進行していくと 自動的に取り消されます そして この２つのファクトは― スキーマにちなんだ名前です モデラのクロックが 動いたら― インプットは取り消されます

モデラの作り方の基本を 知ったうえで― Clips言語とルールを 見てきました 悪いパターンや誤用を 階層で見つけるため― エキスパートシステムを ネットワークInstrumentsに 追加できるか見てみます キャスパーから 最後の実演です (拍手)

アンチパターンを 検出するため― 既存のログで書き込みます Trailblazerを使用中― 速くスクロールすると欠陥が 現れるように思えますが 画像は何度も入れ替わり― 取り消しが機能していない 可能性もあります 検証のため モデラに書き込みます package definitionを 見てみましょう モデラエレメントを書いて 始めます モデラは ID タイトル 目的を持ちます ドキュメンテーションに この３つの領域が引用されます モデラの 全ロジックを含む― 生成システムの パスを特定します

ここで　モデラに 出力を定義します それは ダウンローダ ナラティブスキーマです 要求される入力は os signpostテーブルです このテーブルは beginとendを含みます ダウンローダスキーマの 定義を見ましょう

２つのカラムとタイムスタンプを 定義づけるポイントスキーマです タイムスタンプは診断メッセージの ログの時間を追跡し

何が誤作動したか説明します

そこで テーブルに Instrument定義を制作します

ダウンローダスキーマと ユニークIDをパスします

ここで ナラティブ エレメント定義を使います

はい ナラティブが 定義できました すでに作成した テーブルrefをパスし タイムカラムと ナラティブカラムを定義します

これでモデラのロジックを 定義できます

モデラ定義で 参照したファイルを作ります Clipsファイルを作るには “File”から“New”を選び―

macOSのプラットフォームを 選択します

“Clips file”をクリック

名前を入力し―

作成します

１つ以上のリクエストが 同時に同一セルで 実行されてるか 検出するアルゴリズムは 次のとおりです ワーキングメモリの要求を すべて追跡します 最初にファクトの テンプレートを作ります

時間やセルのアドレスに― 取り込んだsignpost ID 要求した画像名など― ファクトに保管されています ここでは“ダウンロード開始”の ファクトと呼びます

次にモデラのルールを 書き込みます

これはos signpostを 認識します サブシステム 名前 イベントタイプを特定し 欲しい情報すべてを特定し 取り込みます 画像名 callerアドレス 時間 signpost IDを取り込みます

ここで 新たなファクトを ワーキングメモリに明示します

ダウンロード後 クリーンにするため― ワーキングメモリから このファクトを消す必要があります

同じテーブルですが― endのイベントのみ 見ています signpost IDを取り込みます signpostのbeginとendは 同じIDだというファクトを ここで使っています signpost IDを持つ ファクトを― ワーキングメモリで探します そして消します

ナラティブデータを 生成する― レコーダルールを 書き込みます

レコーダルールはスタンダード ダウンロードファクト全部を認識し それを取り込みます 時間 callerアドレス 画像名を取り込みました 同じcallerアドレスを持つ 別の標準ダウンロードがある場合 変数は同じで最初の ファクトの前に発生したと

気づくことができます アンチパターンや 重複リクエストがあります ダウンローダナラティブスキーマに アクセスできるか確認し―

新しいローを作ります

最初のファクトの時間に 時刻カラムを設定し― ナラティブ記述を設定します 後でデバッグできるよう 問題に関する情報を出力します

ではInstrumentを実行します

これで実行です

Trailblazerネットワークを テンプレートから選び―

レコードします

下まで速く スクロールして― ナラティブテーブルを見ます

多くのメッセージが 出力されています 問題を確認して 調べることができます ナラティブは インタラクティブの詳細です パスしたargumentを確認して フィルタをかけられます このcallerアドレスを 詳細として加えて― 詳細フィルタができます

ではInstruments開発の― ベストプラクティスを チャドが紹介します (拍手) ありがとう キャスパー Instrumentの中の エキスパートシステムについて― 基本の作り方を見てきました 途中でも触れた ベストプラクティスの話です まずInstrumentを １つ以上書くこと 練習を積むのでは ありません すでにInstrumentを持っていても それに新しい機能を追加したい場合 単純にそれを追加したり 余計なグラフや詳細を足すでしょう でも それでいいか 考えてください きめ細かい Instrumentなら― ユーザに選択肢を多く 提供できます 欲しいInstrumentを ライブラリにドラッグできてー ターゲットに対する 記録影響が最小限です 多機能の１つのInstrumentは 全能か無能かのどちらかです もし Instrumentに― 複数のInstrumentの 同じ問題に対して ターゲットを絞ったものを 組み合わせて作りたいなら 全機能のものを 同時に使うよりは 問題ごとにカスタムテンプレートを 作るほうがよいでしょう ドキュメントを作り Instrumentをドラッグして設定し テンプレートとして 保存します キャスパーがネットワーク テンプレートに追加した要素は― パッケージ内で使用できます １つ以上のInstrumentを書くのは ツールを使う際 よりよい方法です

２つ目の方法は大変です immediate modeは レコード形式で― ほぼリアルタイムで データを可視化します 大変な理由は２つあります まずは追加でサポートが 必要なこと 時間が足りず 当日中に対応できません 今 取り組んでいます そして重要な ２つ目の理由は― インターバルデータです Analysis Coreでは beginとendを見れば― インターバルデータは それが 閉じるまではテーブルに入りません でも実演していると多くの インターバルができます モデラが 実行可能な 出力として要求すれば upstreamにインターバルが あると― インターバルが閉じるまで 全モデラクロックの ダウンストリームを 停止する必要があります モデラは時間順だからです インターバルのアップストリームが 閉じるまでクロックは動かせません 長い区間でインターバルが できていたら― 出力は止まります ユーザが レコード停止を押せば― インターバルは閉じ 元どおりにデータが入ります でも好ましくありません ディベロッパには ２つの選択肢があります Instrumentに 制限の要素を追加し― immediate modeで サポートを選ぶこと もう１つは先ほどエキスパート システムで実演したのと同じように モデラから出力として インターバルデータを離す方法 私たちは実際 インターバルよりも os signpost pointの イベントを使います 簡単に見えますが― immediateモードは 実装する時に注意が必要です

３つ目の重要な点は― 大量の入力データを ターゲットしたInstrumentを作る時 プリレコードタイムが ５秒モードのものが効率的です traceドキュメントに― レコード形式の オプションを切り替える方法は immediateと deferredと last end secondsモードです なぜ効率的なのか レコーディング技術が バッファリングを使用し― パフォーマンスを改善するので データをInstrumentsから リアルタイムで消費しないからです signpostデータには 大きな効果があり― 最新の５秒のデータしか 見られませんが ５秒モードでは 10倍もの速度で処理可能です Instrumentが生成する大量の データの処理にはもってこいです System Traceや Metal System Trace そしてゲームパフォーマンス テンプレートでは一般的ですが このようなアプリケーションを ターゲットとする場合― immediate modeは 選びません ユーザやInstrumentsに 問題はなく― データ取得やインターバルの 問題でもありません

終了の時間です 多くのワークを経て― 皆さんと分かち合えたことが 最高の喜びです 皆さんの製品を見るのが 待ち遠しいです 私たちと直接 話したい方は― ３時に８番ラボへ お越しください os signpost APIの使い方は 405セッションで紹介します 楽しんでください (拍手)