Share
Willkommen zu Teil 6 der Mobiletuts + Beginning iOS Development-Serie. In dieser Tranche werden die Grundlagen für das Debuggen von Xcode behandelt. Sie enthält eine kurze Einführung in die Software-Debugging-Theorie und eine Übungsanwendung, um die Verwendung von Haltepunkten und den Xcode-Debugger zu demonstrieren. Zum Abschluss des Artikels werden einige allgemeine Tipps und bewährte Methoden sowie eine Liste nützlicher Ressourcen zur Verfügung gestellt, über die Sie Ihr Lernen fortsetzen können.
Probleme beim Anzeigen der Medien oben? Greifen Sie auf die vollständige, hochwertige Version dieses Videos im ursprünglichen MOV-Format zu.
Anstatt eine neue Anwendung speziell für dieses Lernprogramm zu erstellen, habe ich die FortuneCrunch-Anwendung übernommen, die wir in Teil zwei dieser Serie erstellt haben, und eine Reihe verschiedener Fehler in den Quellcode eingefügt. Laden Sie BrokenCrunch herunter, die gebrochene Version von FortuneCrunch, die diesen Beitrag begleitet, folgen, während ich die Verwendung der Xcode-Debugging-Tools demonstriere.
Bevor wir mit dem Debuggen von BrokenCrunch beginnen, lassen Sie uns einen Moment über Software-Debugging-Theorie sprechen. Im Allgemeinen können Softwarefehler (auch als "Fehler" bezeichnet) wie folgt kategorisiert werden:
Wie der Name andeutet, tritt ein Kompilierungsfehler auf, wenn Sie versuchen, den Anwendungsquellcode zu kompilieren. In Xcode geschieht dies, wenn Sie "Build and Run" oder "Build and Debug" auswählen, um Ihre Anwendung auf dem Gerät oder Simulator zu starten. Wenn ein Fehler bei der Kompilierung auftritt, wird der Start der Anwendung buchstäblich verhindert. Wie wir sehen werden, können Fehler in dieser Kategorie entweder durch unsinnige oder falsche Syntaxanweisungen oder durch Probleme verursacht werden, die in der Verknüpfungsphase Ihres Anwendungsbuilds auftreten. Im Allgemeinen sind Fehler beim Kompilieren die einfachste der drei zu lösenden Kategorien, da der Compiler normalerweise eine aussagekräftige Fehlermeldung oder Warnmeldung ausgibt, die Sie auf die Art des Problems aufmerksam macht.
Laufzeitfehler treten auf, nachdem Ihre Anwendung kompiliert und im Simulator oder auf einem Gerät gestartet wurde. Ein Anwendungsabsturz oder ein Speicherverlust, der als Folge einer unzureichenden Objektspeicherverwaltung auftritt, ist ein Beispiel für einen Laufzeitfehler.
Ein logischer Fehler tritt während der Laufzeitphase einer Anwendung auf und führt zu unerwartetem oder unerwünschtem Anwendungsverhalten, das mit dem beabsichtigten Ergebnis des Softwareentwicklers oder des Projektteilnehmers in Konflikt steht. Ein gutes Beispiel für einen logischen Fehler ist eine falsch implementierte mathematische Formel. Betrachten Sie den Satz des Pythagoras:
Wenn ein Softwareentwickler diese Formel unbeabsichtigt implementiert hat als:
Das Ergebnis wäre ein logischer Fehler, aber höchstwahrscheinlich würde die Anwendung nicht abstürzen. Das macht logische Fehler so gefährlich: Die Anwendung kann für den Entwickler scheinbar "fehlerfrei" ausgeführt werden, während er tatsächlich ungültige oder unerwünschte Ausgaben erzeugt.
Mit diesem theoretischen Wissen öffnen Sie BrokenCrunch und machen Sie uns auf den Weg. Wählen Sie nach dem Laden unserer Beispielanwendung Erstellen> Erstellen und Debuggen. Sie werden feststellen, dass die Anwendung nicht gestartet werden kann und der Compiler eine Reihe von Fehlern generiert hat. Wählen Sie, um die Ergebnisse der versuchte Kompilierung anzuzeigen Build> Build-Ergebnisse.
Durch Auswahl der aufgelisteten Fehler gelangen Sie direkt zu der Codezeile, in der der Fehler gemeldet wird. Beachten Sie jedoch, dass die Anzahl der Fehler, die vom Compiler gemeldet werden, und die Zeilennummern dieser Fehler als "beste Vermutung" der Fehler in Ihrer Anwendung und nicht als abschließende Äußerung angesehen werden sollten.
In der Tat kann ein einfacher Syntaxfehler dazu führen, dass vom Compiler mehrere Fehler gemeldet werden, die sich scheinbar nicht auf das Problem beziehen. Schauen Sie sich als Beispiel das an "Erwartete Klammer vor 'setImage'" Fehlerzeile. Wenn Sie die betreffende Zeile untersuchen, sollten Sie feststellen, dass die Syntax perfekt ist. Wie sich herausstellt, liegt das Problem hier nicht in der gemeldeten Zeile, sondern in der Zeile darüber. Sehen Sie das Problem??
Das NSLog () Die Anweisung wurde nicht mit einem Semikolon beendet. Das bedeutet, dass der Compiler nicht weiß, dass Sie beabsichtigen, die Zeile nach der letzten Klammer zu beenden, und von dort aus alles anzeigt NSLog bis zur letzten schließenden Klammer und nach dem Semikolon UIControlStateNormal als eine Aussage.
Fügen Sie das Semikolon hinzu, um das zu beenden NSLog Aussage:
NSLog (@ "In crunchCookie");
Speichern Sie die Quelldatei und klicken Sie erneut auf "Build and Debug". Zwei der drei ursprünglich angezeigten Fehler sollten jetzt behoben werden.
Als nächstes wählen Sie die "Keine Eigentumserklärung" Error. Wie Sie sehen, meldet dieser Fehler, dass die zu synthetisierende Eigenschaft nicht vorhanden ist. Um dies zu überprüfen, öffnen Sie die FortuneCrunchViewController.h-Datei, in der die Eigenschaft hätte deklariert werden sollen. Wenn Sie die Zeile 17 untersuchen, ist die Syntax korrekt, aber wir haben eine Diskrepanz zwischen der von uns deklarierten Eigenschaft und der zu synthetisierenden Eigenschaft. Objective-C ist eine von Groß- und Kleinschreibung abhängige Sprache, was bedeutet, dass das "C" im Cookie aktiviert werden muss, damit es mit der Eigenschaft übereinstimmt, die wir zu synthetisieren versuchen. Aktualisieren Sie die Eigenschaftsdeklaration in der Header-Datei, um sie zu lesen:
@ property (nichtatomisch, beibehalten) IBOutlet * fortuneCookieButton;
Speichern Sie die Quelldatei und erstellen und debuggen Sie erneut. Dieses Mal, anstatt die Build-Ergebnisse zu öffnen Erstellen> Erstellen und Debuggen, Klicken Sie einfach auf das Fehlersymbol in der rechten unteren Ecke von Xcode.
Ein Schritt vorwärts, vier Schritte zurück. Der Fehler bezüglich der Eigenschaftszeile "synthesize" ist nicht mehr vorhanden, aber wir haben eine völlig neue Fehlerliste. Was ist passiert?
Dies ist ein guter Zeitpunkt, um die verschiedenen Phasen im Fenster "Build-Ergebnisse" zu beachten:
Beachten Sie, dass sich unterhalb des Abschnitts "Compile" der Build-Ergebnisausgabe eine Warnung befindet. Dies ist derselbe Abschnitt, in dem unsere vorherigen Fehler gemeldet wurden. Nachdem die vorherigen drei Fehler behoben wurden, konnten wir von der Kompilierungsphase zur Verknüpfungsphase unseres Anwendungs-Builds voranschreiten, und alle neuen Fehler sind vorhanden Verknüpfungsfehler. Wenn Sie einen Verknüpfungsfehler feststellen, liegt dies normalerweise daran, dass Sie versuchen, Funktionen eines Frameworks zu verwenden, das Sie nicht in Ihre Anwendung aufgenommen haben. In diesem Fall referenzieren die Build-Ergebnisse auf eine aufgerufene Funktion _UIApplicationMain in der Datei main.o. Main.o ist die kompilierte Maschinencodeversion von main.m. Schauen wir uns den Quellcode in dieser Datei an. In Zeile 13 sehen Sie einen Funktionsaufruf an UIApplicationMain:
int retVal = UIApplicationMain (argc, argv, nil, nil);
UIApplicationMain ist eine zentrale Funktion für jede iOS-Anwendung, aber wie können Sie mehr darüber erfahren und herausfinden, in welchem Rahmen sie enthalten ist? Zum Glück enthält das iOS-SDK eine großartige Dokumentation. Wenn Sie die Optionstaste (oder die Alt-Taste) gedrückt halten und auf den Funktionsnamen doppelklicken, wird in der offiziellen Dokumentation zum iOS SDK eine Zusammenfassung mit Informationen zu dieser Funktion angezeigt. Klicken Sie oben rechts auf das Buchsymbol, um die vollständige Dokumentation anzuzeigen. Sie sehen, dass damit die Funktionsreferenzdokumentation für das UIKit-Framework gestartet wurde. Bingo, wir haben unser fehlendes Framework. Bevor wir jedoch das Framework zum Projekt hinzufügen, untersuchen wir eine andere Methode, die Sie zur Bestimmung des Ursprungs verwendet haben könnten UIApplicationMain.
Schließen Sie das Dokumentationsfenster. Halten Sie nun die Befehlsschaltfläche gedrückt und doppelklicken Sie auf die UIApplicationMain Funktion. Sie sehen jetzt die Quelle von UIApplication.h, der Header-Deklarationsdatei, die die Datei enthält UIApplicationMain Funktionsdeklaration. Wenn Sie zum oberen Rand des Fensters blättern, werden Sie feststellen, dass diese Datei mehrere andere UIKit-Header importiert und dass der Kommentar oben den Namen des UIKit-Frameworks enthält.
Lassen Sie uns diese Verknüpfungsfehler durch Einbinden des UIKit-Frameworks beheben. Klicken Sie dazu mit der rechten Maustaste oder mit der rechten Maustaste auf den Ordner Frameworks im Bereich Gruppen & Dateien, und wählen Sie aus Fügen Sie> vorhandene Frameworks hinzu. Suchen Sie nach dem UIKit-Framework und klicken Sie auf „Hinzufügen“. Um unsere Arbeit zu testen, wählen Sie erneut Build and Debug.
Wie Sie sehen, wurde der Simulator erfolgreich gestartet und wir können unsere Anwendung sehen. Dies bedeutet, dass wir alle Fehler bei der Kompilierung in unserer Anwendung behoben haben.
Klicken Sie auf den Fortune-Cookie… Wie Sie sehen, führt das Klicken auf den Cookie zu einem Laufzeitfehler und die Anwendung ist abgestürzt. Die unten links im Xcode-Bildschirm angezeigte Meldung ist nicht sehr hilfreich. Schauen wir uns die Konsole also etwas genauer an.
Die Konsole zeigt sowohl einen Aufrufstack der Ereignisse an, die zum Zeitpunkt des Absturzes in unserer Programmausführung aufgetreten sind, als auch eine ausführlichere Erklärung: "App wird wegen nicht abgeholter Ausnahme beendet ... FortuneCrunchViewController cookieCruncher: Nicht erkannter Selektor an Instanz gesendet." Diese Nachricht bedeutet, dass unsere Schaltfläche die falsche Auswahl für das Ereignis aufruft, das wir durch Klicken auf das Cookie ausgelöst haben. Da die Schnittstelle für FortuneCrunch in Interface Builder integriert ist, öffnen wir die Interface Builder XIB-Datei für „FortuneCrunchViewController“, um einen genaueren Blick darauf zu werfen.
Wählen Sie die Cookie-Schaltfläche aus und steuern Sie den Klick oder den Rechtsklick, um eine Liste der verbundenen Aktionen anzuzeigen:
Sie sehen, dass das Touch-Up-Inside-Ereignis auf ein nicht vorhandenes Ziel verweist, das durch den gelben Text angezeigt wird. Entfernen Sie das nicht vorhandene "cookieCruncher" -Ziel und verbinden Sie touchUpInside erneut mit dem Besitzer der Datei, indem Sie das "crunchCookie" -Ziel auswählen, das in der Dropdown-Liste angezeigt wird. Speichern Sie Ihre Arbeit im Interface Builder, wechseln Sie zurück zu Xcode und starten Sie die Anwendung erneut.
Wenn Sie erneut auf den Fortune-Cookie klicken, wird ein Laufzeitfehler angezeigt. Diesmal ist die Konsolenmeldung nicht so hilfreich, sie wird nur angezeigt "EXC_BAD_ACCESS".
Schauen Sie sich die Build-Ergebnisse noch einmal an, indem Sie auswählen Build> Build-Ergebnisse. Haben Sie die Warnung schon früher bemerkt? Compiler-Warnungen sind häufig ein Hinweis auf einen möglichen Laufzeitfehler. Da jedoch die Syntax der Zeile, für die die Warnung ausgegeben wird, nicht fehlerhaft ist, kann der Compiler die Anwendung trotzdem erfolgreich erstellen. Natürlich gibt es Zeiten, in denen eine Compiler-Warnung ein "falsches Flag" ist und nicht zu einem Laufzeitfehler führt, sondern zu 95% der Zeit, wenn der Compiler eine Warnung ausgegeben hat, dass Sie etwas falsch machen.
Klicken Sie auf die Warnung, um zu der Zeile in Ihrem Quellcode zu gelangen, in der sie aufgetreten ist.
Die Warnung bezieht sich auf inkompatible Zeigertypen. Sehen Sie das Problem? Die imageNamed-Methode erwartet ein NSString-Objekt, aber diese Codezeile versorgt die Methode mit einer literalen Zeichenfolge im C-Stil. Fügen Sie das "@" -Symbol hinzu, um eine Objective-C-Zeichenfolge zu erstellen:
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-closed.png"] forState: UIControlStateNormal];
Speichern Sie Ihren Fortschritt und führen Sie die Anwendung erneut aus.
Wenn Sie auf das Fortune-Cookie klicken, wird diesmal ein logischer Fehler angezeigt: Die Anwendung stürzt nicht ab und das Label „Happy iPhone Hacking“ wird wie erwartet angezeigt. Das Hintergrundbild bleibt jedoch als geschlossenes Cookie erhalten.
Um dies zu beheben, werfen wir einen Blick auf die für den Übergang verantwortliche Funktion: (IBAction) CrunchCookie. Zeile 19 ist für das Ändern des Hintergrundbilds verantwortlich und Sie können sehen, dass das neue Hintergrundbild auf "cookie-closed.png" gesetzt wird. Wenn Sie im Ordner Ressourcen auf cookie-closed schauen, werden Sie feststellen, dass es sich tatsächlich um dasselbe Bild handelt, das beim ersten Laden der App angezeigt wird. Wir müssen diese Zeile ändern, um zu "cookie-crunched.png" zu wechseln:
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-crunched.png"] forState: UIControlStateNormal];
Erstellen Sie die Anwendung erneut, und führen Sie sie erneut aus. Wenn Sie nun auf das Cookie tippen, wird das erwartete Hintergrundbild angezeigt, und das Etikett wird ordnungsgemäß angezeigt.
Herzliche Glückwünsche! Sie haben gerade den Vorgang der Behebung von Fehlern bei der Kompilierungszeit, Laufzeitfehler und logischen Fehlern in einer Anwendung durchlaufen. Währenddessen haben wir die leistungsfähigen Debugging-Tools, die Ihnen mit Xcode zur Verfügung stehen, kaum genutzt.
Versuchen Sie, die FortuneCrunch-App zu erweitern, um sie ein wenig interessanter zu machen. Anstatt die statische Zeichenfolge "Happy iPhone Hacking!" Jedes Mal anzuzeigen, wenn der Cookie zerquetscht wird, erstellen wir ein Array aus mehreren NSString Werte, die angezeigt werden könnten.
Wechseln Sie wieder zu Xcode und öffnen Sie die FortuneCrunchViewController.h-Datei. Fügen Sie das folgende Datenelement hinzu:
NSArray * Vermögen;
Dieses Array wird verwendet, um unsere zufälligen Fortune-Strings aufzunehmen.
Fügen Sie nun die folgende Methodensignatur hinzu:
-(NSString *) generateRandomFortune;
Diese Zeile deklariert eine neue Methode in unserer Klasse, mit der ein zufälliges Vermögen aus unserem Fortune-Array ausgewählt wird.
Wechseln Sie als Nächstes zu FortuneCrunchViewController.m. Da diese Klasse von unserer XIB-Datei aus initiiert wird, müssen wir die überschreiben initWithCoder ordnen Sie das von uns deklarierte Array in der .h-Datei zu und initialisieren Sie es mit ein paar neuen Möglichkeiten:
-(id) initWithCoder: aDecoder self = [super initWithCoder: aDecoder]; if (Selbst) Fortunes = [[NSArray-Zuordnung] initWithObjects: @ "Wer Dreck wirft, verliert Boden.", @ "Ein geschlossener Mund sammelt keine Füße.", @ "Hilfe! Ich bin ein Gefangener in einer Bäckerei! “, Null]; return self;
Jetzt haben wir ein neues erstellt NSArray, Vergiss nicht, es in der Dealloc Methode:
-(void) dealloc [Glücksfreigabe];
Gehen wir weiter zum Codieren der generateRandomFortune Funktion:
-(NSString *) generateRandomFortune int chosen_index = arc4random ()% 3 * 10; return [fortunes objectAtIndex: chosen_index];
Diese Zeilen generieren einfach eine neue Zufallsindexnummer, die wir verwenden, um die entsprechende Fortune-Zeichenfolge zurückzugeben.
Ändern Sie abschließend die CrunchCookie Methode, um eines unserer zufälligen Vermögen anstelle des statischen Textes "Happy iPhone Hacking!" zu verwenden:
fortuneLabel.text = [self generateRandomFortune];
Erstellen Sie die Anwendung, und führen Sie sie aus, nachdem Sie diese Änderungen gespeichert haben. Wenn Sie auf das Cookie klicken, wird ein Laufzeitfehler erstellt. Um herauszufinden, warum dies der Fall ist, verwenden wir den Xcode-Debugger und benutzerdefinierte Haltepunkte.
Ein Haltepunkt ist ein Flag, das Ihrer Anwendung signalisiert, dass die Programmausführung "angehalten" wird, wenn die Zeile mit dem Haltepunkt erreicht ist. Wenn Sie Ihre Anwendung im Modus "Build and Debug" ausführen, können Sie Haltepunkte verwenden. Um einen Haltepunkt festzulegen, klicken Sie einfach im Editor auf die Zeile, in der Sie einen Haltepunkt auslösen möchten. Um herauszufinden, was in unserer Anwendung passiert, setzen wir unseren Haltepunkt auf NSLog line, kurz nachdem die crunchCookie-Methode aufgerufen wird:
Erstellen und debuggen Sie die Anwendung mit diesem neuen Haltepunkt.
Klicken Sie nach dem Laden der Anwendung auf das Cookie. Wenn Sie links unten in Xcode nachsehen, sehen Sie die Statusmeldung "An Haltepunkt 1 angehalten". Dies bedeutet, dass der Debugger die Programmausführung an dem von Ihnen festgelegten Haltepunkt erfolgreich beendet hat. Sie werden auch bemerken, dass ein roter Pfeil die aktuelle Ausführungslinie anzeigt, in der der Debugger das Programm "angehalten" hat.
Was können Sie also mit dem Debugger machen? Mehr als in einem einzigen Tutorial behandelt werden kann. Es gibt jedoch drei grundlegende Maßnahmen, die Sie an diesem Punkt ergreifen können: Schritt vorbei, Schritt hinein und Schritt heraus. Alle diese Optionen stehen Ihnen in der In-Code-Debugger-Menüleiste zur Verfügung.
Wenn Sie im In-Code-Debugger-Menü die "Step over" -Taste drücken, werden Sie feststellen, dass die Programmausführung in der nächsten Zeile fortgesetzt wird. "Step over" setzt die Ausführung der aktuellen Methode nur zeilenweise fort, folgt jedoch nicht Ihrer Code-Ausführung, wenn eine andere Methode verwendet wird. Wenn Sie die Code-Ausführung tatsächlich in anderen Methodenaufrufen in Ihrem Code verfolgen möchten, müssen Sie die Schaltfläche "Einsteigen" verwenden.
Wie Sie sehen können, hat uns der Schritt in die Welt gebracht generateRandomFortune Methode, das ist genau das, was wir wollen. Klicken Sie erneut auf "Step over", um zu sehen, was passiert arc4random () wird genannt. Wäre es nicht schön, wenn wir wüssten, worauf die Variable selected_index gerade eingestellt wurde? Zum Glück können wir! Eine der besten Funktionen des Debuggers ist die Möglichkeit, Variablen einfach mit der Maus über den Wert zu ziehen.
Klar, das selected_index Der Wert ist viel größer als die Länge unseres Arrays. Im Gegensatz zu einigen anderen Programmiersprachen gibt die von uns verwendete Randomisierungsfunktion eine ganze Zahl zurück, sodass keine Konvertierung von einer Dezimalzahl in eine ganze Zahl durch Multiplizieren des Werts mit 10 erforderlich ist. Aktualisieren Sie die zu lesende Zeile:
int chosen_index = arc4random ()% 3;
Wir haben alle Änderungen an dieser Funktion vorgenommen. Verwenden Sie die Schaltfläche "Step Out", um diese Unterfunktion zu verlassen und zu zurückzukehren CrunchCookie. Beachten Sie, dass der Rest der Funktion, obwohl wir ihn nicht gesehen haben, normal ausgeführt wurde.
Beachten Sie schließlich die Haltepunkte-Schaltfläche „Aktivieren / Deaktivieren“ und die Schaltfläche „Continue Execution“ in der In-Code-Debugger-Menüleiste. „Continue Execution“ (Fortfahren fortsetzen) lässt die Ausführung des Programms einfach wie gewohnt zu. Sie können es sich als "Pause" -Taste vorstellen. Fahren Sie fort und drücken Sie dies jetzt.
Bevor wir Breakpoints deaktivieren, müssen wir noch ein weiteres Problem lösen: Was Sie gerade erlebt haben, wird als "In-Code-Debugger" bezeichnet. Es ist sehr mächtig, aber es gibt auch zwei andere Debugging-Modi: das vollständige Debugger-Fenster und die Mini-Debugger-Perspektive.
Um auf das vollständige Debugger-Fenster zuzugreifen, klicken Sie auf das Symbol "Debugging" in der In-Code-Debugger-Menüleiste. Dieses Fenster enthält wesentlich mehr Informationen als der In-Code-Debugger. Auf der linken Seite befindet sich ein Stack-Trace, der den Kontext der Programmausführung anzeigt (Sie haben auch die Möglichkeit, einen der aktuell erzeugten Threads auszuwählen). Rechts sehen Sie eine schnelle Anzeige der verschiedenen Variablen, die aktuell gespeichert sind. Durch Auswahl einer anderen Callstack-Signatur wird Ihre Ansicht im Debugger geändert. Sie können das Layout des Debugger-Fensters ändern, indem Sie zu gehen Führen Sie> Debugger-Anzeige aus.
Schließlich ist der Mini-Debugger eine weitere Debugging-Perspektive, die Ihnen zur Verfügung steht. Ich nutze diese Perspektive selten, aber sie steht Ihnen zur Verfügung Führen Sie> Mini-Debugger aus.
Da wir gerade den Fehler behoben haben, der in unseren Zufallscode eingeführt wurde, ist der Debugger nicht mehr aktiv. Haltepunkte ausschalten. Bevor wir jedoch die Anwendung erneut erstellen, müssen wir die Schriftgröße unseres Fortune-Labels anpassen.
Öffnen Sie den Interface Builder, wählen Sie das Etikett aus und ändern Sie die Schrift im Inspektor in Arial Black, 9 Punkte. Wählen Sie dann das Feld „Anpassen“ und ändern Sie die Mindestschriftgröße auf 6 Punkte. Bauen Sie jetzt unser Projekt erneut auf und führen Sie es aus.
Voila! Unsere Anwendung funktioniert jetzt wie beabsichtigt.
Nachdem Sie nun die Grundlagen der Verwendung des Debuggers in Xcode kennen gelernt haben, sollten Sie die folgenden Richtlinien in Ihrem täglichen Entwicklungsworkflow anwenden:
Der Simulator ist zwar eine hilfreiche Methode zum Testen einer Anwendung während der Entwicklungsphase Ihres Produkts, er ersetzt jedoch nicht den Test auf einem physischen Gerät. Dies liegt daran, dass sich der Simulator und ein iOS-Gerät in wichtigen und grundlegenden Aspekten unterscheiden. Beispielsweise wird der Simulator offensichtlich in OS X ausgeführt, und das Dateisystem unter OS X unterscheidet nicht zwischen Groß- und Kleinschreibung. Das Dateisystem unter iOS ist jedoch von Groß- und Kleinschreibung abhängig. Also bezogen auf die Datei Cookie-CRUNChed.png, anstatt cookie-crunched.png, funktioniert im Simulator einwandfrei, schlägt aber auf einem echten iOS-Gerät fehl. Eine weitere wichtige Überlegung ist, dass der Simulator viel mehr Speicher zur Verfügung hat als ein tatsächliches Gerät, und diese Tatsache wird die Benutzererfahrung oft stark beeinträchtigen. Schließlich sind nicht alle Standardanwendungen, die mit iOS ausgeliefert werden, einschließlich der Maps- und App Store-Programme im Simulator verfügbar. Dies bedeutet, dass Sie keinen Code testen können, der eine Wegbeschreibung mit der Maps-App generiert, oder Anwendungen im App Store im Simulator übergreifend unterstützen. Dies sind nur einige der Unterschiede, die es gibt. Ich empfehle nachdrücklich, auf so vielen physischen iOS-Geräten zu testen, auf denen möglichst viele verschiedene Zielversionen von iOS ausgeführt werden.
Der Clang Static Analyzer ist ein spezielles statisches C / Objective-C-Analysewerkzeug, das mit Xcode geliefert wird. Dieses Tool kann Ihren Code auf Fehler oder Inkonsistenzen analysieren, die andernfalls unbemerkt bleiben könnten.
Obwohl die Details zur Funktionsweise des Analysators den Rahmen dieses Artikels sprengen, ist die Verwendung zum Glück sehr einfach. Um eine statische Analyse Ihres Codes durchzuführen, wählen Sie einfach aus Erstellen> Erstellen und analysieren aus dem Xcode-Buildmenü.
Wenn Sie mehr über die Funktionsweise der Option "Erstellen und Analysieren" erfahren möchten, finden Sie online Informationen zur statischen Codeanalyse und zum statischen Analysegerät von Clang.
In diesem Lernprogramm haben wir erfahren, wie Breakpoints funktionieren, indem Sie projektspezifische Breakpoints in unserem Code festlegen. Neben projektspezifischen Haltepunkten können Sie in Xcode auch „globale“ Haltepunkte festlegen, die für alle in Xcode erstellten iOS-Projekte gelten. Einen globalen Haltepunkt setzen auf objc_exception_throw ermöglicht es Ihnen, den Debugger automatisch zu starten, wenn eine Ausnahme (eine Art Laufzeitfehler) auftritt. Weitere Informationen zu den Vorteilen dieses Ansatzes und zur Implementierung in Code finden Sie in meinem iOS-QuickTip zu objc_exception_throw und globalen Haltepunkten.
Wie zuvor in diesem Lernprogramm erwähnt, sollte die überwiegende Mehrheit der ausgegebenen Compiler-Warnungen vor dem Starten Ihres Projekts aufgelöst werden, und es sollte niemals ein Szenario vorkommen, in dem Code generiert wird, der Compiler-Warnungen generiert Muss bleiben unverändert, damit eine Anwendung ordnungsgemäß funktioniert. Einige Programmierer empfehlen daher, alle Compiler-Warnungen als Fehler zu behandeln, sodass sie als Teil des normalen Entwicklungsprozesses behoben werden müssen.
Bis auf ein paar Randfälle unterstütze ich diese Idee und Xcode macht es leicht, sie umzusetzen. Gehe zu Projekt> Projekteinstellungen bearbeiten und wählen Sie dann die Registerkarte Erstellen. Wenn Sie in die Suchleiste "Treat warning" eingeben, wird ein boolescher Wert mit der Bezeichnung "Behandeln von Warnungen als Fehler" angezeigt. Aktivieren Sie dieses Kontrollkästchen, um die Funktion zu aktivieren.
Ein weiterer Schritt, mit dem Sie die Wahrscheinlichkeit erhöhen können, dass Ihre Anwendung bei der ersten Übermittlung an den iTunes Store akzeptiert wird, ist das Aktivieren der Option "Build and Validate" in den Einstellungen zum Erstellen von Projekten. Geben Sie "validate" in das Suchfeld der Registerkarte "Projekteinstellungen" ein, und wählen Sie "Validate Build Product" aus. Mit dieser Option werden einige von den Apple-Prüfern durchgeführte Tests ausgeführt, sodass Sie möglicherweise eine Zurückweisung des App Store vorab deaktivieren. Beachten Sie, dass das Aktivieren dieses Kontrollkästchens keine Garantie dafür ist, dass Ihre App die App Store-Prüfung durchläuft, aber es ist besser als nichts.
Neben der Konsole, den Build-Ergebnissen und dem Debugger gibt es noch einige weitere großartige Debugging- und Optimierungstools, die Sie bei Ihren Entwicklungsarbeiten berücksichtigen sollten. Weitere Informationen finden Sie in der Dokumentation der folgenden Tools:
Dies war eine rasante Tour des Debugging mit dem iOS SDK. Es gibt noch viel mehr zu tun, aber hoffentlich hat diese Lektion ausgereicht, um Ihnen zu helfen, die Fehler in Ihren eigenen Anwendungen schneller zu beheben und bessere Software zu schreiben! Wenn Sie mehr über einige der fortgeschrittenen Tools erfahren möchten, die in diesem Lernprogramm behandelt werden, wie z. B. Instruments, Shark oder SpinControl, oder wenn Sie mehr über Debugging im Allgemeinen erfahren möchten, geben Sie unten einen Kommentar an und lassen Sie es mich wissen!
Accentsconagua