OSLog の優位点

メモリ上の循環バッファにバイナリでログを保持しておき、何らかの障害が発生した時点で初めて外部に出力するので、観測者効果が最小限で、余計な I/O が発生せずログが容量を逼迫することがない。

Activity Tracking により、そのログがどういうコンテキストで出力されたのかを視覚的に表示することができる。

その他、機微情報の取り扱いなどが変わっているらしい。小容量な SSD がメインストレージで、紛失によるセキュリティリスクの高い、モバイル端末時代を考えたロガーとして設計されている感じがある。

OSLog の欠点

ログが単純なテキストファイルではないので、これを横断的に検索する手段が存在しない。閲覧に際しても、基本的には Sierra 以降のコンソール.app を使う必要がある。

肝心の Activity Tracking が長らく Swift に対応していない。

ログ収集時に文字列組み立てによる負荷を発生させないために、Obj-C ライクな書式文字列が存在して、それを覚える必要がある（その書式文字列の一覧がどこにあるのかは分からない…）。

OSLog の使い方でいまいち分かりにくかったところ

Xcode の Console に出る情報が少なすぎて使いにくい

コンソール.app を使うのがほぼ前提なところがある。

OSLog.default って使っていいの？

subsystem と category の情報をログに含める必要がないなら別に使っても問題ないらしい。

subsystem と category って何？

ログを識別するために設定できる任意の文字列。

subsystem は慣例的に Reverse domain name notation で実行しているアプリの識別子などを渡す。
category はその中でログメッセージを分類するのに使用する。

ビデオの中では、メッセージ本体とタイムスタンプに別の category を設定するという使い方が紹介されていた。

ログレベル良くわからない

ログレベル	意味
Default	循環バッファにログを出力し、メモリが溢れたとき圧縮して外部に保存する。追跡に使うデータは基本これ。
Info	循環バッファにログを出力する。エラーが発生しない限り、外部に書き出されず捨てられる。
Debug	設定を変えない限り、メモリには取り込まれない。開発用。
Error	常に外部に書き出される。プロセスレベルのエラーを報告するためのもの。
Fault	常に外部に書き出される。システムレベルおよびマルチプロセスのエラーを報告するためのもの。

とりあえず残しておいて損はない情報は Info にざくざく詰んでおくと、障害発生時にだけ書き出してくれる。

Error / Fault の違いは、Activity Tracking の振る舞いに起因しているっぽい？あんまり分かってない。

ラッパークラスやラッパー関数を作ってもいいの？

ラップするとどこでエラーが発生したのかという情報が失われるのでダメらしい。（参考にしたビデオの Transcript より）

Avoid wrapping os log APIs in other functions. If you wrap it in another function you then lose our ability to collect the file and line number for you.

これについて信憑性を調査しようと思ったものの、OSLog の実体のマクロを展開してもよくわからず。