iOS-Leistungstricks, damit sich Ihre App leistungsfähiger anfühlt

Obwohl moderne iOS-Hardware leistungsfähig genug ist, um viele intensive und komplexe Aufgaben zu bewältigen, reagiert das Gerät möglicherweise immer noch nicht, wenn Sie nicht auf die Leistung Ihrer App achten. In diesem Artikel werden wir uns fünf Optimierungstricks ansehen, mit denen sich Ihre App reaktionsschneller anfühlt.

1. Wiederverwendbare Zelle aus der Warteschlange nehmen

Sie haben wahrscheinlich schon tableView.dequeueReusableCell(withIdentifier:for:) innerhalb tableView(_:cellForRowAt:) . Haben Sie sich jemals gefragt, warum Sie dieser umständlichen API folgen müssen, anstatt einfach ein Array von Zellen zu übergeben? Lassen Sie uns die Begründung dafür durchgehen.

Angenommen, Sie haben eine Tabellenansicht mit tausend Zeilen. Ohne wiederverwendbare Zellen müssten wir für jede Zeile eine neue Zelle erstellen, etwa so:

 func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Create a new cell whenever cellForRowAt is called. let cell = UITableViewCell() cell.textLabel?.text = "Cell \(indexPath.row)" return cell }

Wie Sie vielleicht gedacht haben, werden dem Speicher des Geräts tausend Zellen hinzugefügt, wenn Sie nach unten scrollen. Stellen Sie sich vor, was passieren würde, wenn jede Zelle eine UIImageView und viel Text enthalten würde: Das gleichzeitige Laden könnte dazu führen, dass der App der Speicher ausgeht! Abgesehen davon würde jede einzelne Zelle beim Scrollen neuen Speicher benötigen, der allokiert werden müsste. Wenn Sie schnell durch eine Tabellenansicht scrollen, werden schnell viele kleine Speicherblöcke zugewiesen, und dieser Vorgang macht die Benutzeroberfläche ruckelig!

Um dieses Problem zu lösen, hat uns Apple die Methode dequeueReusableCell(withIdentifier:for:) zur Verfügung gestellt. Die Wiederverwendung von Zellen funktioniert, indem die Zelle, die nicht mehr auf dem Bildschirm sichtbar ist, in eine Warteschlange gestellt wird, und wenn eine neue Zelle auf dem Bildschirm sichtbar wird (z. B. die nächste Zelle darunter, wenn der Benutzer nach unten scrollt), wird die Tabellenansicht angezeigt Rufen Sie eine Zelle aus dieser Warteschlange ab und ändern Sie sie in der Methode cellForRowAt indexPath:

Durch die Verwendung einer Warteschlange zum Speichern von Zellen muss die Tabellenansicht nicht tausend Zellen erstellen. Stattdessen benötigt es gerade genug Zellen, um den Bereich der Tabellenansicht abzudecken.

Durch die Verwendung von dequeueReusableCell können wir den von der App verwendeten Speicher reduzieren und sie weniger anfällig für Speichermangel machen!

2. Verwenden eines Startbildschirms, der wie der Startbildschirm aussieht

Wie in den Human Interface Guidelines (HIG) von Apple erwähnt, können Startbildschirme verwendet werden, um die Wahrnehmung der Reaktionsfähigkeit einer App zu verbessern:

„Es soll lediglich den Eindruck vermitteln, dass Ihre App schnell gestartet und sofort einsatzbereit ist. Jede App muss einen Startbildschirm bereitstellen.“

Es ist ein häufiger Fehler, einen Startbildschirm als Begrüßungsbildschirm zu verwenden, um Branding anzuzeigen oder eine Ladeanimation hinzuzufügen. Gestalten Sie den Startbildschirm so, dass er identisch mit dem ersten Bildschirm Ihrer App ist, wie von Apple erwähnt:

„Entwerfen Sie einen Startbildschirm, der fast identisch mit dem ersten Bildschirm Ihrer App ist. Wenn Sie Elemente einfügen, die nach dem Start der App anders aussehen, kann es zu einem unangenehmen Aufblitzen zwischen dem Startbildschirm und dem ersten Bildschirm der App kommen.

„Der Startbildschirm ist keine Branding-Möglichkeit. Entwerfen Sie kein Einstiegserlebnis, das wie ein Begrüßungsbildschirm oder ein „Über“-Fenster aussieht. Fügen Sie keine Logos oder andere Branding-Elemente ein, es sei denn, sie sind ein statischer Teil des ersten Bildschirms Ihrer App.“

Die Verwendung eines Startbildschirms zum Laden oder für Branding-Zwecke könnte die Zeit der ersten Verwendung verlangsamen und dem Benutzer das Gefühl geben, dass die App träge ist.

Wenn Sie ein neues iOS-Projekt starten, wird ein leeres LaunchScreen.storyboard erstellt. Dieser Bildschirm wird dem Benutzer angezeigt, während die App die Ansichtscontroller und das Layout lädt.

Damit sich Ihre App schneller anfühlt, können Sie den Startbildschirm so gestalten, dass er dem ersten Bildschirm (View-Controller) ähnelt, der dem Benutzer angezeigt wird.

Der Startbildschirm der Safari-App ähnelt beispielsweise der ersten Ansicht:

Das Startbildschirm-Storyboard ist wie jede andere Storyboard-Datei, außer dass Sie nur die standardmäßigen UIKit-Klassen wie UIViewController, UITabBarController und UINavigationController verwenden können. Wenn Sie versuchen, andere benutzerdefinierte Unterklassen (z. B. UserViewController) zu verwenden, benachrichtigt Xcode Sie, dass die Verwendung benutzerdefinierter Klassennamen verboten ist.

Beachten Sie außerdem, dass UIActivityIndicatorView nicht animiert wird, wenn es auf dem Startbildschirm platziert wird, da iOS ein statisches Bild aus dem Storyboard des Startbildschirms generiert und es dem Benutzer anzeigt. (Dies wird kurz in der WWDC 2014-Präsentation „Platforms State of the Union“ um 01:21:56 .)

Apples HIG rät uns auch, keinen Text in unseren Startbildschirm aufzunehmen, da der Startbildschirm statisch ist und Sie Text nicht lokalisieren können, um ihn an verschiedene Sprachen anzupassen.

Empfohlene Lektüre : Mobile App mit Gesichtserkennungsfunktion: Wie man es real macht

3. Zustandswiederherstellung für Ansichtscontroller

Zustandserhaltung und -wiederherstellung ermöglichen es dem Benutzer, zu genau demselben UI-Zustand zurückzukehren, den er unmittelbar vor dem Verlassen der App hatte. Manchmal muss das Betriebssystem Ihre App aufgrund von unzureichendem Arbeitsspeicher möglicherweise aus dem Speicher entfernen, während sich die App im Hintergrund befindet, und die App verliert möglicherweise den Überblick über ihren letzten UI-Status, wenn er nicht beibehalten wird, was möglicherweise dazu führt, dass Benutzer ihre Arbeit verlieren in Bearbeitung!

Auf dem Multitasking-Bildschirm sehen wir eine Liste von Apps, die in den Hintergrund gestellt wurden. Wir könnten davon ausgehen, dass diese Apps immer noch im Hintergrund laufen; In Wirklichkeit könnten einige dieser Apps aufgrund der Speicheranforderungen vom System beendet und neu gestartet werden. Die App-Snapshots, die wir in der Multitasking-Ansicht sehen, sind tatsächlich Screenshots, die vom System direkt beim Verlassen der App aufgenommen wurden (dh um zum Start- oder Multitasking-Bildschirm zu wechseln).

iOS verwendet diese Screenshots, um die Illusion zu erwecken, dass die App noch läuft oder immer noch diese bestimmte Ansicht anzeigt, während die App möglicherweise bereits beendet oder im Hintergrund neu gestartet wurde, während immer noch derselbe Screenshot angezeigt wird.

Haben Sie schon einmal die Erfahrung gemacht, dass die App beim Fortsetzen einer App vom Multitasking-Bildschirm eine andere Benutzeroberfläche anzeigt als die Momentaufnahme, die in der Multitasking-Ansicht angezeigt wird? Dies liegt daran, dass die App den Zustandswiederherstellungsmechanismus nicht implementiert hat und die angezeigten Daten verloren gingen, als die App im Hintergrund beendet wurde. Dies kann zu einer schlechten Erfahrung führen, da der Benutzer erwartet, dass sich Ihre App in demselben Zustand befindet, in dem sie sie verlassen hat.

Aus Apples Artikel:

„Sie erwarten, dass Ihre App in demselben Zustand ist, in dem sie sie verlassen haben. Zustandserhaltung und -wiederherstellung stellen sicher, dass Ihre App beim nächsten Start in ihren vorherigen Zustand zurückkehrt.“

UIKit leistet eine Menge Arbeit, um die Zustandserhaltung und -wiederherstellung für uns zu vereinfachen: Es übernimmt das Speichern und Laden des Zustands einer App automatisch zu geeigneten Zeiten. Alles, was wir tun müssen, ist eine Konfiguration hinzuzufügen, um der App mitzuteilen, dass sie die Zustandserhaltung und -wiederherstellung unterstützen soll, und um der App mitzuteilen, welche Daten aufbewahrt werden müssen.

Um das Speichern und Wiederherstellen des Zustands zu ermöglichen, können wir diese beiden Methoden in AppDelegate.swift :

 func application(_ application: UIApplication, shouldSaveApplicationState coder: NSCoder) -> Bool { return true }

 func application(_ application: UIApplication, shouldRestoreApplicationState coder: NSCoder) -> Bool { return true }

Dadurch wird die App angewiesen, den Status der Anwendung automatisch zu speichern und wiederherzustellen.

Als Nächstes teilen wir der App mit, welche Ansichtscontroller beibehalten werden müssen. Dazu geben wir im Storyboard die „Restoration ID“ an:

Sie können auch „Storyboard-ID verwenden“ aktivieren, um die Storyboard-ID als Wiederherstellungs-ID zu verwenden.

Um die Wiederherstellungs-ID im Code festzulegen, können wir die Eigenschaft " restorationIdentifier " des View-Controllers verwenden.

 // ViewController.swift self.restorationIdentifier = "MainVC"

Während der Statuserhaltung wird der Status jedes Ansichtscontrollers oder jeder Ansicht, der eine Wiederherstellungskennung zugewiesen wurde, auf der Festplatte gespeichert.

Wiederherstellungskennungen können zusammen gruppiert werden, um einen Wiederherstellungspfad zu bilden. Die Bezeichner werden unter Verwendung der Ansichtshierarchie gruppiert, vom Root-Ansichtscontroller bis zum aktuell aktiven Ansichtscontroller. Angenommen, ein MyViewController ist in einen Navigationscontroller eingebettet, der wiederum in einen anderen Registerkartenleisten-Controller eingebettet ist. Angenommen, sie verwenden ihre eigenen Klassennamen als Wiederherstellungskennungen, sieht der Wiederherstellungspfad folgendermaßen aus:

 TabBarController/NavigationController/MyViewController

Wenn der Benutzer die App verlässt, wobei MyViewController der aktive Ansichtscontroller ist, wird dieser Pfad von der App gespeichert; dann erinnert sich die App an die zuvor angezeigte Ansichtshierarchie ( Tab Bar Controller → Navigation Controller → My View Controller ).

Nach dem Zuweisen der Wiederherstellungskennung müssen wir die Methoden encodeRestorableState(with coder:) und decodeRestorableState(with coder:) für jeden der beibehaltenen Ansichtscontroller implementieren. Mit diesen beiden Methoden können wir angeben, welche Daten gespeichert oder geladen werden müssen und wie sie codiert oder decodiert werden.

Sehen wir uns den View-Controller an:

 // MyViewController.swift​ // MARK: State restoration // UIViewController already conforms to UIStateRestoring protocol by default extension MyViewController { // will be called during state preservation override func encodeRestorableState(with coder: NSCoder) { // encode the data you want to save during state preservation coder.encode(self.username, forKey: "username") super.encodeRestorableState(with: coder) } // will be called during state restoration override func decodeRestorableState(with coder: NSCoder) { // decode the data saved and load it during state restoration if let restoredUsername = coder.decodeObject(forKey: "username") as? String { self.username = restoredUsername } super.decodeRestorableState(with: coder) } }

Denken Sie daran, die Implementierung der Oberklasse am Ende Ihrer eigenen Methode aufzurufen. Dadurch wird sichergestellt, dass die übergeordnete Klasse die Möglichkeit hat, den Status zu speichern und wiederherzustellen.

Sobald die Objekte die Decodierung abgeschlossen haben, wird applicationFinishedRestoringState() aufgerufen, um dem Ansichtscontroller mitzuteilen, dass der Zustand wiederhergestellt wurde. Wir können die Benutzeroberfläche für den View-Controller in dieser Methode aktualisieren.

 // MyViewController.swift​ // MARK: State restoration // UIViewController already conforms to UIStateRestoring protocol by default extension MyViewController { ... override func applicationFinishedRestoringState() { // update the UI here self.usernameLabel.text = self.username } }

Hier hast du es! Dies sind die wesentlichen Methoden zum Implementieren der Zustandserhaltung und -wiederherstellung für Ihre App. Denken Sie daran, dass das Betriebssystem den gespeicherten Zustand entfernt, wenn die App vom Benutzer zwangsweise geschlossen wird, um zu vermeiden, dass Sie in einem fehlerhaften Zustand stecken bleiben, falls bei der Erhaltung und Wiederherstellung des Zustands etwas schief geht.

Speichern Sie auch keine Modelldaten (dh Daten, die in UserDefaults oder Core Data hätten gespeichert werden sollen) im Zustand, auch wenn dies bequem erscheinen mag. Zustandsdaten werden entfernt, wenn der Benutzer das Beenden Ihrer App erzwingt, und Sie möchten auf diese Weise sicherlich keine Modelldaten verlieren.

Führen Sie die folgenden Schritte aus, um zu testen, ob die Zustandserhaltung und -wiederherstellung gut funktionieren:

1. Erstellen und starten Sie eine App mit Xcode.
2. Navigieren Sie zu dem Bildschirm mit Zustandserhaltung und -wiederherstellung, den Sie testen möchten.
3. Kehren Sie zum Startbildschirm zurück (indem Sie nach oben wischen oder auf die Home-Schaltfläche doppelklicken oder im Simulator Shift ⇧ + Cmd ⌘ + H drücken), um die App in den Hintergrund zu schicken.
4. Stoppen Sie die App in Xcode, indem Sie auf die Schaltfläche klicken.
5. Starten Sie die App erneut und prüfen Sie, ob der Zustand erfolgreich wiederhergestellt wurde.

Da dieser Abschnitt nur die Grundlagen der Zustandserhaltung und -wiederherstellung behandelt, empfehle ich die folgenden Artikel von Apple Inc. für tiefergehende Kenntnisse zur Zustandswiederherstellung:

1. Erhaltung und Wiederherstellung des Zustands
2. UI-Erhaltungsprozess
3. UI-Wiederherstellungsprozess

4. Reduzieren Sie die Verwendung von nicht undurchsichtigen Ansichten so weit wie möglich

Eine undurchsichtige Ansicht ist eine Ansicht ohne Transparenz, was bedeutet, dass dahinter platzierte UI-Elemente überhaupt nicht sichtbar sind. Wir können eine Ansicht im Interface Builder undurchsichtig einstellen:

Oder wir können dies programmgesteuert mit der isOpaque Eigenschaft von UIView tun:

 view.isOpaque = true

Wenn Sie eine Ansicht auf undurchsichtig setzen, optimiert das Zeichensystem die Zeichenleistung beim Rendern des Bildschirms.

Wenn eine Ansicht Transparenz aufweist (dh Alpha unter 1,0 liegt), muss iOS zusätzliche Arbeit leisten, um zu berechnen, was angezeigt werden soll, indem verschiedene Ebenen von Ansichten in der Ansichtshierarchie gemischt werden. Wenn andererseits eine Ansicht undurchsichtig eingestellt ist, stellt das Zeichensystem diese Ansicht einfach in den Vordergrund und vermeidet die zusätzliche Arbeit des Mischens der mehreren Ansichtsebenen dahinter.

Sie können überprüfen, welche Ebenen im iOS-Simulator gemischt (nicht deckend) werden, indem Sie Debuggen → Überblendete Ebenen mit Farbe aktivieren .

Nachdem Sie die Option Color Blended Layers aktiviert haben, können Sie sehen, dass einige Ansichten rot und andere grün sind. Rot zeigt an, dass die Ansicht nicht undurchsichtig ist und dass die Ausgabeanzeige das Ergebnis von dahinter verschmolzenen Ebenen ist. Grün zeigt an, dass die Ansicht undurchsichtig ist und keine Überblendung durchgeführt wurde.

Die oben gezeigten Beschriftungen („Freunde anzeigen“ usw.) sind rot hervorgehoben, da beim Ziehen einer Beschriftung auf das Storyboard die Hintergrundfarbe standardmäßig auf transparent eingestellt ist. Wenn das Zeichensystem die Anzeige in der Nähe des Beschriftungsbereichs zusammensetzt, fragt es nach der Ebene hinter der Beschriftung und führt einige Berechnungen durch.

Eine Möglichkeit, die App-Leistung zu optimieren, besteht darin, die Anzahl der rot markierten Aufrufe so weit wie möglich zu reduzieren.

Indem wir label.backgroundColor = UIColor.clear in label.backgroundColor = UIColor.white , können wir die Ebenenüberblendung zwischen der Beschriftung und der dahinter liegenden Ansichtsebene reduzieren.

Sie haben vielleicht bemerkt, dass der Simulator in der Bildansicht immer noch rot anzeigt, selbst wenn Sie eine UIImageView auf undurchsichtig gesetzt und ihr eine Hintergrundfarbe zugewiesen haben. Dies liegt wahrscheinlich daran, dass das Bild, das Sie für die Bildansicht verwendet haben, einen Alphakanal hat.

Um den Alphakanal für ein Bild zu entfernen, können Sie die Vorschau-App verwenden, um ein Duplikat des Bildes zu erstellen ( Umschalttaste ⇧ + Cmd ⌘ + S ) und beim Speichern das Kontrollkästchen „Alpha“ deaktivieren.

5. Übergeben Sie schwere Verarbeitungsfunktionen an Hintergrundthreads (GCD)

Da UIKit nur im Hauptthread funktioniert, verlangsamt die Ausführung einer starken Verarbeitung im Hauptthread die Benutzeroberfläche. Der Haupt-Thread wird von UIKit nicht nur verwendet, um Benutzereingaben zu verarbeiten und darauf zu reagieren, sondern auch um den Bildschirm zu zeichnen.

Der Schlüssel, um eine App reaktionsfähig zu machen, besteht darin, so viele schwere Verarbeitungsaufgaben wie möglich in Hintergrundthreads zu verschieben. Vermeiden Sie komplexe Berechnungen, Netzwerke und umfangreiche E/A-Vorgänge (z. B. Lesen und Schreiben auf die Festplatte) im Haupt-Thread.

Möglicherweise haben Sie einmal eine App verwendet, die plötzlich nicht mehr auf Ihre Berührungseingabe reagierte, und es fühlt sich an, als wäre die App hängen geblieben. Dies wird höchstwahrscheinlich dadurch verursacht, dass die App schwere Rechenaufgaben im Hauptthread ausführt.

Der Haupt-Thread wechselt normalerweise in kleinen Intervallen zwischen UIKit-Aufgaben (z. B. der Verarbeitung von Benutzereingaben) und einigen leichten Aufgaben. Wenn eine schwere Aufgabe im Haupt-Thread ausgeführt wird, muss UIKit warten, bis die schwere Aufgabe beendet ist, bevor Berührungseingaben verarbeitet werden können.

Standardmäßig werden der Code innerhalb der Lebenszyklusmethoden des Ansichtscontrollers (z. B. viewDidLoad) und die IBOutlet-Funktionen im Hauptthread ausgeführt. Um schwere Verarbeitungsaufgaben in einen Hintergrundthread zu verschieben, können wir die von Apple bereitgestellten Grand Central Dispatch-Warteschlangen verwenden.

Hier ist die Vorlage zum Wechseln von Warteschlangen:

 // Switch to background thread to perform heavy task. DispatchQueue.global(qos: .default).async { // Perform heavy task here. // Switch back to main thread to perform UI-related task. DispatchQueue.main.async { // Update UI. } }

Das qos steht für „Quality of Service“. Unterschiedliche Quality-of-Service-Werte geben unterschiedliche Prioritäten für die spezifizierten Aufgaben an. Das Betriebssystem weist Tasks, die Warteschlangen mit höheren QoS-Werten zugeordnet sind, mehr CPU-Zeit und CPU-Leistungs-E/A-Durchsatz zu, was bedeutet, dass eine Task in einer Warteschlange mit höheren QoS-Werten schneller beendet wird. Ein höherer QoS-Wert verbraucht auch mehr Energie, da mehr Ressourcen verbraucht werden.

Hier ist die Liste der QoS-Werte von der höchsten bis zur niedrigsten Priorität:

Apple hat eine praktische Tabelle mit Beispielen dafür bereitgestellt, welche QoS-Werte für verschiedene Aufgaben verwendet werden sollten.

Beachten Sie, dass der gesamte UIKit-Code immer im Hauptthread ausgeführt werden sollte. Das Ändern von UIKit-Objekten (z. B. UILabel und UIImageView ) im Hintergrundthread kann unbeabsichtigte Folgen haben, z. B. dass die Benutzeroberfläche nicht wirklich aktualisiert wird, ein Absturz auftritt und so weiter.

Aus Apples Artikel:

„Das Aktualisieren der Benutzeroberfläche in einem anderen Thread als dem Hauptthread ist ein häufiger Fehler, der zu verpassten UI-Updates, visuellen Mängeln, Datenbeschädigungen und Abstürzen führen kann.“

Ich empfehle, sich das WWDC 2012-Video von Apple zur UI-Parallelität anzusehen, um besser zu verstehen, wie man eine responsive App erstellt.

Anmerkungen

Der Nachteil der Leistungsoptimierung besteht darin, dass Sie zusätzlich zur Funktionalität der App mehr Code schreiben oder zusätzliche Einstellungen konfigurieren müssen. Dadurch wird Ihre App möglicherweise später als erwartet bereitgestellt, und Sie müssen in Zukunft mehr Code warten, und mehr Code bedeutet potenziell mehr Fehler.

Bevor Sie Zeit mit der Optimierung Ihrer App verbringen, fragen Sie sich, ob die App bereits reibungslos funktioniert oder ob sie einen nicht reagierenden Teil hat, der wirklich optimiert werden muss. Viel Zeit damit zu verbringen, eine bereits flüssige App zu optimieren, um 0,01 Sekunden einzusparen, lohnt sich möglicherweise nicht, da die Zeit besser für die Entwicklung besserer Funktionen oder anderer Prioritäten verwendet werden könnte.

Weitere Ressourcen

• „Eine Suite köstlicher iOS-Eye Candy“, Tim Oliver, Tokyo iOS Meetup 2018 (Video)
• „Erstellen gleichzeitiger Benutzeroberflächen auf iOS“, Andy Matuschak, WWDC 2012 (Video)
• „Bewahren der Benutzeroberfläche Ihrer App über Starts hinweg“, Apple
• „Concurrency Programming Guide: Dispatch Queues“, Documentation Archive, Apple
• „Haupt-Thread-Checker“, Apple