iOS
Profil med instrument

Introduktion

Time Profiler

Det första instrumentet du tittar på är Time Profiler . Med uppmätta intervaller kommer instrument att stoppa genomförandet av programmet och ta ett stapelspår på varje löpande tråd. Tänk på det som att trycka på pausknappen i Xcodes debugger. Här är en förhandsvisning av Time Profiler: -

Den här skärmen visar Call Tree . Call Tree visar hur lång tid som körs på olika metoder inom en app. Varje rad är en annan metod som programmets körningsväg har följt. Tiden för varje metod kan bestämmas utifrån antalet gånger profilen stoppas i varje metod. Om till exempel 100 prover görs med intervaller på 1 millisekund , och en viss metod visar sig vara högst upp i stacken i 10 prover, kan du dra slutsatsen att ungefär 10% av den totala exekveringstiden - 10 millisekunder - har använts i den metoden. Det är en ganska grov tillnärmning, men det fungerar!

Från Xcode's menyfält väljer du Product\Profile eller press ⌘I . Detta kommer att bygga appen och starta instrument. Du hälsas med ett urvalsfönster som ser ut så här:

Dessa är alla olika mallar som kommer med instrument.

Välj Time Profiler instrumentet och klicka på Välj. Detta öppnar ett nytt instrumentdokument. Klicka på den röda inspelningsknappen längst upp till vänster för att starta inspelningen och starta appen. Du kan bli ombedd för ditt lösenord för att auktorisera Instrument för att analysera andra processer - rädsla inte, det är säkert att tillhandahålla här! I instrumentfönstret kan du se tiden räkna upp och en liten pil flytta från vänster till höger ovanför diagrammet mitt på skärmen. Detta indikerar att appen körs.

Börja nu använda appen. Sök efter några bilder och borr ner till ett eller flera av sökresultaten. Du har antagligen lagt märke till att det är tråkigt långsamt att gå in i ett sökresultat och att rulla igenom en lista med sökresultat är också otroligt irriterande - det är en oerhört klumpig app!

Tja, du har tur, för du är på väg att börja fixa det! Men du kommer först att få en snabb nedgång på vad du tittar på i Instruments . Först bör du se till att väljarknappen på höger sida av verktygsfältet har båda alternativen valda, så:

Det säkerställer att alla paneler är öppna. Studera nu skärmdumpen nedan och förklaringen av varje avsnitt under det:

1. Det här är inspelningskontrollerna . Den röda "post" -knappen kommer att stoppa och starta appen som för närvarande profileras när den klickas (den växlar mellan en post- och stoppikon). Paus-knappen gör exakt vad du kan förvänta dig och pausar den aktuella exekveringen av appen.

2. Detta är körtimern. Timern räknar hur länge appen som profilerats har körts och hur många gånger den har körts. Om du stannar och sedan startar om appen med inspelningskontrollerna skulle det starta en ny körning och displayen visar sedan körning 2 av 2.

3. Detta kallas ett spår. När det gäller den tidsprofilmall du valde finns det bara ett instrument så att det bara finns ett spår. Du lär dig mer om detaljerna i diagrammet som visas här senare i handledning.

4. Det här är detaljpanelen. Den visar huvudinformationen om det specifika instrumentet du använder. I det här fallet visar det de metoder som är "hetaste" - det vill säga de som har använt mest CPU-tid. Om du klickar på fältet högst upp som säger Call Tree (den vänstra) och väljer Exempellista, får du en annan vy av uppgifterna. Den här vyn visar varje prov. Klicka på några prover så ser du det fångade stackspåret visas i inspektören för utökad detalj.

5. Det här är inspektörspanelen. Det finns tre inspektörer: Spela in inställningar, skärminställningar och utökad detalj. Du lär dig mer om några av dessa alternativ inom kort.

Borra djupt

Utför en bildsökning och borra i resultaten. Jag gillar personligen att söka efter "hund", men välj vad du vill - du kanske är en av dessa kattfolk!

Bläddra nu upp och ner i listan några gånger så att du har en bra mängd data i Time Profiler . Du bör märka att siffrorna i mitten av skärmen ändras och att grafen fyller i; detta säger att CPU- cykler används.

Du kan verkligen inte förvänta dig att någon UI ska vara så klumpig eftersom denna ingen table view är redo att skickas tills den rullar som smör! För att hjälpa till att hitta problemet måste du ställa in några alternativ.

På höger sida väljer du skärminställningsinspektören (or press ⌘+2) . I inspektören under Call Tree , välj Åtskilj med tråd, Invert Call Tree , dölja saknade symboler och Hide System bibliotek. Det kommer att se ut så här:

Här är vad varje alternativ gör för data som visas i tabellen till vänster:

Separat med tråd: Varje tråd ska beaktas separat. Detta gör att du kan förstå vilka trådar som är ansvariga för den största mängden CPU- användning.

Invert Call Tree: Med det här alternativet, den stack trace anses från topp till botten. Detta är vanligtvis vad du vill, eftersom du vill se de djupaste metoderna där CPU: n spenderar sin tid.

Dölj saknade symboler: Om dSYM filen inte kan hittas för din app eller ett system framework , istället för att se metodnamn (symboler) i tabellen ser du bara hexvärden som motsvarar adresser i binären. Om detta alternativ är valt visas bara helt upplösta symboler och de olösta hexvärdena döljs. Detta hjälper till att decluttera de presenterade uppgifterna.

Dölj systembibliotek: När det här alternativet är valt visas bara symboler från din egen app. Det är ofta användbart att välja det här alternativet, eftersom du vanligtvis bara bryr dig om var CPU tillbringar tid i din egen kod - du kan inte göra mycket åt hur mycket CPU system libraries använder!

Flatten rekursion: Det här alternativet behandlar rekursiva funktioner (de som kallar sig) som en post i varje stack trace , snarare än multipel.

Toppfunktioner: Genom att aktivera detta får Instruments betrakta den totala tiden som används i en funktion som summan av tiden direkt inom den funktionen, liksom den tid som spenderas i funktioner som kallas av den funktionen.

Så om funktion A anropar B, rapporteras A: s tid som den tid som spenderas i A PLUS tiden tillbringad i B. Detta kan vara riktigt användbart, eftersom det låter dig välja den största tidssiffran varje gång du går ner i samtalstacken och nollar på dina mest tidskrävande metoder.

Om du kör en Objective-C app finns det också ett alternativ för Visa endast Obj-C : Om detta är valt visas bara Objective-C metoder snarare än alla C eller C++ -funktioner. Det finns inga i ditt program, men om du tittade på en OpenGL app kan det till exempel ha C++ .

Även om vissa värden kan vara något annorlunda, bör postens ordning likna tabellen nedan när du har aktiverat alternativen ovan:

Det ser verkligen inte så bra ut. Den stora majoriteten av tiden tillbringas i metoden som tillämpar "tonal" -filtret på miniatyrbilderna. Det borde inte bli så mycket chockerande för dig, eftersom tabellbelastningen och rullningen var de klumpigaste delarna av UI, och det är när tabellcellerna ständigt uppdateras.

För att ta reda på mer om vad som händer inom den metoden, dubbelklicka på raden i tabellen. Om du gör det får du följande vy:

Det är väl intressant, eller hur! applyTonalFilter() är en metod som läggs till UIImage i en förlängning, och nästan 100 % av den tid som spenderas på den spenderas för att skapa CGImage-utgången efter tillämpning av bildfiltret.

Det finns inte riktigt mycket som kan göras för att påskynda detta: att skapa bilden är en ganska intensiv process och tar så lång tid som det tar. Låt oss försöka gå tillbaka och se var applyTonalFilter() heter från. Klicka på Call Tree i brödkorsspåret längst upp i kodvyn för att komma tillbaka till föregående skärm:

Klicka nu på den lilla pilen till vänster om ApplyTonalFilter-raden längst upp i tabellen. Detta öppnar samtalsträdet för att visa den som ringer till ApplyTonalFilter. Du kanske måste utveckla nästa rad också; vid profilering av Swift kommer det ibland att vara duplicerade rader i samtalsträdet, förinställt med @objc. Du är intresserad av den första raden som är förinställd med appens målnamn (InstrumentsTutorial):

I det här fallet hänvisar denna rad till resultatsamlingsvyens cellForItemAtIndexPath . Dubbelklicka på raden för att se den tillhörande koden från projektet.

Nu kan du se vad problemet är. Metoden för att tillämpa tonfiltret tar lång tid att köra, och det kallas direkt från cellForItemAtIndexPath, vilket kommer att blockera main thread (och därför hela användargränssnittet) varje gång det begär en filtrerad bild.

Avsättningar

Det finns detaljerad information om alla objekt som skapas och minnet som stöder dem; det visar också att du retain counts för varje objekt. För att börja om igen med en ny instruments profile , avsluta appen Instruments. Den här gången, bygga och köra appen och öppna Debug Navigator i området Navigators. Klicka sedan på Minne för att visa grafer över minnesanvändning i huvudfönstret:

Dessa diagram är användbara för att få en snabb uppfattning om hur din app presterar. Men du kommer att behöva lite mer kraft. Klicka Profile in Instruments knappen Profile in Instruments och sedan på Överför för att få den här sessionen till instrument . Tilldelningsinstrumentet startar automatiskt.

Den här gången kommer du att märka två spår. En kallas allokeringar och en kallas läckor. Tilldelningsspåret kommer att diskuteras i detalj senare; Leaks-spåret är i allmänhet mer användbart i Objekt-C och kommer inte att behandlas i den här handledning. Så vilket fel ska du spåra nästa? Det finns något gömt i projektet som du antagligen inte vet finns där. Du har antagligen hört talas om minnesläckor. Men vad du kanske inte vet är att det faktiskt finns två typer av läckor:

Sanna minnesläckor är där ett objekt inte längre hänvisas till av något men ändå tilldelas - det betyder att minnet aldrig kan återanvändas. Även med Swift och ARC hjälper till att hantera minne, är den vanligaste typen av minnesläcka en retain cycle or strong reference cycle . Detta är när två objekt har starka referenser till varandra, så att varje objekt håller det andra från att omlokaliseras. Detta innebär att deras minne aldrig släpps!

Obegränsad minnetillväxt är där minnet fortsätter att tilldelas och ges aldrig en chans att omlokaliseras . Om detta fortsätter för evigt system's memory att fyllas på någon gång och du har ett stort minnesproblem på dina händer. I iOS betyder det att appen kommer att dödas av systemet.

Med tilldelningsinstrumentet som körs på appen gör du fem olika sökningar i appen men borrar inte ner i resultaten än. Se till att sökningarna har några resultat! Låt nu appen lösa sig lite genom att vänta några sekunder.

Du borde ha märkt att grafen i tilldelningsspåret har stigit. Detta säger att minnet tilldelas. Det är den här funktionen som hjälper dig att hitta unbounded memory growth .

Det du ska utföra är en generation analysis . För att göra detta, tryck på knappen som heter Mark Generation. Du hittar knappen längst upp i inspektören för skärminställningar:

Tryck på den så ser du en röd flagga i spåret, som så:

Syftet med generation analysis är att utföra en åtgärd flera gånger och se om minnet växer på unbounded fashion . Borra i en sökning, vänta några sekunder tills bilderna laddas och gå sedan tillbaka till startsidan. Markera sedan generationen igen. Gör detta upprepade gånger för olika sökningar. Efter en borrning i några sökningar kommer instrument att se ut så här:

Vid denna punkt bör du bli misstänksam. Lägg märke till hur den blå grafen går upp med varje sökning du borrar in i. Det är verkligen inte bra. Men vänta, hur är det med memory warnings? Du vet om dessa, eller hur? Memory warnings är iOS: s sätt att berätta för en app att saker och ting blir hårdare i minnesavdelningen och att du måste rensa ut lite minne.

Det är möjligt att denna tillväxt inte bara beror på din app; Det kan vara något i UIKit djup som håller fast vid minnet. Ge systemramarna och din app en chans att rensa minnet först innan du pekar ett finger mot endera.

Simulera en memory warning genom att välja Instrument\Simulate Memory Warning i instrumentfältets menyraden, eller Hardware\Simulate Memory Warning från simulator's menyfält. Du kommer att märka att minnesanvändningen sjunker lite, eller kanske inte alls. Visst inte tillbaka till var den borde vara. Så det finns fortfarande obegränsad minneutveckling någonstans.

Anledningen till att markera en generation efter varje iteration av borrning i en sökning är att du kan se vilket minne som har tilldelats mellan varje generation. Titta i detaljpanelen så ser du ett gäng generationer.