Lire un écran sans le ralentir
Capturer, lire, chiffrer, indexer — environ un tiers de seconde, environ un pour cent d'un cœur. Trois décisions qui ont mené là.
Le coût d'un historique d'écran se paie à chaque intervalle, indéfiniment, en arrière-plan, pendant que vous essayez de faire autre chose. Il doit donc s'arrondir à rien. Capturer une image avec ScreenCaptureKit, en lire le texte avec Vision, la chiffrer, l'écrire et l'indexer prend environ un tiers de seconde et environ un pour cent d'un seul cœur.
Le travail le moins cher est celui qu'on évite
L'essentiel de ce budget n'est jamais dépensé, parce que la plupart des intervalles s'arrêtent à la vérification de changement — une comparaison avec l'image précédente qui ne coûte presque rien et conclut qu'il n'y a rien à garder ici. Comment fonctionne cette vérification fait l'objet d'une note à part.
Le même texte n'est pas lu deux fois
La reconnaissance de texte est l'étape coûteuse. Quand une image est assez proche de la précédente pour que ses mots n'aient pas pu changer, LockTime reporte le texte précédent au lieu de relancer Vision. Lire un écran prend environ 70 ms. Réutiliser ce qui a déjà été lu en prend environ 1.
L'interface n'attend pas la bibliothèque
Lister une journée dans une bibliothèque de 20 000 captures prend environ 1 milliseconde. Disposer la bande de moments d'une journée entière enregistrée à la seconde — 86 400 moments — prend 5,4 ms, confortablement à l'intérieur d'une image de 16 ms. La fenêtre tient la fréquence de l'écran que la bibliothèque contienne une semaine ou une année.
Une seule version pour les deux machines
LockTime est du Swift et du SwiftUI de bout en bout, livré en une version universelle pour Apple Silicon et Intel. Cette contrainte a des dents. La recherche par le sens, optionnelle, stocke ses embeddings en flottants 16 bits, et la façon évidente de les écrire en Swift s'appelle Float16 — qui n'existe que sur arm64. Écrite ainsi, l'app compile et passe ses tests sur un Mac Apple Silicon, et ne peut pas être construite pour Intel du tout. Le stockage écrit de l'IEEE binary16 via vImage à la place, et un test fige la disposition des octets pour que cela le reste.
Rien de tout cela ne se voit, et c'est le but. Vous ne devriez pas pouvoir dire que ça tourne.