Neues Spielzeug
Wir machen uns weiterhin mit neuem Material von Apple vertraut, das auf der WWDC vorgestellt wurde. Betrachten
Sie diesmal
MetricKit , ein völlig neues Framework, das als Tool zur Überwachung der Anwendungsleistung dient.
Jeder weiß, dass das Messen der Anwendungsleistung während der Entwicklung einfach ist. Xcode zeigt die Menge des verwendeten Arbeitsspeichers und die Prozessorlast an. Sie können mithilfe von Instrumenten eine Verbindung zu einem zu testenden Simulator oder Gerät herstellen und sogar Ihre eigenen Tools schreiben (weitere Informationen finden Sie in unseren Artikeln zu benutzerdefinierten Toolpaketen:
Teil 1 /
Teil 2 ). Wenn Sie nur die Bedeutung der Leistungsoptimierung verstehen, können Sie nicht fast alles messen, was die Anwendung tut. Wenn wir über den AppStore sprechen, wird es jedoch komplizierter, wenn die entwickelte Anwendung für echte Benutzer gedacht ist. Unabhängig davon, wie sorgfältig Sie Ihre Anwendung testen, gibt es unter realen Bedingungen immer eine Reihe von Überraschungen, die sich auf die Leistung und das Benutzererlebnis auswirken. Natürlich gibt es viele Tools zum Sammeln verschiedener Parameter, aber die meisten davon sind durch das
iOS SDK sowie die Auswirkungen der tatsächlichen Überwachung auf das Anwendungsverhalten begrenzt.
In diesem Jahr hat Apple beschlossen, diese Lücke zu schließen, und Entwicklern ein Tool zur Verfügung gestellt, mit dem sie Anwendungsleistungsmetriken in einer realen Umgebung erfassen und analysieren können. Sie kündigten
MetricKit (ein Framework, das Zugriff auf die vom Betriebssystem
bereitgestellten Optionen bietet) einer separaten Registerkarte im Xcode 11-Organizer an, auf der Sie Anwendungseinstellungen finden. Wir werden in MetricKit pausieren, da die Anzeige von Parametern in Xcode nur mit Anwendungen funktioniert, die bereits im AppStore veröffentlicht wurden.
MXMetricManager
Die Architektur des Frameworks ist recht einfach und unkompliziert. Der zentrale Teil wird von der
MXMetricManager- Klasse belegt, einer Einzelelementstruktur, die dem Entwickler eine große
Anzahl von Framework-APIs zur Verfügung stellt.
Im Allgemeinen besteht der Workflow aus drei Hauptschritten:
- Sie initialisieren MXMetricMnager und weisen ihm einen Beobachter zu.
- Wenn Sie möchten, können Sie mithilfe der Signpost-API Ihre eigenen Metriken in Ihrer Anwendung implementieren
- Und schließlich beschäftigen wir uns jetzt mit den empfangenen Daten in der didReceivePayloads-Methode, d. H. Senden Sie sie zur weiteren Analyse an Ihr Backend.
Parameter werden als Array von Instanzen von
MXMetricPayload geliefert . Die Nutzdaten kapseln Metadatensätze und Zeitstempel. Metric Payload ist ein einfacher Wrapper für die Unterklasse von
MXMetric . Für jeden Parametertyp ist er separat.
Die Arten von Metriken sind von Apple ziemlich gut dokumentiert. Lassen Sie uns also nicht zu lange darauf eingehen. Sie sollten jedoch aufhören, eine interessante Sache zu bemerken: MXMetric bietet eine offene API für die Serialisierung in NSDictionary oder JSON, was meiner Meinung nach etwas ungewöhnlich ist.
Interne Komponenten von MetricKit.
Draußen sieht MetricKit ziemlich einfach aus. Aber es ist immer interessant zu sehen, wie alles von innen nach außen funktioniert. Das Eintauchen in etwas Tieferes ist immer eine Intrige, wenn Sie vor einer bestimmten Aufgabe stehen. Daher habe ich beschlossen, Parameter mit MetricKit-Tags zu übergeben und sie dann dazu zu bringen, mir jederzeit aktualisierte Metriken zur Verfügung zu stellen. Natürlich können Sie in Xcode "
Debug -> MetricKit Payloads simulieren" verwenden , aber mit id können Sie Ihre eigenen Daten nicht anzeigen. Das ist zwar kein sehr nützliches Team, aber es gibt dir die Richtung in deiner Forschung vor und es sieht sehr lustig aus;)
Um die Aufgabe zu starten, benötigen wir natürlich MetricKit selbst. Sie könnten denken, dass das Abrufen einer Binärdatei für das Framework einfach ist, da Xcode sie in der Liste der Frameworks anzeigt, sobald Sie sie über das Dialogfeld "Binärdatei mit Bibliotheken verknüpfen" hinzufügen. Dies ist ein sehr optimistischer Gedanke. Denn wenn Sie
MetricKit.framework öffnen, wird die Datei
MetricKit.tbd angezeigt . Seine Größe beträgt nur
4kb . Offensichtlich ist dies nicht das, wonach wir suchen.
Also, was ist hier wirklich los?
TBD steht für "textbasierter Dylib-Stub" und ist eine YAML-Datei mit einer Dylib-Beschreibung, die Zeichen exportiert, und einem Pfad zur Dylib-Binärdatei. Durch das Verknüpfen mit TBD-Dateien wird die Größe der Binärdatei verringert. Später zur Laufzeit wird die echte Dylib-Binärdatei unter dem in der TBD-Datei angegebenen Pfad vom Betriebssystem heruntergeladen. So sieht die Datei aus, wenn Sie sie in Xcode öffnen:
Wenn Sie den Pfad aus der TBD-Datei verwenden, können Sie die MetricKit-Binärdatei problemlos für weitere Untersuchungen abrufen. Es gibt jedoch eine noch einfachere Methode.
Unsere Anwendungsbinärdatei enthält den Pfad zu jeder dynamisch verknüpften Bibliothek im Abschnitt Mach-O-Header. Diese Informationen können mit dem Tool unter Verwendung des Flags -l leicht abgerufen werden.
Hier ist die Ausgabe für das von mir erstellte Testprojekt:
→ otool -l ./Metrics | grep -i metrickit name /System/Library/Frameworks/MetricKit.framework/MetricKit (offset 24)
Sie können den gleichen Pfad sehen, den wir zuvor in der tbd-Datei gesehen haben. Mit einer binären Framework-Datei können Sie sich die internen Elemente ansehen. Dafür benutze ich normalerweise das
Hopper Disassemble . Es ist ein einfach zu bedienendes, aber sehr leistungsfähiges Tool zum sorgfältigen Studium von Binärdateien.
Sobald die MetricKit-Binärdatei geöffnet wird, wechseln Sie zur Registerkarte "Proc." und erweitern Sie die Liste 'Tags'. Hier sehen Sie alle exportierten Zeichen. Wenn Sie eine davon auswählen (z. B. MXMetricManager), werden alle Methoden angezeigt. Nachdem Sie eine Methode ausgewählt haben, wird deren Inhalt auf der rechten Seite angezeigt:
Beim Anzeigen der MXMetricManager-Methodenliste [
https://gist.github.com/deszip/88a258ae21d33dc75d7cbac9569c6ec1 ] fällt die Methode _checkAndDeliverMetricReports sehr leicht auf. Dies scheint das zu sein, was aufgerufen werden muss, damit MetricKit den Abonnenten Updates liefert.
Leider führte ein Versuch, ihn anzurufen, nicht zu einem Anruf beim Teilnehmer, was wahrscheinlich bedeutet, dass diese Parameter nicht zugestellt werden. In Anbetracht der Implementierung der Methode stellen wir einige interessante Dinge fest: Sie listet den Inhalt des Verzeichnisses / Library / Caches / MetricKit / Reports auf.
Anschließend versucht er, die MXMetricPayload-Instanz für jedes Element auf der Festplatte zu entpacken. Und schließlich iteriert es über registrierte Abonnenten und ruft die didReceive-Methode mit einer Liste von Daten auf.
Das Problem ist wahrscheinlich, dass sich keine Daten in
/ Library / Caches / MetricKit / Reports befinden , aber wir wissen, dass wir einige archivierte Instanzen von MXMetricPayload benötigen. Erstellen wir sie also und legen sie auf der Festplatte ab, bevor
wir '
_checkAndDeliverMetricReports ' aufrufen. Auch hier ist geplant, eine Instanz von MXMetricPayload zu erstellen, dann einen beliebigen Typ von MXMetric zu erstellen und hinzuzufügen und die Dateninstanz dann auf der Festplatte zu archivieren.
Rufen Sie schließlich die Methode '
_checkAndDeliverMetricReports ' auf. Dies sollte dazu führen, dass Sie unseren Abonnenten mit stub als Argument aufrufen.
Wenn Sie sich die Apple-Dokumente zu Nutzdaten und Metriken ansehen, werden Sie möglicherweise feststellen, dass sie keine öffentlichen Initialisierer haben und die meisten Eigenschaften schreibgeschützt sind. Wie ist es also möglich, eine Klasse zu instanziieren?
Kehren Sie erneut zu Hopper zurück, um eine Liste der
MXMetricPayload- Methoden
anzuzeigen :
Hier sehen Sie die Initialisierer und Methoden zum Zuweisen von Parametern. Das Aufrufen privater Methoden ist mit der
NSInvocation- Klasse und der 'performSelector'-Methode aufgrund der Dynamik von Objective-C einfach.
Als Beispiel erstellen wir Metriken für die CPU und fügen sie der Nutzlast hinzu. Über diesen Link finden Sie das vollständige Codefragment: [
https://gist.github.com/deszip/a0cf877b07cc2877129e0aaef2fed1e4 ].
Und schließlich archivieren wir alles, was wir erstellt haben, und schreiben die Daten in das
Verzeichnis / Library / Caches / MetricKit / Reports .
Jetzt ist es Zeit, die Methode '
_checkAndDeliverMetricReports '
aufzurufen , die schließlich zu einem Anruf beim Abonnenten führen sollte. Dieses Mal übergeben wir die Daten mit gestoppelter Nutzlast als Argument als Argument.
Woher kommen die Metriken?
Das
Abrufen von Berichten ist über
MetricKit recht einfach zu implementieren, aber Sie
möchten wahrscheinlich erfahren, wie Berichte im Verzeichnis
app / Library angezeigt werden . So.
Beim Durchsuchen der MetricKit-Binärdatei fiel mir diese Methode auf: '_createXPCConnection'. Durch die Überprüfung der Implementierung wird die Situation verdeutlicht: Es wird eine NSXPCConnection for Service mit dem Namen
com.apple.metrickit.xpc und zwei Schnittstellen
MXXPCServer und
MXXPCClient für die Client- und Serverseite erstellt. Wenn Sie sich die Protokollbeschreibung ansehen:
Fazit
MetricKit ist ein einzigartiges und unverzichtbares Werkzeug, um die Leistung Ihrer Anwendung unter realen Produktionsbedingungen zu
gewährleisten .
Leider ist es derzeit nicht möglich, einen Blick auf die 'Metric'-Benutzeroberfläche in Xcode zu werfen, außer auf das, was während einer Demo in einer WWDC-Sitzung gezeigt wurde.
Es kann ein unschätzbares Werkzeug sein, um die Benutzererfahrung auf die nächste Stufe zu heben, indem Leistungsprobleme in Ihrem Code beseitigt werden.
Ein Nachteil, den ich jetzt in diesem Tool sehe, ist das Fehlen von Details für jeden Typ: Nur die Trennung ist die Version der Anwendung, und Sie können keine Metriken für eine bestimmte Gruppe von Geräten / Betriebssystemversionen / Regionen usw. sehen.
Natürlich besteht immer die Möglichkeit, Daten zur weiteren Verarbeitung zusammen mit wichtigen Informationen, die Sie benötigen, an sich selbst zu senden. Sie können es an Aufgaben in Ihrem Bug-Tracker und mehr anhängen. Bei
AppSpector arbeitet unser Team daran, die Funktionalität von Leistungsüberwachungstools mithilfe von Daten aus
MetricKit zu erweitern .
Bleiben Sie auf dem Laufenden!