優れたプロファイリング体験を開発する

(音楽)

(拍手) 最高のプロファイリング体験を 紹介するセッションです 私 ダニエルと キャスパーが― Custom Instruments packageの 作成についてお話しします デベロッパは 持続可能なモジュールや 再利用できるコードを作るため― 他者が設計した フレームワークを使ってきました 良質なAPIや ドキュメンテーションは― フレームワークのユーザ体験の向上に 欠かせませんが― 今日 考えてほしいのは Instruments packageの開発です Metalを例に理由を説明します API設計は中心的で 呼び出し先はコアコンセプト デバイス コマンドバッファなど 多様です APIは何が可能かを表現しますが― ドキュメンテーションや サンプルコードは― コンセプトをアプリケーションに どう組み込むかを表現します しかし物語は続きます 自身のフレームワークで コードを書いている最中に― 不具合が起きたらどうなるか Custom Instrumentsは 他者にデバッグや最適化の方法を教え APIを最大限に活用します InstrumentsでMetal System Traceを 使えば 何が可能か分かります 規定のコンセプトとAPI用に設計された ビジュアルツールの作成です Instruments packageは 内部で透明性を生成する方法で フレームワークはテストされ 分かりやすく サポートもされています Custom Instrumentsの作成に 時間をかければ コードが期待どおりに作動するという 自信や信頼が生まれます Toolsもまた― どのコールが高額かを知る コストモデルの開発に最適な方法です パフォーマンスに問題が生じた際は― バグがどこに生じているかも 特定してくれます しかし重要なのは― Instrumentsは自身の物語を伝える 機会だということです Instruments packageは 重要な指標を視覚化し― 問題の迅速な発見に役立ちます 今日は最高の手段を生成する方法を 考えます まずフレームワーク内での トレースポイントの開発 それらをスキーマで生成する方法 Instruments内部のモデリングや構造 最後はInstrumentsのUIや 視覚化について説明します 今日は“トレース”“モデリング” “視覚化”をヒントに― OSSignpostについて話をしましょう

OSSignpostは 2018年に導入された 低コストのトレース･プリミティブです そのSignpostsは“.events”と インターバルに分かれます それらはformat stringのような printf関数であらゆるデータを記憶します しかし ここでは全Signpostsが static stringで名付けられます

SwiftにおけるOSSignpostのAPIは １つだけで― 変数は“begin”“end” “event”の３つのみ Ｃ言語ではそれらのインターフェイスは ３つのマクロを通し公開されます OSSignpostは OSLog上に生成されるので― トレースは 提供されたlog handleに 左右されるということです log handleには トレース時に名前がつき― サブシステムやカテゴリを 特定できるようになります 各Signpostsに名前がつくことで― トレースポイントに 構造や階層があてがわれます

OSSignpost上にCustom Instrumentsが 組み込まれた理由は 第１に時間です “.events”でもインターバルでも Signpostsは― 暗黙のうちに 高精度のtimestampを記憶します

複数のことを同時に行う世界では オーバーラップの精度も求められますが OSSignpostでは それをSignpostIDで行います 直近のイベントを マッチングさせるため― 異なるスレッドやDispatchQueue上でも 前後関係を十分に記憶します

第２に OSSignpostは低コストです ロギングのメカニズムは 効果的に設定され― OSSignpostを有効にした際 最小量のデータまで記憶します フォーマットの文字列や Signpostsの名前は最適化され― 二進法のテキストセグメントとして 並んで出力されます OSSignpostの負荷は少ないので― プロダクション･コードのまま 放置しても構いません 最適化されたコードをデバッグする ツールの生成にも役立つわけです

InstrumentsがSignpostsを記憶すれば 指定フィールドへのアクセスも可能に フォーマットの文字列や 用意した引数を含めてです また 知らずに特定したフィールドにも アクセスできます timestampや 呼び出し中のスレッドも含まれ便利です バックトレースが可能な log handleなら― コールスタックも記憶され 参照が可能になります

コードのトレースでは― OSLogとOSSignpostは ３つのモードで作動します 各OSLog handleには 使用可能なSignpostsがありますが 依然 ローコストで リングバッファに記憶されます Instrumentsやクライアントが 急ぎでデータを求めれば―

コストが少しかさむ ストリーミングモードが作動します

今年 用意した２つの ダイナミック･カテゴリは― Instrumentsの記憶中にだけ 作動します ２番目のカテゴリのスタックトレースを 記憶するよう設定されており― オーバーヘッドは 多少 追加されています では実際のコストは どの程度でしょう

多くのファクターが 実世界のパフォーマンスに影響します デバイスやハードの種類 OSのバージョン システムへの負荷や 温度もそうです 正確な数値化は困難ですが 対数目盛りで その規模をお見せします コストを想像しやすくなるはずです リリースビルド時のSignpostsは １マイクロ秒以下に分解できますが― このオフ･バイ･デフォルトなカテゴリは ナノ秒の領域で動いています

Instrumentsが 数秒前の記憶を始めると― オン･バイ･カテゴリの動作と 一致するようになります 動的スタックのカテゴリを除けば コストは同じですが― 呼び出しスタックを記憶しているため マイクロ秒レベルでコストが上がります

これがストリーミング･モードになると コストは途端に マイクロ秒レベルで跳ね上がります

そのことを念頭に―

OSSignpostのオーバーヘッドを 抑える方法を考えましょう 時間単位でのコストは プロファイルにも反映されるでしょうか 対策は２つあります まずはInstrumentsを “数秒前モード”に切り替えること ストリーミングをやめれば オーバーヘッドは減らせます 記憶のためのテンプレートの設定も 簡単にできます

ダイナミック･トレースカテゴリを 使うなら― オーバーヘッドを 最小限に抑えられます Signpostsが オフ･バイ･デフォルトとなるためです これはCustom Instrumentsでしか 実現できないので― 内蔵されたOSSignpostツールが 混み合うことはありません

フレームワークやサブシステムの 設計者は― プロファイリング中にSignpostsを どの程度 放出できるか 控えめな目標を見てみましょう プロファイル中の シングルコアのCPUは１％以下です Signpostsのコストが それなりだとすると― 動作は0.5マイクロ秒単位なので― １秒あたりのSignpostsは ２万になる計算です １秒120フレームで駆動する iPad Proでさえ― １フレームあたり 83のインターバルが可能です

繰り返しになりますが― パフォーマンスは変わるため 数字はあくまで目安です Signpostsは 共有されたリソースであり― 使用するだけ ロギング･システムに影響します ハイレートでのトレースを可能にした こうした設定は― コードのパイプライン･インストールや 指令の問題点の発見に役立ちます オーディエンスごとに異なるカテゴリに Signpostsを分けたい場合もあります クライアントより コントリビューターのほうが― 詳細をトレースしたがる傾向があります そこで複数のlog handleに トレースポイントを分散させれば― ツールは必要なサブセットだけを 有効にできます

トレースはインストルメンテーションの ベースですが― ４つの事例を紹介します

まず大切なのが インターバルは停止しておくことです 正確性を期すためにも― インターバルは停止しないと Instrumentsの分析が鈍くなります ここではOSSignpostが― 高コストで エラーの出やすいコードを 呼び出しています 実際にエラーが起きると― end関数が 丸ごと飛ばされることがあります しかしSwiftはコマンドを延期させ― 初期にエラーが発生しても うまく対応し―

OSSignpostのend関数が 呼び出されるようになっています

第２に効率性があります begin/end関数のトレースポイントの 同一データのロギングを避け― 最初のポイントで記憶する そうして二重の動作を避け Instrumentsに任意の値を与えます 例えばここでは リクエストする値を反復せず― オーバーラップに備えた インターバルの値も用意していません これらのポイントは― 各インターバルのlog handleのため 独自のSignpostIDを生み出しています

第３にSignpostsが作動していない時は 不要な動作を避けます ダイナミック･トレースの作動で log handleを生み出すと― Instrumentsに関係なく Signpostsのプロパティが表れます この優れた方法により― OSSignpostの背後で 高コストのデータ計算が進められます

第４に ツールに実際に必要なのは トレースデータだけということ guard statementや preconditionは― 短いインターバルを含ませるため トレースしたい事柄の１つです 例えば あるメソッドがあり― キャッシュヒットと キャッシュミスの違いを知りたいとする しかし初期のリターンの結果は退屈です こうした場合はpreconditionの後に Signpostsを移し― Signpostシステムに送るデータ量を 減らします こうしたヒントから分かるように トレースポイントは 最上部に生成する ツールの 基礎になるもので― 多くはプロダクション･コードに 存在しています トレースポイントのパフォーマンスと 維持には気を配りましょう 核にあるものなので― Signpostsのコールを変更するなら ツールも変える必要があります

トレースポイントを安定させるには 細かなトレースを避け― APIレイヤーの近くで OSSignpostの 呼び出しをします コードベースの周辺に移すことは 問題にはなりません インライン展開のような コンパイラ最適化も気にしなくていい static stringを変えないようにだけ 気をつけましょう サブシステムやカテゴリ Signpostsの名前や format stringでは特にです 変えるならInstruments packageも アップデートしてください

次はモデリングや― Instruments内のデータに 構造を加えるという話です

Instrumentsのアーキテクチャは テーブルに記憶されています テーブルの構造を決定づける スキーマは― Instrumentsのアナリシス･コアが 測定しています Instrumentsのアーキテクチャを 知るため― 2018年のセッションを 思い出してみてください モデリングとプロファイリングの 関連性を見ましょう 左側のOSSignpostは― Instrumentsがメインで記憶する データソースです Custom Instrumentsで使われる 定義されたスキーマです

次の段階がモデリングです modelerは別テーブルのデータを 観察･推論し― １以上のアウトプット･テーブルに データを放出します modelerは ドメインロジックが属する場所です そしてアウトプット･テーブルの スキーマは― formatterなど どれが 任意のデータに適応するかを指定します

最後の段階が視覚化です これはInstrumentsのスタンダードUIに XMLで表現されます ここでmodelerが データをグラフ化する方法を特定します データをどの列に配置し 値を使用するか― どれを色付けするかといったことです Custom Instrumentsの視覚化は― あなた自身のスキーマや modelerが基準となります OSSignpostのトレースポイントが 良好かを確認し― スキーマにデータを配置する方法は 確認が必要です

Custom Instruments内のデータの 取り込み方法は― ２通りあるうちの１つです ポイントのスキーマには timestampの列があり― インターバルのスキーマには 継続時間の列もあります ポインタ インターバル スキーマを 少なくとも１つ定義し― 残りの列の 名前とタイプを指定しましょう

入力データはモデリングの ルールどおりに配置されます このルールはEclipseの言語で 記述されています Instrumentsは modelerを自動生成する スキーマを生成してくれるので― Eclipseのコードを 都度 書き込む手間が省けます 例えばデータが正しいかを 確かめたいとします Instrumentsはライブラリに ビルトインOSSignpostツールを提供し OSSignpostのインターバルが 適切かを記憶･確認します そうするとインスペクタが 原データの状態を検証してくれます データの確認後は― Instrumentsの新ターゲットが ツールの生成には最適です Xcodeの ビルトインXMLスニペットがあれば― automatic modelerや ライブラリ内の Instrumentsまであと一歩です その様子をお見せしましょう キャスパーをご紹介します (拍手) どうも こんにちは

MacのSolar System アプリケーションは― 画像や映像 バイナリデータなど 惑星に関する膨大なデータを扱います 私はこのアプリケーション専用の フレームワークを生成し― データのエンコード等がしやすいよう ライブラリを圧縮しました ではフレームワーク用に インストルメンテーションを生成し 将来のユーザへのヒントを お見せします ２つのコンセプトを紹介しましょう CompressionManagerは 圧縮に関わるオブジェクトです 複数のチャネルで構成され 同時に実行できる タスク数を指定できます 次に 特定のファイルや アルゴリズムの圧縮がいかに効果的かを 圧縮比を見ながら検証しましょう データを圧縮すべきか 判断できるようになります OSSignpost APIに インターバルを書き込んだので― CompressionManager Swiftファイルを 見てみましょう

まずはlog handleです フレームワークのBundle IDが サブシステムとして― クラス名がカテゴリとして指定されます

圧縮と解凍は パブリック･インターフェイスです どちらもまずは 圧縮用のアイテムを作りますが― そこには圧縮タスクの情報が 埋め込まれています 次にプライベートの SubmitWorkItemMethodを呼び出します

圧縮チャネルがビジー状態だと― アイテムの作成から実行まで 時間がかかる場合があるからです 遅延の状態を測るには ここが一番というわけです CompressionItemWaitから Signpostsを呼び出します このguardコンディションは― ソースファイルがあることを 次へ移る前に確認してくれます ダニエルが言うように 関数の最上部へ移し― インターバルの停止を確認します

ExecuteWorkItemMethodは― チャネル上で圧縮の準備ができた時に 呼び出されます まずは待機状態のアイテムを― endのSignpostsを呼び出し 停止させます

CompressionExecution Signpostで 圧縮を始めます メタデータには アルゴリズムや オペレーションの種類― ソースやデスティネーション チャネルなどの情報が含まれます OSSignpostは暗黙のうちに パラメータを記憶するので― スレッドは取り除いても大丈夫です

次にデスティネーション･ ファイルを作成 同時に 圧縮オペレーションを 実行させ― デスティネーション･ファイルサイズに 帰属させます ここでもSignpostsの呼び出しを 改善できます StartCompressionMethodには エラーがあります エラーが起きれば Signpostsを呼び出せません それを回避するには 別のブロックを持ち出し―

インターバルが停止してるかを見るため コードを移動させます

Xcodeのプロファイルを使い Instruments内のSignpostsを見ます

空のテンプレートに―

Signposts Instrumentsを追加

数秒ほど 記憶させます

完了しました Signposts Instrumentsを展開し 記憶されたサブシステムを確認

Solar Compressionがありました CompressionManagerカテゴリを 見てみましょう “Ctrl＋Z”でグラフに合うよう このトラックをリサイズできます

拡大してデータを見てみます

最上部にはCompressionExecutionの Signpostsが 下には 待機中のタスクのためのインターバルが こちら側には別の表示があります 最大２つのタスクが 同時に実行されているので― アプリケーションコードは 圧縮チャネルを２つ使っているはずです こうしたスパイクは― 圧縮待ちのタスクがあることを 意味します

OSSignpostではSignpostsを 分析できますが― フレームワーク内のオーディエンスでは 十分なコンテキストを提供できません そこでCustom Instrumentsを用いた Solar Compression Instrumentです この２つのSignpostsを 別のテーブルに入れ― InstrumentsのスタンダードUIを適応し ビジュアルを改善しました このInstrumentsを含む トレース･ドキュメントを開きます

下にある待機中のタスクは― OSSignpost Instrumentsに 類似させています

チャネルによって分けられた インターバルが最上部にあります 使用できるチャネルは２つですね

下にあるものは すべて圧縮タスクです インターバルやファイルのサイズ 圧縮率などの項目もあります 長くて赤い こちらのタスクが気になりますが― これは圧縮が遅いという意味です

タスクの内容を知りたければ “active tasks detail”を選択 インスペクションの先端にある インターバルが出てきました 先端を移動させ 分析を始めます

zipアーカイブを圧縮中ですが― ファイルのサイズの縮小率は １％強です それでは圧縮の意味がありません

次は“task summary detail”を選択 全タスクを集計します 圧縮の種類 拡張子 アルゴリズムの ３段階で集計されます 右側には別の統計データがあります 平均圧縮率や所要時間 トータルの保存サイズなどです これにより 異なるアルゴリズムを比較したり― ファイルの種類による 圧縮率の違いを検証できます 例えば こちらのJPEGファイルは 平均34％の縮小率ですが― 圧縮済みだったファイルにしては よい値です

Instrumentsのインスペクタでも 見てみましょう

こちらがOSSignpostのテーブルです イベントの一部始終を見ています 他にもテーブルが２つあります

これは実行テーブル これらはすべて 記録されたデータですが― エンジニアリングのタイプに従い フォーマットされています

こちらのテーブルは UIが直接 消費したものです

このInstrumentsには満足ですが― 待機中のタスクの見せ方は 変えたいところです 特定のインターバルではなく― 負荷が大きい箇所を 目立たせるにはどうするか ダニエルに考えがありそうです ダニエル

(拍手) ありがとう ライブラリのOSSignpost Instrumentsを 見てもらいました インスペクタが 原データをどう視覚化するか― Instrumentsが データをどう分析するかも紹介しました キャスパーはEclipse modelerに 書き込みをしなくても― フレームワークの圧縮概念を用い データを表示させていました トレースポイントは４つ インターバルスキーマは２つだけでした しかし理想のプロファイリング体験とは 違うと言います カスタムmodelerは そうした体験の テーラリングには向いています 複数のlog handleのために データを結合し― ビルトインテーブルのデータを 活用することもできます 複雑なロジックを組み込み 状態を維持し― イベントの命令の推測もできます 独自のカスタムmodelerを 書き込めば― グラフを作成したり 詳細なスキーマも作れます ポイントやインターバルのスキーマ modelerのタグなどは― 分かりやすいテーマですが 今回は割愛します カスタムmodelerに関しては― 2019年の別のセッションで サンプルコードについても触れています プロファイリング体験のUIについて 話を続けましょう “視覚化”について 制作者として 視覚化の技術を活用し― 自身のコードを使うデベロッパに 物語を伝える そのために覚えておく原則が― データと物語は 同じではないということです 先ほどのOSSignpostのグラフも そうでしたが― インターバルの原データは 制作者にしか理解しづらいものです あなたのツールを使うユーザは タイムラインの問題や― フェーズの順序がどうであるか 知りません Instruments packageを 開発するなら― 何が起きたかを知らせ 自ら診断できるようにしてください 解説しなくても 問題が伝わるようにするのです

視覚化とは グラフの作成だけではありません 問題を伝えるには 一連の統計データや― 説明文があったほうが いい場合もあります

しかし 新規ユーザにとって 取っつきやすいグラフは― いわば物語の１ページ目です 問題点を他者に理解させるには 視覚化が有効です 選別が速いというのも いいツールの条件ですが― 問題点を明確にするのが 視覚化の目標です グラフなら 重要なポイントが ひと目で分かります そこから問題を掘り下げる時― 詳細な視点やメトリクスが コードから伝わるべきなのです Instrumentsではポイントと インターバルを扱いますが― 双方を同時に表示させる方法を 説明します

“.event”を要約する際は 何が重要かを評価します 値が似通っている場合― 柱状グラフを使うと 密集具合が伝わります 背の高いバーは目立つので まず そこに着目します Custom Instrumentsでは グラフを簡単にカスタマイズできます 柱状グラフは 時間の配列を指定しやすく― 画面を縮小しても 見やすいという利点があります 個々のイベントのプロットを 拡大する際も同様です

各イベントの重要性が異なる場合― 不可欠なイベントに レーンを設けるのも効果的です

同じテーブルのデータを基とする 複数のグラフでは― どのプロットを選ぶかを Instrumentsに書き込み 指定できます これらはカスタムmodelerを使わず XMLだけで表示しています

ポイントもしくはインターバルの サマリー表では― どのメトリクスが重要かを特定できます 詳細なデータが一覧になり― “Min”“Max”などの項目別に 値がまとまっています 新規ユーザはこうした集計を基に― 何が重要で 何を最適化すべきかを判断します そのため配列の名称などの視覚情報も 重要になってきます

詳細を知りたい時は― ナラティブ型の処理方法も 役に立ちます 実行時のビヘイビアを 自然言語や 他のformatterで説明できるからです この方法により 何ができなかったかが明確になり― 調査すべきハプニングも 把握できるようになります

インターバルデータのプロットは 少々 複雑です インターバルはオーバーラップするため １つの縦軸には収まりません オーバーラップしたインターバルを 固定できるなら― レーンを分散し 縦方向に表示させる方法が２つあります クオリファイド･プロットは 単独タイトル内に複数のレーンを分散 インスタンス･プロットは レーンにタイトルを付ける際に便利です OSSignpostのツールでは 双方の技術を用いますが― オーバーラップするインターバルが 少なく表示されたほうが 効果が出ます オーバーラップが多い場合は― Instruments 11の新たな階層が 使えるかもしれません トレースデータを 入れ子状のトラックに分散させれば― グラフの規模が大きいほど 必要な情報を得やすくなります しかし より大切なのは インターバルデータの要約方法です それは どんな階層や グラフにも言えることです

シンプルなインターバルデータなら 柱状グラフを使いたくなりますが― これはインターバルが短い場合にしか うまく表示できません インターバルが長い場合は 柱が左方向に集中し値が大きくなります 所要時間を含むデータを グラフ化する際は― Ｙ軸に時間の設定を入れないでください パーセンテージのような値のほうが 向いています

オーバーラップするインターバルは 多いものです ３つのサマリー表を例に挙げましょう コンセプトを 理想どおりに フレームワーク内に表示し― 印象深い提示スタイルを 確立する方法になります

リソースの使用率が高いと オーバーラップは増えるものです そうしたデータの表示には クオンタイズ設定を使いましょう 特定の値に色付けもできます Eclipse modelerやInstrumentsは データの維持や結合に役立ちます OSSignpostのイベントストリームと 内部のタイマータグを組み合わせると クオンタイズされた平均値を 一定時に発信することも可能になります modelerのアウトプットテーブルは ４列程度のグラフになります ここには プロットの値を示す利用率の列や― 色を決定づける重要な列があります

一方 多くの短いインターバルが 重要になることもあります フレームワークの使い方が 非効率的だからです 先ほどの例を見てみましょう 特定のインターバルを数えるmodelerを ベースにしたグラフのほうが― ある時点では 見やすいかもしれません modelerのアウトプットテーブルは 似ているものの― ユーザの目を引くのは 別のタイムラインにある項目です ここでは短いインターバルに 注意が向きます

最初の２例のデータは 10ミリ秒の集合体に要約されます しかしオーバーラップ自体が 重視され― 同時に実行される複数のインターバルを 調べたい場合もあります その際は 時間を基準にするのではなく― オーバーラップの程度を グラフ化したほうが分かりやすいです

OSSignpostのイベントのみを追う modelerは― カスタムインターバルスキーマにより テーブルを追加できます ここではデュレーションや 説明的な列が表示されます

以上 ３つの例を挙げました これらがデータの提示の際に 役立てば幸いですが― やはりグラフのデザインは コンセプト次第です 多くの場合 自動生成されるmodelerは― 適切な体験を創出する 力と柔軟性を与えてくれます しかし毎度 行う入出力は １回とは限りません これまでお見せしたテーブル例も そうです カスタムmodelerは そうした力や柔軟性を生み出し― コンセプトのビジュアルも文章も 分かりやすく表示します もう一度 キャスパーに 実演してもらいましょう (拍手) どうもありがとう カスタムmodelerをいじる中で― インストルメンテーションの改良に 成功しました ご覧ください 制作したSolar Conversionの テンプレートを使います

ここでは ファイルシステム動作Instrumentsが 圧縮ライブラリを使用する際 入出力の情報を追加してくれます まずは記憶です

ウィンドウモードにし オーバーヘッドの負担を減らします

Instrumentsが ホスト上のデータを転送し― modelerを作動させています

データを見てみましょう ファイルシステム動作と Signpostsの相互関係が見て取れます 先ほど見た zipの長い圧縮タスクですが― 目立つように赤く色付けされました 文章での説明もあれば さらに分かりやすくなります 圧縮率が低いシチュエーションを 検出し― 解決策を探ります

このmodelerの出力を見直すため 提案内容を見てみましょう

提案は１つだけですね “アーカイブ用のzipファイルサイズが １％以上減少” “圧縮は 不要かもしれません”とあります 速さでは劣りますが 圧縮率を上げるため LZMAアルゴリズムを使ってみます 使えそうです アルゴリズムを変えて記憶し 再計算します

待機中のタスクはどうでしょう 負荷の平均値を計算すれば― どこに負荷がかかっているかを はっきり特定できます 赤色の部分を見てみましょう 平均的な値のタスクは 多そうですが― こちらのチャネルへ行くと 値が下がってきます エリアごとの分析もできますし― チャネル数を増やし 並行性のレベルを上げることも可能です

得られた結果は別の提案の生成にも 役立ちます

Instrumentsのインスペクタを 見ましょう Solar Compressionの 出力テーブルを探し― 解決策を見てみます

OSSignpostのポイントスキーマの データが modelerによって転送され― Solar Compressionの出力テーブルに 表示されました UIがここで消費していたものです 提示したmodelerである 新たなエンティティも表示されています これは 圧縮テーブルにあった インターバルを― ポイントスキーマ上の提案に変換します これが後ほど 文章化されます

Instrumentsが ライブラリのコンセプトを説明し― ユーザに 見せられる状態になりました スライドに戻りましょう

(拍手) 優れたプロファイリング体験は ユーザを探索の世界へ導きます 使いやすいテンプレートは― 問題を見つけやすいよう 設定されています インストルメンテーションに影響され 脆弱になるコードもあります 原因はサンプリング システムトレース 先行するアクティビティなどです その点はテンプレートに反映しましょう 記憶を分析する際は― ユーザの目を引くグラフを作成すること 問題が出力タイムラインに 潜んでいたとしても― 解決策のヒントは 細部から得られることも多いです

良質なプロファイリング体験の 創出のため― Instrumentsの新たな特徴を ２つご紹介しました １つは階層的なトラック その一例が OSSignpost Instrumentsです 階層には 基礎となるサブシステムと カテゴリ名が表示されています

Custom Instrumentsの一部である階層は ご自身のInstrumentsで作成できます

ワークフローのカスタマイズ方法も 新しくなりました トレースドキュメント内のデータを 別の側面から分析するには― 追跡フィルタを適応させるか 異なるブランチを選択しましょう コールや圧縮ライブラリの Signpostsに関心がある場合 アプリケーションのメモリの影響を 分析したい場合は― 他の追跡を除去するスコープを 作成しましょう それをテンプレートに保存すれば 情報を共有できるようになります

インストルメンテーションの形をとった ツールは あなたを― より良い領域や 未知の領域へ導いてくれます フレームワークの 中にある物語を伝え― 情報を与え 簡単なミスを知らせてくれます デバッグの問題で困っていたら ツールに答えを求めましょう そうした相互関係が ライブラリの信頼度を上げてくれます

Custom Instrumentsの詳細は “Instruments Developer Help”まで 他のセッションもご覧ください ありがとうございました (拍手)