Share
Bine ați venit la partea a șasea a seriei MobileTuts + Beginning iOS Development. Această tranșă va acoperi fundamentele de depanare Xcode. Acesta va include o sumă scurtă de teorie de depanare software și o aplicație de practică pentru a demonstra utilizarea punctelor de întrerupere și a programului de depanare Xcode. Articolul se va încheia cu câteva sfaturi generale și cele mai bune practici, precum și o listă cu resurse utile disponibile pentru a vă continua procesul de învățare.
Probleme de vizualizare a conținutului media de mai sus? Accesați versiunea completă și de înaltă calitate a acestui videoclip în formatul său original MOV.
În loc să construim o nouă aplicație specială pentru acest tutorial, am luat aplicația FortuneCrunch pe care am creat-o în partea a doua a acestei serii și am introdus o serie de erori diferite în codul sursă. Descărcați BrokenCrunch, versiunea ruptă a FortuneCrunch care însoțește această postare, să urmeze cât timp demonstrez cum să folosesc instrumentele de depanare Xcode.
Înainte de a începe debugarea BrokenCrunch, hai să vorbim un moment despre teoria de depanare a software-ului. În general, erorile de software (cunoscute și ca "bug-uri") pot fi clasificate după cum urmează:
După cum sugerează și numele, apare o eroare de compilare când încercați să compilați codul sursă al aplicației. În Xcode, aceasta se întâmplă atunci când selectați "Build and Run" sau "Build and Debug" pentru a lansa aplicația pe dispozitiv sau simulator. Când se întâlnește o eroare de compilare, aceasta va împiedica literalmente lansarea aplicației. După cum vom vedea, erorile din această categorie pot apărea fie din declarații de sintaxă nonsensale sau incorecte, fie din probleme care apar în faza de conectare a aplicației dvs.. În general, erorile de compilare sunt cea mai ușoară dintre cele trei categorii de rezolvat deoarece compilatorul va emite în mod obișnuit un mesaj de eroare semnificativ sau un mesaj de avertizare care vă va avertiza cu privire la natura problemei.
Eroare de timp de execuție apar după ce aplicația a fost compilată și lansată în Simulator sau pe un dispozitiv. Un accident de aplicație sau o scurgere de memorie care apare ca urmare a gestionării necorespunzătoare a memoriei obiectului este un exemplu de eroare de execuție.
O eroare logică apare în timpul fazei de execuție a unei aplicații și duce la comportamentul neașteptat sau nedorit al aplicației, care este în conflict cu rezultatul dorit al dezvoltatorului de software sau al părților interesate de proiect. Un bun exemplu de eroare logică este o formulă matematică care a fost implementată incorect. Luați în considerare teorema lui Pitagora:
Dacă un dezvoltator de software a implementat neintenționat această formulă ca:
Rezultatul ar fi o eroare logică, dar cel mai probabil nu va cauza ca aplicația să se prăbușească. Aceasta este ceea ce face ca erorile logice să fie atât de periculoase: aplicația se poate executa aparent "fără bug-uri" dezvoltatorului, în timp ce produce, de fapt, rezultate nevalabile sau nedorite.
Cu aceste cunoștințe teoretice în loc, deschideți BrokenCrunch și să începem. După încărcarea aplicației noastre exemplu, selectați Build> Build și Debug. Veți observa că aplicația nu se lansează, iar compilatorul a generat o serie de erori. Pentru a vizualiza rezultatele încercării de compilare, selectați Construiți> Construiți rezultatele.
Selectarea erorilor enumerate vă va duce direct la linia de cod unde este raportată eroarea. Un lucru important este însă faptul că numărul de erori raportate de compilator și numerele de linie ale acelor erori ar trebui să fie considerate drept "cea mai bună estimare" a ceea ce este în neregulă cu cererea dvs., nu o pronunțare concludentă.
De fapt, o singură eroare de sintaxă poate duce la mai multe erori raportate de compilator, care nu au nicio legătură cu problema. De exemplu, aruncăm o privire la "Previzualizare înainte de 'setImage'" linie de eroare. Dacă examinați linia în cauză, ar trebui să găsiți că sintaxa este perfectă. După cum se dovedește, problema aici nu este pe linia raportată, ci linia chiar deasupra ei. Vedeți problema?
NSLog () declarația nu a fost încheiată cu un punct și virgulă. Aceasta înseamnă că compilatorul nu știe că intenționați să terminați linia după ultima paranteză și vedeți totul de la NSLog până la brațul final de închidere și semi-colon după UIControlStateNormal ca o declarație.
Adăugați punct și virgulă pentru a finaliza NSLog afirmație:
NSLog (@ "În crunchCookie");
Salvați fișierul sursă și faceți din nou clic pe "Build and Debug". Două dintre cele trei erori afișate inițial ar trebui rezolvate acum.
Apoi, selectați "Nici o declarație de proprietate" eroare. După cum puteți vedea, această eroare arată că proprietatea pe care încercăm să o sintetiză nu există. Pentru a verifica acest lucru, deschideți fișierul FortuneCrunchViewController.h unde ar fi trebuit să fie declarată proprietatea. Dacă examinați linia 17, sintaxa este corectă, dar avem o nepotrivire între proprietatea pe care am declarat-o și cea pe care încercăm să o sintetizăm. Obiectivul C este un limbaj sensibil la caz, ceea ce înseamnă că "C" în cookie trebuie să fie capitalizată pentru a se potrivi cu proprietatea pe care încercăm să o sintetizăm. Actualizați declarația de proprietate din fișierul antet pentru a citi:
@property (nonatomic, reține) IBOutlet * fortuneCookieButton;
Salvați fișierul sursă și construiți și depanați încă o dată. De data aceasta, mai degrabă decât deschiderea rezultatelor construirii Build> Build și Debug, faceți clic pur și simplu pe pictograma de eroare din colțul din dreapta jos al Xcode.
Un pas înainte, patru pași înapoi. Eroarea privind linia de proprietate sintetizată a dispărut, însă avem o listă complet nouă de erori. Ce s-a întâmplat?
Acesta este momentul potrivit pentru a observa diferitele faze afișate în fereastra Rezultate rezultate:
Observați că avem un avertisment sub secțiunea "Compilați" din rezultatele de construire a rezultatelor. Aceasta este aceeași secțiune în care au fost raportate erorile noastre anterioare. Acum că cele trei erori anterioare au fost rezolvate, am reușit să progresăm de la faza de compilare la faza de legătură a creării aplicației noastre și toate erorile noi sunt erorile de conectare. Când întâmpinați o eroare de legătură, este în mod obișnuit deoarece încercați să utilizați funcții dintr-un cadru pe care nu l-ați inclus în aplicație. În acest caz, rezultatele Construi se referă la o funcție numită _UIApplicationMain în fișierul principal.o. Main.o este versiunea compilate, mașină cod de main.m. Să aruncăm o privire la codul sursă din acel fișier. Pe linia 13 puteți vedea un apel pentru funcții la UIApplicationMain:
int retVal = UIApplicațieMain (argc, argv, zero, nil);
UIApplicationMain este o funcție centrală pentru fiecare aplicație iOS, dar cum puteți afla mai multe despre aceasta și să vă dați seama în ce cadru este inclus? Din fericire, SDK-ul iOS vine cu o mare documentație. Dacă țineți apăsat butonul opțiune (sau alt) și faceți dublu clic pe numele funcției, veți lansa un rezumat din documentația oficială SDK pentru iOS care discută această funcție. Dați clic pe pictograma "carte" din partea dreaptă sus pentru a vedea documentația completă disponibilă. Puteți vedea că, prin aceasta, a fost lansată documentația de referință a funcției pentru cadrul UIKit. Bingo, avem cadrul nostru lipsă. Cu toate acestea, înainte de a adăuga cadrul pentru proiect, să examinăm o altă metodă pe care ați fi putut-o utiliza pentru a determina originea UIApplicationMain.
Închideți fereastra de documentare. Acum, țineți apăsat butonul de comandă și faceți dublu clic pe UIApplicationMain funcţie. Acum analizați sursa UIApplication.h, fișierul declarației antetului care conține UIApplicationMain declarație de funcționare. Dacă derulați în partea de sus a ferestrei, veți vedea că acest fișier importă mai multe alte titluri UIKit și că comentariul din partea superioară include numele de cadru "UIKit".
Să mergem la rezolvarea acestor erori de conectare prin includerea cadrului UIKit. Pentru a face acest lucru, faceți clic dreapta sau controlați clic pe folderul Cadru din panoul Grupuri și fișiere și selectați adăugați> cadrele existente. Găsiți cadrul UIKit și faceți clic pe "Adăugați". Pentru a testa munca noastră, selectați din nou Build și Debug.
După cum puteți vedea, simulatorul a lansat cu succes și suntem capabili să vizualizăm aplicația noastră. Aceasta înseamnă că am rezolvat toate erorile de compilare în aplicația noastră.
Mergeți mai departe și faceți clic pe cookie-ul de avere ... după cum puteți vedea, făcând clic pe cookie rezultă o eroare de execuție și aplicația sa prăbușit. Mesajul afișat în partea din stânga jos a ecranului Xcode nu este foarte util, așa că haideți să aruncăm o privire mai atentă prin deschiderea consolei.
Consola afișează atât un stiva de apel a ceea ce se întâmpla în execuția programului nostru în momentul prăbușirii, cât și o explicație mai detaliată: "Terminarea aplicației din cauza unei excepții ... FortuneCrunchViewController cookieCruncher: Selector nerecunoscut trimis la instanță." Acest mesaj înseamnă că butonul nostru sună selector greșit pentru evenimentul pe care l-am declanșat făcând clic pe fișierul cookie. Deoarece interfața pentru FortuneCrunch a fost construită în Interface Builder, să deschidem fișierul Interface Builder XIB pentru "FortuneCrunchViewController" pentru a arunca o privire mai atentă.
Selectați butonul cookie și controlați clic sau clic dreapta pentru a vizualiza o listă de acțiuni conectate:
Puteți vedea că evenimentul Touch Up Inside se referă la o țintă care nu există, indicată prin textul galben. Eliminați țintă inexistentă "cookieCruncher" și reconectați touchUpInside la Proprietarul fișierului selectând țintă "crunchCookie" care apare în meniul derulant. Salvați-vă munca în Interface Builder, reveniți la Xcode și relansați aplicația.
Dacă faceți clic pe cookie-ul de avere, rezultă din nou o eroare de execuție. De data aceasta, mesajul consolei nu este atât de util, ci doar afișează "EXC_BAD_ACCESS".
Luați o altă privire la rezultatele construirii selectând Construiți> Construiți rezultatele. Ați observat avertismentul mai devreme? Avertismentele de compilare sunt adesea o indicație a unei erori de execuție potențiale, dar deoarece nu există nimic incorect cu sintaxa reală a liniei de avertizare emisă, compilatorul este în continuare capabil să construiască aplicația cu succes. Desigur, există momente când un avertisment de compilator este un "flag fals" și nu va duce la o eroare de execuție, dar în sus de 95% din timp, dacă compilatorul a emis un avertisment că faci ceva greșit.
Faceți clic pe avertisment pentru a trece la linia din codul sursă unde a avut loc.
Avertizarea se referă la tipurile de indicatori incompatibili. Vedeți problema? Metoda imageNamed așteaptă un obiect NSString, dar această linie de cod furnizează metoda cu un șir de caractere literal C. Adăugați simbolul "@" pentru a face acest lucru un șir Obiectiv-C:
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-closed.png"] pentruState: UIControlStateNormal];
Salvați progresul și executați din nou aplicația.
De data aceasta, când faceți clic pe cookie-ul de avere, întâmpinați o eroare logică: aplicația nu se prăbușește și eticheta "Happy iPhone Hacking" apare așa cum era de așteptat, dar imaginea de fundal rămâne ca fișierul cookie închis.
Pentru a rezolva acest lucru, să aruncăm o privire la funcția responsabilă de tranziție: (IBAction) crunchCookie. Linia 19 este responsabilă pentru modificarea imaginii de fundal și puteți vedea că setarea noii imagini de fundal la "cookie-closed.png". Dacă aruncați o privire asupra cookie-închis în folderul Resurse, veți vedea că aceasta este, de fapt, aceeași imagine afișată atunci când prima aplicație este încărcată. Trebuie să schimbăm linia respectivă la trecerea la "cookie-crunched.png":
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-crunched.png"] pentruState: UIControlStateNormal];
Construiți și rulați din nou aplicația ... și atingând acum rezultatele cookie-ului în imaginea de fundal așteptată, cu eticheta afișată corect.
Felicitări! Tocmai ați trecut prin procesul de stabilire a erorilor de timp de compilare, a erorilor de execuție și a erorilor logice într-o aplicație. În tot acest timp, abia am reușit să folosim instrumentele puternice de depanare disponibile pentru dvs. cu Xcode.
Pentru a continua explorarea celor mai avansate instrumente de depanare disponibile, să încercăm să extindem aplicația FortuneCrunch pentru ao face mai interesantă. Mai degrabă decât să afișați șirul static "Happy iPhone Hacking!" De fiecare dată când cookie-ul este crunched, să construim o serie de multiple NSString valorile care ar putea fi afișate.
Reveniți la Xcode și deschideți fișierul FortuneCrunchViewController.h. Adăugați următorul membru de date:
NSArray * averi;
Această matrice va fi utilizată pentru a ține strânsele aleatoare ale noastre.
Acum, adăugați următoarea semnătură de metodă:
-(NSString *) generateRandomFortune;
Această linie va declara o nouă metodă în clasa noastră care va fi utilizată pentru a selecta o avere aleatorie din matricea noastră de averi.
Apoi treceți la FortuneCrunchViewController.m. Deoarece această clasă va fi inițiată din fișierul nostru XIB, trebuie să ignorăm initWithCoder și aloca matricea pe care am declarat-o în fișierul .h, inițializându-l cu câteva averi noi:
-(id) initWithCoder: aDecoder auto = [super initWithCoder: aDecoder]; dacă (auto) fortunes = [[NSArray aloca] initWithObjects: @ "Cel care aruncă murdăriile pierde teren", @ "O gură închisă nu adună nici un pic.", @ "Ajutor! Eu sunt prizonier într-o brutărie! "; întoarce-te;
Acum că am creat un nou NSArray, nu uitați să o eliberați în dealloc metodă:
-(void) dealloc [avere eliberare];
Să trecem la codificarea generateRandomFortune funcţie:
-(NSString *) generateRandomFortune int ales_index = arc4random ()% 3 * 10; retur [fortunes objectAtIndex: selected_index];
Aceste linii generează pur și simplu un nou număr de index aleatoriu pe care îl vom folosi pentru a returna șirul de avere corespunzător.
În cele din urmă, modificați crunchCookie metodă de a utiliza unul dintre averile noastre aleatorii, mai degrabă decât textul static "Happy iPhone Hacking!":
fortuneLabel.text = [auto generateRandomFortune];
Construiți și executați aplicația după salvarea acestor modificări. Dacă faceți clic pe modul cookie, veți crea o eroare de execuție. Pentru a înțelege de ce se întâmplă acest lucru, vom folosi instrumentul de depanare Xcode și punctele de întrerupere personalizate.
Punctul de întrerupere este un semnalizator care semnalează aplicației dvs. că executarea programului ar trebui să "întrerupă" atunci când se atinge linia cu punctul de întrerupere. Rularea aplicației în modul "Build and Debug" vă permite să utilizați puncte de întrerupere. Pentru a seta un punct de întrerupere, faceți clic pur și simplu în editorul "jgheab" de pe linia pe care doriți să declanșeze un breakpoint. Pentru a afla ce se întâmplă în cererea noastră, vom stabili punctul nostru de întâlnire NSLog line, imediat după metoda crunchCookie se numește:
Construiți și depanați aplicația cu acest nou punct de întrerupere.
După încărcarea aplicației, dați clic pe modul cookie. Dacă vă uitați în partea din stânga jos a Xcode, veți vedea mesajul de stare "Oprit la punctul de întrerupere 1". Aceasta înseamnă că programul de depanare a întrerupt cu succes executarea programului la punctul de întrerupere pe care l-ați setat. Veți observa, de asemenea, că o săgeată roșie indică linia de execuție curentă în care debuggerul a "întrerupt" programul.
Deci, ce puteți face cu depanatorul? Mai mult decât poate fi acoperit într-un singur tutorial. Cu toate acestea, există trei acțiuni fundamentale pe care le puteți lua în acest moment: treci peste, intră și ieși. Toate aceste opțiuni sunt disponibile de la bara de meniuri pentru depanare în cod.
Dacă apăsați butonul "step over" din meniul de depanare în cod, veți observa că execuția programului continuă cu linia următoare. "Pasul peste" va continua pur și simplu să executați o singură linie pe rând în cadrul metodei curente, dar nu va urma execuția codului dvs. dacă va fi furculiță la altă metodă. Dacă doriți să urmați de fapt executarea codului în alte metode de apel în codul dvs., va trebui să utilizați butonul "pas în".
După cum puteți vedea, intrarea în realitate ne-a dus în noi generateRandomFortune care este exact ceea ce dorim. Faceți clic din nou pe "Pasul peste" pentru a vedea ce se întâmplă când arc4random () se numește. Nu ar fi frumos dacă știm ce a fost setată variabila select_index? Din fericire, putem! Una dintre cele mai bune caracteristici de utilizare a depanatorului este capacitatea de a pur și simplu mouse-ul peste variabile pentru a vedea rapid valoarea lor.
În mod evident, chosen_index valoarea este mult mai mare decât lungimea matricei noastre. Spre deosebire de alte limbi de programare, funcția de randomizare pe care o folosim va returna un număr întreg, deci nu este nevoie să convertiți dintr-o zecimă la un întreg prin înmulțirea valorii cu 10. Actualizați linia pentru a citi:
int ales_index = arc4random ()% 3;
Am terminat de făcut modificări la această funcție, deci utilizați butonul "Step Out" pentru a ieși din această subfuncție și a reveni la crunchCookie. Rețineți că, deși nu am văzut-o, restul funcției a fost executat ca normal.
În cele din urmă, țineți cont de butonul de întrerupere "Activare / Dezactivare" și de butonul "Continuați executarea" din bara de meniuri pentru depanare în cod. "Continuați execuția" va permite pur și simplu ca executarea programului să continue în mod normal. Vă puteți gândi la acest lucru ca la butonul "unpause". Continuați și apăsați acum.
Înainte de a trece la oprirea punctelor de întrerupere, există încă o problemă de abordat: ceea ce tocmai ați experimentat se numește "debugger în cod". Este foarte puternic, dar sunt disponibile și alte două moduri de depanare: fereastra de depanare completă și perspectiva mini-debuggerului.
Pentru a accesa fereastra de depanare completă, faceți clic pe pictograma de depanare din meniul de depanare din cod. Această fereastră are în mod semnificativ mai multe informații decât debuggerul în cod. În stânga, aveți o urmă de stivă care afișează contextul de execuție a programului (de asemenea aveți posibilitatea de a selecta din oricare dintre firele create în prezent). În dreapta, puteți vedea o afișare rapidă a diferitelor variabile aflate în prezent în memorie. Selectarea unei semnături diferite de stack-call va schimba vizualizarea în Debugger. Puteți modifica aspectul ferestrei Debugger accesând Run> Debugger Display.
În cele din urmă, mini-debuggerul este o altă perspectivă de depanare disponibilă pentru dvs. Eu rareori folosesc această perspectivă, dar este disponibilă pentru tine Run> Mini-Debugger.
Deoarece am rezolvat doar eroarea introdusă în codul nostru de avere aleator, nu mai avem nevoie de depanatorul pentru a fi activat. Schimbați punctele de întrerupere. Cu toate acestea, înainte de a construi din nou aplicația, să adaptăm dimensiunea fontului etichetei noastre de avere.
Open Interface Builder, selectați eticheta și modificați fontul din Inspector la Arial Black, 9 point, apoi selectați caseta "Ajustare pentru a se potrivi" și schimbați dimensiunea minimă a fontului la 6 puncte. Acum, construiți și conduceți din nou proiectul nostru.
Voila! Aplicația noastră funcționează acum așa cum intenționăm.
Acum că ați fost prezentați la elementele de bază ale depanării în Xcode, vă recomandăm să aplicați următoarele reguli în fluxul dvs. de lucru de zi cu zi:
În timp ce simulatorul este o metodă utilă de testare a unei aplicații în timpul fazei de dezvoltare a produsului dvs., nu este un înlocuitor pentru testarea pe un dispozitiv fizic. Acest lucru se datorează faptului că simulatorul și un dispozitiv iOS diferă în moduri importante și fundamentale. De exemplu, simulatorul se execută, în mod evident, în cadrul OS X, iar sistemul de fișiere de pe OS X nu are sensibilitate la minusculă. Cu toate acestea, sistemul de fișiere din iOS este sensibil la minuscule. Referindu-se astfel la dosar cookie-CRUNChed.png, in loc de cookie-crunched.png, va funcționa foarte bine în simulator dar nu reușește pe un dispozitiv iOS real. Un alt aspect important este faptul că simulatorul are mult mai multă memorie decât un dispozitiv real, iar acest fapt va afecta adesea experiența utilizatorului. În cele din urmă, nu toate aplicațiile implicite livrate cu iOS sunt disponibile în simulator, inclusiv programele Maps și App Store. Aceasta înseamnă că nu veți putea testa codul care generează indicații de conducere cu aplicația Hărți sau care promovează încrucișat aplicațiile din App Store din simulator. Acestea sunt doar câteva dintre diferențele care există. Vă recomandăm foarte testarea pe cât mai multe dispozitive fizice iOS care rulează cât mai multe versiuni diferite de iOS orientate pe cât posibil.
Analizorul static Clang este un instrument special de analiză statică C / Objective-C care se livrează cu Xcode. Acest instrument vă poate analiza codul pentru erori sau neconcordanțe care altfel ar putea trece neobservate.
În timp ce detaliile referitoare la modul în care funcționează analizorul depășesc sfera de aplicare a acestui articol, utilizarea acestuia din fericire este foarte ușoară. Pentru a efectua o analiză statică a codului, selectați pur și simplu Build> Build and Analyze din meniul de construire Xcode.
Dacă doriți să aflați mai multe despre modul în care funcționează opțiunea "Construiți și analizați", puteți citi despre analiza statistică a codurilor statice și despre analizorul static online Clang.
În acest tutorial, am aflat despre modul în care funcționează punctele de blocare prin stabilirea punctelor de întrerupere a proiectului în codul nostru. În plus față de punctele de întrerupere specifice proiectului, Xcode vă va permite să setați puncte de întrerupere "globale" care se vor aplica tuturor proiectelor iOS pe care le creați în Xcode. Stabilirea unui punct de întrerupere global objc_exception_throw vă va permite să lansați automat depanatorul ori de câte ori survine o excepție (un tip de eroare de execuție). Pentru a citi mai multe despre avantajele acestei abordări și despre modul în care o puneți în aplicare în cod, consultați Sfatul meu rapid pentru iOS cu privire la punctele de întrerupere objc_exception_throw și global.
După cum sa menționat anterior în acest tutorial, marea majoritate a avertismentelor de compilator care sunt emise ar trebui rezolvate înainte de a lansa proiectul și nu ar trebui să existe într-adevăr un scenariu când un cod care generează avertismente de compilator trebuie sa rămân neschimbate pentru ca o aplicație să funcționeze corect. În consecință, unii programatori recomandă tratarea tuturor erorilor de avertizare ale compilatorului, ceea ce le obligă să fie rezolvate ca parte a procesului normal de dezvoltare.
Pentru toate cazurile, cu excepția câtorva cazuri, susțin această idee, iar Xcode simplifică implementarea. Mergi la Proiect> Editați setările proiectului apoi selectați fila Construiți. Introduceți "Avertisment de traume" în bara de căutare și veți vedea o valoare booleană numită "Atenționați-vă ca erori". Bifați această casetă pentru a activa funcția.
Un alt pas pe care îl puteți lua pentru a spori șansele ca aplicația dvs. să fie acceptată prima oară când o trimiteți la magazinul iTunes este să activați parametrul "Build and Validate" în setările de construire a proiectului. Introduceți "validați" în caseta de căutare din fila de configurare a setărilor proiectului, apoi selectați "Validare produs construit". Această opțiune va executa unele dintre testele efectuate de recenzorii Apple, permițându-vă să preveniți eventual o respingere a aplicației App Store. Trebuie menționat faptul că dacă bifați această casetă nu este o garanție că aplicația dvs. va trece în revistă App Store, dar este mai bine decât nimic.
În plus față de consolă, de a construi rezultatele și de Debugger, există și alte câteva instrumente de depanare și optimizare, pe care ar trebui să le cunoașteți în eforturile de dezvoltare. Pentru mai multe informații, consultați documentația pentru următoarele instrumente:
Acesta a fost un tur tur al depanării cu SDK-ul iOS. Există încă mult mai multe care pot fi făcute, dar sperăm că această lecție a fost suficientă pentru a vă ajuta să rezolvați rapid bug-urile în propriile aplicații și să scrieți mai bune programe! Dacă doriți să aflați mai multe despre unele dintre instrumentele avansate discutate în acest tutorial, cum ar fi Instruments, Shark sau SpinControl, sau dacă doriți să aflați mai multe despre depanare în general, lăsați un comentariu de mai jos și spuneți-mi!
Accentsconagua