Plánování výkonu

Uživatelé očekávají, že jejich aplikace zůstanou responzivní, budou cítit přirozeně a nebudou vyprázdnit baterii. Technicky vzato je výkon nefunkčním požadavkem, ale zacházení s výkonem jako funkce vám pomůže zajistit očekávání vašich uživatelů. Určení cílů a měření jsou klíčové faktory. Určete, jaké jsou vaše scénáře kritické pro výkon; definovat, co je dobrý výkon. Pak v průběhu životního cyklu projektu změřte časně a často, abyste měli jistotu, že dosáhnete svých cílů.

Určení cílů

Uživatelské prostředí představuje základní způsob definování dobrého výkonu. Čas spuštění aplikace může ovlivnit vnímání jeho výkonu uživatelem. Uživatel může považovat dobu spuštění aplikace kratší než jednu sekundu za vynikající, méně než 5 sekund za dobrou a více než 5 sekund za špatnou.

Jiné metriky mají méně zřetelný dopad na uživatelské prostředí, například paměť. Pravděpodobnost, že aplikace bude ukončena, zatímco je pozastavená nebo nečinná, roste s množstvím paměti používané aktivní aplikací. Obecně platí, že vysoké využití paměti zhoršuje zážitek ze všech aplikací v systému, takže je rozumné mít cíl na spotřebu paměti. Vezměte v úvahu hrubou velikost vaší aplikace, jak ji vnímají uživatelé: malá, střední nebo velká. Očekávání ohledně výkonu budou korelovat s tímto vnímáním. Můžete například chtít, aby malá aplikace, která nepoužívá velké množství médií, spotřebovává méně než 100 MB paměti.

Je lepší nastavit počáteční cíl a pak ho později upravit, než nemít vůbec žádný cíl. Výkonnostní cíle vaší aplikace by měly být specifické a měřitelné a měly by se spadat do tří kategorií: jak dlouho trvá, než uživatelé nebo aplikace dokončí úkoly (čas). rychlost a kontinuita, se kterou se aplikace překresluje v reakci na interakci uživatele (fluidita); a jak dobře aplikace šetří systémové prostředky, včetně energie baterie (účinnosti).

Čas

Představte si přijatelné rozsahy uplynulého času (tříd interakce), které uživatelům zabere dokončení úkolů ve vaší aplikaci. Pro každou třídu interakce přiřaďte popisek, vnímané mínění uživatelů a ideální a maximální dobu trvání. Tady je několik návrhů.

Popisek interakční třídy	Vnímání uživatelů	Ideál	Maximálně	Příklady
Rychlé	Minimální znatelné zpoždění	100 milisekund	200 milisekund	Vyvolání panelu aplikace; stiskněte tlačítko (první odpověď)
Typický	Rychlé, ale ne rychlé	300 milisekund	500 milisekund	Změnit velikost; sémantické přiblížení
Citlivý	Není rychlé, ale působí svižně	500 milisekund	1 sekunda	Přejděte na jinou stránku; obnovení aplikace z pozastaveného stavu
Zahájení	Konkurenční prostředí	1 sekunda	3 sekundy	Spusťte aplikaci poprvé nebo po jejím ukončení.
Nepřetržité	Už se necítí responzivní	500 milisekund	5 sekund	Stažení souboru z internetu
Zajatec	Dlouhý; uživatel by se mohl přepnout jinam	500 milisekund	10 sekund	Instalace více aplikací ze Storu

 

Třídy interakce teď můžete přiřadit ke scénářům výkonu vaší aplikace. Každému scénáři můžete přiřadit referenční informace k určitému bodu v čase, část uživatelského prostředí a třídu interakce. Tady je několik návrhů pro ukázkovou aplikaci pro jídlo a stravování.

Scénář	Časový bod	Uživatelské prostředí	Třída interakce
Přechod na stránku receptu	První odpověď	Animace přechodu stránky byla spuštěna.	Rychlé (100–200 milisekund)
	Citlivý	Seznam složek načten, obrázky nejsou k dispozici	Responzivní (500 milisekund - 1 sekunda)
	Viditelně úplné	Veškerý obsah je načten; Obrázky jsou zobrazené	Nepřetržitý (500 milisekund – 5 sekund)
Hledání receptu	První odpověď	Kliknutí na tlačítko Hledat	Rychlé (100 - 200 milisekund)
	Viditelně úplné	Seznam zobrazených místních názvů receptů	Typické (300 - 500 milisekund)

Pokud zobrazujete živý obsah, zvažte také cíle aktuálnosti obsahu. Je cílem aktualizovat obsah každých několik sekund? Nebo je aktualizace obsahu každých několik minut, každých několik hodin nebo dokonce jednou denně přijatelná uživatelská zkušenost?

Díky zadaným cílům teď můžete lépe testovat, analyzovat a optimalizovat aplikaci.

Fluidita

Mezi konkrétní měřitelné cíle plynulosti pro vaši aplikaci můžou patřit:

• Bez přerušení při překreslení obrazovky, bez závad.
• Animace se vykreslují s 60 snímky za sekundu (FPS).
• Když uživatel posouvá nebo rolováním, aplikace zobrazí 3 až 6 stránek obsahu za sekundu.

Efektivita

Mezi měřitelné cíle efektivity vaší aplikace můžou patřit:

• Pro proces vaší aplikace je procento využití procesoru vždy N nebo nižší a využití paměti v megabajtech je vždy M nebo nižší.
• Když je aplikace neaktivní, N a M jsou pro proces aplikace nula.
• Aplikaci můžete používat aktivně po dobu X hodin na baterii; když je vaše aplikace neaktivní, zařízení si uchová nabíjení po dobu Y hodin.

Návrh aplikace pro zvýšení výkonu

Teď můžete využít výkonnostní cíle k ovlivnění návrhu vaší aplikace. Při použití příkladu aplikace pro jídlo a stravování se po přechodu uživatele na stránku receptu můžete rozhodnout přírůstkově aktualizovat položky tak, že se nejprve vykreslí název receptu, poté se odloží zobrazení ingrediencí a zobrazení obrázků se odloží ještě více. Tím se udržuje rychlost odezvy a plynulé uživatelské rozhraní při posunu/rolování, přičemž vykreslování s plnou věrností probíhá poté, co se interakce zpomalí na rychlost, která umožní vláknu uživatelského rozhraní dohnat. Tady jsou některé další aspekty, které je potřeba vzít v úvahu.

uživatelské rozhraní

• Maximalizujte dobu analýzy a načítání a efektivitu paměti pro každou stránku uživatelského rozhraní vaší aplikace (zejména počáteční stránku) optimalizaci kódu XAML. Stručně řečeno, odložte načítání uživatelského rozhraní a kódu, dokud to nebude potřeba.
• Pro ListView a GridViewnastavte všechny položky na stejnou velikost a aplikujte co nejvíce technik optimalizace pro ListView a GridView .
• Deklarujte uživatelské rozhraní ve formě značek, které může framework načíst a znovu použít v blocích, namísto sestavení imperativně v kódu.
• Pozdržte vytváření prvků uživatelského rozhraní, dokud je uživatel nepotřebuje. Viz atribut x:Load .
• Upřednostněte přechody a animace motivů před animacemi ve scénářích. Další informace najdete v tématu Přehled animací. Mějte na paměti, že animace se storyboardem vyžadují konstantní aktualizace obrazovky a udržují procesorový a grafický proces aktivní. Pokud chcete zachovat baterii, nemáte spuštěné animace, pokud uživatel s aplikací nekomuaguje.
• Obrázky, které načtete, by se měly načíst s velikostí, která je vhodná pro zobrazení, ve kterém ho prezentujete, pomocí metody GetThumbnailAsync .

CPU, paměti a napájení

• Naplánujte práci s nižší prioritou tak, aby běžela na vláknech s nižší prioritou nebo jádrech. Viz asynchronní programování, vlastnost Dispatcher a třída CoreDispatcher.
• Minimalizujte nároky na paměť vaší aplikace uvolněním drahých prostředků (například médií) při pozastavení.
• Minimalizujte pracovní sadu kódu.
• Vyhněte se únikům paměti zrušením registrace obslužných rutin událostí a dereferencováním prvků uživatelského rozhraní, kdykoli je to možné.
• Kvůli šetření baterie buďte konzervativní v tom, jak často načítáte data, dotazujete se senzoru nebo naplánujete práci na procesoru, když je nečinný.

Přístup k datům

• Pokud je to možné, předem načtěte obsah. Informace o automatickém předběžném načítání naleznete ve třídě ContentPrefetcher. Pro ruční předběžné načítání, podívejte se do oboru názvů Windows.ApplicationModel.Background a do třídy MaintenanceTrigger.
• Pokud je to možné, ukládejte do mezipaměti obsah, který je nákladný pro přístup. Podívejte se na vlastnosti LocalFolder a LocalSettings.
• V případě chybějících uložených dat v mezipaměti co nejrychleji zobrazte zástupné uživatelské rozhraní, které značí, že aplikace stále načítá obsah. Přecházejte od zástupného symbolu k živému obsahu tak, aby to pro uživatele nebylo rušivé. Například neměňte umístění obsahu pod prstem nebo ukazatelem myši uživatele, protože aplikace načítá živý obsah.

Spuštění a obnovení aplikace

• Odložte úvodní obrazovku aplikace a neposouvejte úvodní obrazovku aplikace, pokud to není nutné. Podrobnosti najdete v tématu Vytvoření rychlého a plynulého zážitku ze spouštění aplikací a Zobrazení úvodní obrazovky na delší dobu.
• Zakažte animace, ke kterým dochází okamžitě po zavření úvodní obrazovky, protože to povede pouze ke zpoždění při spuštění aplikace.

Adaptivní uživatelské rozhraní a orientace

• Použijte Třídu VisualStateManager .
• Okamžitě dokončete pouze požadovanou práci, náročnou práci aplikace odložte až na později – vaše aplikace má 200 až 800 milisekund na dokončení práce, než se uživatelské rozhraní aplikace zobrazí v oříznutém stavu.

S využitím návrhů souvisejících s výkonem můžete začít programovat aplikaci.

Nástroj pro výkon

Při psaní kódu přidejte kód, který během spouštění aplikace protokoluje zprávy a události v určitých bodech. Později při testování aplikace můžete k vytvoření a zobrazení sestavy o výkonu vaší aplikace použít nástroje pro profilaci, jako je Windows Performance Recorder a Windows Performance Analyzer (obojí je součástí sady nástrojů Windows Performance Toolkit). V této sestavě můžete tyto zprávy a události vyhledat, abyste snadněji analyzovali výsledky sestavy.

Univerzální platforma Windows (UWP) poskytuje rozhraní API pro záznam, která jsou podporována trasováním událostí pro Windows (ETW)a společně nabízejí bohaté řešení pro záznam a sledování událostí. Rozhraní API, která jsou součástí oboru názvů Windows.Foundation.Diagnostics, zahrnujíFileLoggingSession , LoggingActivity, LoggingChannela třídy LoggingSession.

Pokud chcete v sestavě protokolovat zprávu v určitém okamžiku, když je aplikace spuštěná, vytvořte objekt typu LoggingChannel a poté zavolejte jeho metodu LogMessage, následujícím způsobem.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

Pokud chcete v sestavě během běhu aplikace protokolovat události spuštění a zastavení, vytvořte LoggingActivity objekt a potom zavolejte konstruktor LoggingActivity tohoto objektu.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

Také se podívejte na ukázku protokolování .

Pomocí instrumentované aplikace můžete otestovat a změřit výkon aplikace.

Testování a měření ve vztahu k cílům výkonu

Součástí plánu výkonu je definování bodů během vývoje, kde budete měřit výkon. Slouží k různým účelům v závislosti na tom, jestli měříte během vytváření prototypů, vývoje nebo nasazení. Měření výkonu v počátečních fázích vytváření prototypů může být nesmírně cenné, proto doporučujeme, abyste to udělali, jakmile máte kód, který dělá smysluplnou práci. Časná měření vám poskytnou dobrou představu o tom, kde jsou důležité náklady ve vaší aplikaci, a informují rozhodnutí o návrhu. Výsledkem je vysoký výkon a škálování aplikací. Obecně je nákladné změnit návrhy později než dříve. Měření výkonu v pozdním období cyklu produktu může způsobit hacky za poslední minutu a nízký výkon.

Pomocí těchto technik a nástrojů otestujte, jak si vaše aplikace stojí v porovnání s původními cíli výkonu.

• Otestujte si širokou škálu konfigurací hardwaru, včetně univerzálních a stolních počítačů, notebooků, ultrabooků a tabletů a dalších mobilních zařízení.
• Testujte na široké škále velikostí obrazovky. I když širší velikosti obrazovky můžou zobrazovat mnohem více obsahu, může to mít negativní vliv na výkon.
• Eliminujte tolik testovacích proměnných, kolik můžete.
  • Vypněte aplikace na pozadí na testovacím zařízení. Uděláte to tak, že v systému Windows vyberete Nastavení z nabídky Start >Přizpůsobení>Zamykací obrazovka. Vyberte každou aktivní aplikaci a vyberte Žádné.
  • Před nasazením aplikace do testovacího zařízení ji zkompilujte do nativního kódu tak, že ji sestavíte v konfiguraci vydané verze.
  • Pokud chcete zajistit, aby automatická údržba neměla vliv na výkon testovacího zařízení, aktivujte ji ručně a počkejte na dokončení. Ve Windows v nabídce Start vyhledejte Zabezpečení a Údržbu. V oblasti Údržba v části Automatická údržbavyberte Spustit údržbu a počkejte, až se stav změní z Probíhá údržba.
  • Spusťte aplikaci několikrát, abyste eliminovali náhodné testovací proměnné a zajistili konzistentní měření.
• Otestujte nižší dostupnost napájení. Zařízení uživatelů může mít výrazně menší výkon než váš vývojový počítač. Systém Windows byl navržen s ohledem na zařízení s nízkým výkonem, jako jsou mobilní zařízení. Aplikace, které běží na platformě, by měly zajistit, aby na těchto zařízeních dobře fungovaly. Jako heuristické počítejte s tím, že zařízení s nízkým výkonem běží přibližně ve čtvrtině rychlosti stolního počítače a odpovídajícím způsobem nastavuje vaše cíle.
• Pomocí kombinace nástrojů, jako je Microsoft Visual Studio a Windows Performance Analyzer, můžete měřit výkon aplikací. Visual Studio je navržené tak, aby poskytovalo analýzu zaměřenou na aplikaci, jako je propojení zdrojového kódu. Windows Performance Analyzer je navržený tak, aby poskytoval analýzu zaměřenou na systém, jako je poskytování systémových informací, informací o událostech manipulace s dotykovým ovládáním a informace o nákladech na vstup/výstup disku (V/V) a grafický procesor (GPU). Oba nástroje poskytují zachytávání a export trasování a mohou znovu otevřít sdílené a následné trasování.
• Před odesláním aplikace do Obchodu k certifikaci nezapomeňte začlenit do testovacích plánů testovací případy související s výkonem, jak je popsáno v části "Testy výkonnosti" testů sady Windows App Certification Kit a v části "Výkon a stabilita" testovacích případů pro UWP aplikace .

Další informace najdete v těchto zdrojích informací a nástrojích pro profilaci.

• Nástroj pro analýzu výkonu Windows
• Windows Performance Toolkit
• Analýza výkonu pomocí diagnostických nástrojů sady Visual Studio
• Výkon XAML na sezení //build/
• Sezení //build/ Nové nástroje pro XAML v sadě Visual Studio 2015

Reakce na výsledky testu výkonnosti

Po analýze výsledků testu výkonnosti určete, jestli jsou potřeba nějaké změny, například:

• Měli byste změnit některá rozhodnutí o návrhu aplikace nebo optimalizovat kód?
• Měli byste do kódu přidat, odebrat nebo změnit nějakou instrumentaci?
• Měli byste zrevidovat některé z vašich výkonnostních cílů?

Pokud jsou potřeba nějaké změny, proveďte je a pak se vraťte k instrumentaci nebo testování a zopakování.

Optimalizace

Optimalizujte v aplikaci jenom cesty ke kódu kritickému pro výkon: ty, ve kterých se tráví nejvíce času. Profilace vám řekne, která. Často existuje kompromis mezi vytvořením softwaru, který dodržuje osvědčené postupy návrhu a psaní kódu, který se provádí při nejvyšší optimalizaci. Obecně je lepší určit prioritu produktivity vývojářů a dobrého návrhu softwaru v oblastech, kde výkon není problém.