Komponenty prostředí Windows Runtime a optimalizace spolupráce

Vytvářejte aplikace pro Windows, které používají komponenty Windows Runtime a zajišťují spolupráci mezi nativními a spravovanými typy, a zároveň se vyhýbejte problémům s výkonem této spolupráce.

Osvědčené postupy pro interoperabilitu s komponentami prostředí Windows Runtime

Pokud nejste opatrní, může použití komponent prostředí Windows Runtime mít velký vliv na výkon vaší aplikace. Tato část popisuje, jak získat dobrý výkon, když vaše aplikace používá komponenty prostředí Windows Runtime.

Úvod

Interoperabilita může mít velký dopad na výkon a možná ji používáte, aniž byste si uvědomili, že jste. Prostředí Windows Runtime za vás zpracovává spoustu interoperability, abyste mohli být produktivnější a opakovaně používat kód napsaný v jiných jazycích. Doporučujeme vám využít výhod toho, co pro vás prostředí Windows Runtime dělá, ale mějte na paměti, že to může mít vliv na výkon. Tato část popisuje, co můžete udělat, abyste snížili dopad, který má interoperabilita na výkon vaší aplikace.

Modul Windows Runtime má knihovnu typů, které jsou přístupné z libovolného jazyka, který může psát aplikaci univerzální platformy Windows. Typy prostředí Windows Runtime používáte v jazyce C# nebo Microsoft Visual Basic stejným způsobem jako objekty .NET. Pro přístup k komponentám prostředí Windows Runtime není nutné volat metodu volání platformy. Díky tomu je psaní aplikací mnohem složitější, ale je důležité si uvědomit, že může docházet k větší interoperabilitě, než očekáváte. Pokud je komponenta Prostředí Windows Runtime napsaná v jiném jazyce než C# nebo Visual Basic, protínáte hranice interoperability při použití této komponenty. Překročení hranic interoperability může mít vliv na výkon aplikace.

Při vývoji aplikace pro univerzální platformu Windows v jazyce C# nebo Visual Basic jsou dvěma nejběžnějšími sadami rozhraní API, která používáte, rozhraní API prostředí Windows Runtime a rozhraní .NET API pro aplikace pro UPW. Obecně platí, že typy poskytované systémem Windows, které jsou založené na prostředí Windows Runtime v oborech názvů, které začínají na "Windows" a typy .NET, jsou v oborech názvů, které začínají na "Systém". Existují však výjimky. Typy v .NET pro aplikace pro UPW nevyžadují při jejich použití interoperabilitu. Pokud zjistíte, že máte špatný výkon v oblasti, která používá prostředí Windows Runtime, můžete místo toho použít .NET pro aplikace pro UPW, abyste dosáhli lepšího výkonu.

Poznámka Většina komponent prostředí Windows Runtime, které jsou dodávány s Windows 10, jsou implementovány v jazyce C++, takže při jejich použití z jazyka C# nebo Visual Basic protínáte hranice interoperability. Jako vždy se ujistěte, že měřením aplikace zjistíte, jestli použití komponent prostředí Windows Runtime ovlivňuje výkon vaší aplikace, než začnete investovat do provádění změn kódu.

Když v tomto tématu zmíníme "Součásti prostředí Windows Runtime", znamenáme komponenty prostředí Windows Runtime, které jsou napsané v jiném jazyce než C# nebo Visual Basic.

 

Při každém přístupu k vlastnosti nebo volání metody v komponentě Windows Runtime se účtují náklady na interoperabilitu. Vytvoření komponenty prostředí Windows Runtime je ve skutečnosti nákladnější než vytvoření objektu .NET. Důvodem je, že modul Windows Runtime musí spouštět kód, který přechází z jazyka vaší aplikace do jazyka komponenty. Pokud také předáte data komponentě, musí být data převedena mezi spravovanými a nespravovanými typy.

Efektivní používání komponent prostředí Windows Runtime

Pokud zjistíte, že potřebujete dosáhnout lepšího výkonu, můžete zajistit, aby váš kód co nejefektivněji používal komponenty prostředí Windows Runtime. Tato část popisuje některé tipy pro zvýšení výkonu při použití komponent prostředí Windows Runtime.

Vyžaduje velký počet volání v krátkém časovém období, aby byl dopad na výkon znatelný. Dobře navržená aplikace, která zapouzdřuje volání komponent prostředí Windows Runtime z obchodní logiky a jiného spravovaného kódu, by neměla způsobovat obrovské náklady na interoperabilitu. Pokud ale vaše testy naznačují, že použití komponent prostředí Windows Runtime ovlivňuje výkon vaší aplikace, tipy probírané v této části vám pomůžou zlepšit výkon.

Zvažte použití typů poskytovaných rozhraním .NET pro aplikace pro UPW.

Existují určité případy, kdy můžete úlohu provést pomocí typu prostředí Windows Runtime nebo typu, který poskytuje .NET pro aplikace pro UPW. Je vhodné se pokusit nemíchat typy .NET a typy prostředí Windows Runtime. Zkuste zůstat v jednom nebo druhém. Stream xml můžete například analyzovat pomocí typu Windows.Data.Xml.Dom.XmlDocument (typ Prostředí Windows Runtime) nebo System.Xml.XmlReader (typ .NET). Použijte rozhraní API, které je ze stejné technologie jako stream. Pokud například načtete xml z MemoryStream, použijte typ System.Xml.XmlReader , protože oba typy jsou typy .NET. Pokud čtete ze souboru, použijte typ Windows.Data.Xml.Dom.XmlDocument , protože rozhraní API souborů a XmlDocument jsou implementovány v nativních komponentách prostředí Windows Runtime.

Kopírování objektů Windows Runtime do typů .NET

Když komponenta prostředí Windows Runtime vrátí objekt prostředí Windows Runtime, může být výhodné zkopírovat vrácený objekt do objektu .NET. Dvě místa, kde je to zvlášť důležité, je, když pracujete s kolekcemi a streamy.

Pokud zavoláte rozhraní API prostředí Windows Runtime, které vrací kolekci, a pak tuto kolekci často ukládáte a přistupujete k ní, může být užitečné kolekci zkopírovat do kolekce .NET a potom použít verzi .NET.

Ukládání výsledků volání komponent prostředí Windows Runtime do mezipaměti pro pozdější použití

Možná budete moct dosáhnout lepšího výkonu tím, že hodnoty uložíte do místních proměnných místo toho, abyste vícekrát přistupovali k typu prostředí Windows Runtime. To může být zvlášť výhodné, pokud použijete hodnotu uvnitř smyčky. Změřte aplikaci, abyste zjistili, jestli použití místních proměnných zlepšuje výkon vaší aplikace. Používání hodnot uložených v mezipaměti může zvýšit rychlost aplikace, protože bude trávit méně času na interoperabilitě.

Kombinování volání komponent prostředí Windows Runtime

Zkuste dokončit úkoly s co nejmenším počtem volání objektů UPW. Obvykle je například lepší číst velké množství dat z datového proudu než číst malé množství najednou.

Používejte rozhraní API, která seskupují práci do co nejmenšího počtu volání, místo rozhraní API, která provádějí méně práce a vyžadují více volání. Například raději vytvořit objekt voláním konstruktorů, které inicializují více vlastností jednou místo volání výchozí konstruktor a přiřazování vlastností po jednom.

Sestavení komponent prostředí Windows Runtime

Pokud napíšete komponentu prostředí Windows Runtime, kterou můžou používat aplikace napsané v jazyce C++ nebo JavaScript, ujistěte se, že je vaše komponenta navržená pro dobrý výkon. Všechny návrhy pro získání dobrého výkonu v aplikacích platí pro získání dobrého výkonu v komponentách. Změřte komponentu, abyste zjistili, která rozhraní API mají vzorce vysokého provozu a pro tyto oblasti, zvažte poskytování rozhraní API, která uživatelům umožňují pracovat s několika voláními.

Udržujte svou aplikaci rychlou při použití mezioperační komunikace ve spravovaném kódu.

Prostředí Windows Runtime usnadňuje spolupráci mezi nativním a spravovaným kódem, ale pokud si nejste opatrní, můžou vám vzniknout náklady na výkon. Tady vám ukážeme, jak dosáhnout dobrého výkonu při používání zprostředkovatele komunikace ve spravovaných aplikacích pro UPW.

Windows Runtime umožňuje vývojářům psát aplikace v jazyce podle svého výběru pomocí XAML díky projekcím rozhraní API Windows Runtime dostupným v každém jazyce. Při psaní aplikace v jazyce C# nebo Visual Basic má toto pohodlí své náklady v oblasti interoperability, protože rozhraní API prostředí Windows Runtime jsou obvykle implementována v nativním kódu a každé volání rozhraní Windows Runtime z jazyka C# nebo Visual Basic vyžaduje, aby CLR přecházel ze spravovaného do nativního rámce zásobníku a aby se parametry funkcí zprostředkovaly do podoby, kterou nativní kód rozumí. Tyto náklady jsou pro většinu aplikací zanedbatelné. Když ale v kritické cestě aplikace provedete mnoho volání (stovky tisíc až miliony) do rozhraní API prostředí Windows Runtime, můžou se tyto náklady projevit. Obecně chcete zajistit, aby čas strávený při přechodu mezi jazyky byl malý vzhledem ke spuštění zbytku kódu. To je znázorněno následujícím diagramem.

Typy uvedené v .NET pro aplikace pro Windows neúčtují tyto náklady na interoperabilitu při použití z C# nebo Visual Basicu. Obecně vzato můžete předpokládat, že typy v oborech názvů, které začínají na «Windows». jsou součástí rozhraní API prostředí Windows Runtime poskytovaného systémem Windows a typy v oborech názvů, které začínají na "System". jsou typy .NET. Mějte na paměti, že i jednoduché použití typů rozhraní Windows Runtime způsobuje náklady spojené s interoperabilitou při přidělování nebo přístupu k vlastnostem.

Před optimalizací nákladů na interoperabilitu byste měli změřit výkon vaší aplikace a určit, zda interop zabírá velkou část celkové doby vykonávání aplikace. Při analýze výkonu aplikace pomocí sady Visual Studio můžete snadno získat horní mez nákladů na interoperabilitu pomocí zobrazení Functions a pozorováním doby zahrnuté v metodách, které volají Windows Runtime.

Pokud je vaše aplikace pomalá kvůli režijním nákladům interoperability, můžete zlepšit její výkon snížením počtu volání rozhraní API prostředí Windows Runtime na kritických cestách kódu. Například herní stroj, který provádí spoustu fyzikálních výpočtů tím, že neustále dotazuje pozici a rozměry UIElements , může ušetřit spoustu času uložením potřebných informací z UIElements do místních proměnných, prováděním výpočtů na těchto hodnotách uložených v mezipaměti a přiřazením koncového výsledku zpět k UIElements po dokončení výpočtů. Další příklad: Pokud je kolekce silně přístupná kódem jazyka C# nebo Visual Basic, je efektivnější použít kolekci z oboru názvů System.Collections , a ne kolekci z oboru názvů Windows.Foundation.Collections . Můžete také zvážit kombinování volání komponent prostředí Windows Runtime; Jedním z příkladů, kde je to možné, je použití rozhraní API Windows.Storage.BulkAccess .

Sestavení komponenty UWP

Pokud napíšete komponentu prostředí Windows Runtime pro použití v aplikacích napsaných v C++ nebo JavaScriptu, ujistěte se, že je vaše komponenta navržená pro dobrý výkon. Vaše rozhraní API definuje hranici interoperability a určuje, do jaké míry budou vaši uživatelé muset zohlednit pokyny v tomto tématu. Pokud komponenty distribuujete ostatním stranám, stane se to zvlášť důležité.

Všechny návrhy pro získání dobrého výkonu v aplikacích platí pro získání dobrého výkonu v komponentách. Změřte komponentu, abyste zjistili, která rozhraní API mají vysoký provoz, a u těchto oblastí zvažte poskytování rozhraní API, která uživatelům umožňují pracovat s několika voláními. Do konstrukce prostředí Windows Runtime bylo vloženo značné úsilí, aby aplikace mohly pracovat bez nutnosti častého překračování hranice interoperability.