画面を遅くせずに、画面を読む

画面履歴のコストは、あなたが別のことをしようとしている間に、バックグラウンドで、毎回、いつまでも払われ続けます。だから、ほぼゼロに丸められるものでなければなりません。ScreenCaptureKitでフレームをキャプチャし、Visionでテキストを読み取り、暗号化し、書き込み、インデックスを作る。それにかかるのは、およそ0.3秒、1コアのおよそ1%です。

いちばん安い処理は、やらない処理

その予算の大半は、実際には使われません。ほとんどの間隔は変化のチェックで終わるからです。これは直前のフレームとの比較で、コストはほぼゼロ。ここに残す価値のあるものはない、と判断します。このチェックのしくみは、別のノートで書いています。

同じテキストは二度読まない

文字認識はコストの高い処理です。フレームが直前のものとほとんど同じで、言葉が変わりようがないとき、LockTimeはVisionをもう一度実行せず、前のテキストを引き継ぎます。画面の読み取りには約70ミリ秒かかります。すでに読んだものの再利用なら約1ミリ秒です。

インターフェイスはライブラリを待たない

20,000枚のスクリーンショットのライブラリから1日分を一覧にするのにかかるのは、約1ミリ秒です。1秒に1回記録した丸1日分、つまり86,400個の場面の帯をレイアウトするのには5.4ミリ秒。16ミリ秒の1フレームに余裕で収まります。ライブラリが1週間分でも1年分でも、ウインドウはディスプレイのフレームレートを保ちます。

どちらのマシンにも、ひとつのビルド

LockTimeは隅々までSwiftとSwiftUIで書かれ、AppleシリコンとIntelの両方に対応するユニバーサルビルドとして出荷されています。この制約には落とし穴があります。オプションの意味での検索は埋め込みを16ビット浮動小数点数で保存しますが、Swiftでそれを書くいちばん素直な方法はFloat16で、これはarm64にしか存在しません。そう書くと、アプリはAppleシリコンのMacではコンパイルもテストも通るのに、Intel向けにはまったくビルドできなくなります。そこでストアはvImageを通してIEEE binary16を書き込み、そのバイト配置をテストで固定して、変わらないようにしています。

どれも目には見えません。それこそが狙いです。動いていることに気づかないくらいでなければならないのですから。