Windows Runtime-komponenter och optimering av interop

Skapa Windows-appar som använder Windows Runtime-komponenter och interop mellan interna och hanterade typer samtidigt som du undviker prestandaproblem med interop.

Metodtips för samverkan med Windows Runtime-komponenter

Om du inte är försiktig kan användning av Windows Runtime-komponenter ha stor inverkan på appens prestanda. I det här avsnittet beskrivs hur du får bra prestanda när din app använder Windows Runtime-komponenter.

Inledning

Samverkan kan ha stor inverkan på prestanda och du kanske använder den utan att ens inse att du är det. Windows Runtime hanterar mycket av samverkan åt dig så att du kan vara mer produktiv och återanvända kod som skrivits på andra språk. Vi rekommenderar att du drar nytta av vad Windows Runtime gör åt dig, men tänk på att det kan påverka prestanda. I det här avsnittet beskrivs saker du kan göra för att minska den inverkan som samverkan har på appens prestanda.

Windows Runtime har ett bibliotek med typer som är tillgängliga från alla språk som kan skriva en Universell Windows-plattformsapp. Du använder Windows Runtime-typerna i C# eller Microsoft Visual Basic på samma sätt som du använder .NET-objekt. Du behöver inte anropa metodanrop för plattform för att få åtkomst till Windows Runtime-komponenterna. Detta gör det mycket mindre komplicerat att skriva dina appar, men det är viktigt att inse att det kan uppstå mer samverkan än förväntat. Om en Windows Runtime-komponent är skriven på ett annat språk än C# eller Visual Basic, korsar du samverkansgränser när du använder komponenten. Att korsa samverkansgränser kan påverka prestandan för en app.

När du utvecklar en Universell Windows-plattformsapp i C# eller Visual Basic är de två vanligaste api:erna som du använder Windows Runtime API:er och .NET-API:er för UWP-appar. I allmänhet finns typer som tillhandahålls av Windows som bygger på Windows Runtime i namnområden som börjar med "Windows" och .NET-typer i namnområden som börjar med "System". Det finns dock undantag. Typerna i .NET för UWP-appar kräver inte samverkan när de används. Om du upptäcker att du har dåliga prestanda i ett område som använder sedan Windows Runtime kanske du kan använda .NET för UWP-appar i stället för att få bättre prestanda.

Not De flesta Windows Runtime-komponenter som levereras med Windows 10 implementeras i C++ så att du korsar samverkansgränser när du använder dem från C# eller Visual Basic. Se som alltid till att mäta din app för att se om användning av Windows Runtime-komponenter påverkar appens prestanda innan du investerar i att göra ändringar i koden.

I det här avsnittet, när vi nämner "Windows Runtime-komponenter", menar vi Windows Runtime-komponenter som är skrivna på ett annat språk än C# eller Visual Basic.

 

Varje gång du får åtkomst till en egenskap eller anropar en metod på en Windows Runtime-komponent uppstår en samverkanskostnad. Det är faktiskt dyrare att skapa en Windows Runtime-komponent än att skapa ett .NET-objekt. Orsaken till detta är att Windows Runtime måste köra kod som övergår från appens språk till komponentens språk. Om du skickar data till komponenten måste data konverteras mellan hanterade och ohanterade typer.

Använda Windows Runtime-komponenter effektivt

Om du upptäcker att du behöver få bättre prestanda kan du se till att koden använder Windows Runtime-komponenter så effektivt som möjligt. I det här avsnittet beskrivs några tips för att förbättra prestanda när du använder Windows Runtime-komponenter.

Det tar ett betydande antal anrop på kort tid för att prestandapåverkan ska märkas. Ett väldesignat program som kapslar in anrop till Windows Runtime-komponenter från affärslogik och annan hanterad kod bör inte medföra enorma samverkanskostnader. Men om dina tester visar att användning av Windows Runtime-komponenter påverkar appens prestanda kan de tips som beskrivs i det här avsnittet hjälpa dig att förbättra prestandan.

Överväg att använda typer som tillhandahålls av .NET för UWP-appar

Det finns vissa fall där du kan utföra en uppgift med hjälp av antingen Windows Runtime-typen eller en typ som tillhandahålls av .NET för UWP-appar. Det är en bra idé att försöka att inte blanda .NET-typer och Windows Runtime-typer. Försök att stanna i det ena eller det andra. Du kan till exempel parsa en xml-dataström med hjälp av typen Windows.Data.Xml.Dom.XmlDocument (en Windows Runtime-typ) eller typen System.Xml.XmlReader (en .NET-typ). Använd DET API som kommer från samma teknik som strömmen. Om du till exempel läser xml från en MemoryStream använder du typen System.Xml.XmlReader eftersom båda typerna är .NET-typer. Om du läser från en fil använder du typen Windows.Data.Xml.Dom.XmlDocument eftersom både fil-API:er och XmlDocument implementeras i inbyggda Windows Runtime-komponenter.

Kopiera Window Runtime-objekt till .NET-typer

När en Windows Runtime-komponent returnerar ett Windows Runtime-objekt kan det vara fördelaktigt att kopiera det returnerade objektet till ett .NET-objekt. Två platser där detta är särskilt viktigt är när du arbetar med samlingar och strömmar.

Om du anropar ett Windows Runtime-API som returnerar en samling och sedan sparar och kommer åt samlingen många gånger kan det vara bra att kopiera samlingen till en .NET-samling och använda .NET-versionen från och med då.

Cachelagra resultat av anrop till Windows Runtime-komponenter för senare användning

Du kanske kan få bättre prestanda genom att spara värden i lokala variabler i stället för att komma åt en Windows Runtime-typ flera gånger. Detta kan vara särskilt fördelaktigt om du använder ett värde inuti en loop. Mät din app för att se om användning av lokala variabler förbättrar appens prestanda. Att använda cachelagrade värden kan öka appens hastighet eftersom den ägnar mindre tid åt samverkan.

Kombinera anrop till Windows Runtime-komponenter

Försök att slutföra uppgifter med minst antal anrop till UWP-objekt som möjligt. Det är till exempel oftast bättre att läsa en stor mängd data från en dataström än att läsa små mängder åt gången.

Använd API:er som paketerar arbete i så få anrop som möjligt, istället för API:er som gör mindre arbete och kräver fler anrop. Du kan till exempel skapa ett objekt genom att anropa konstruktorer som initierar flera egenskaper en gång i stället för att anropa standardkonstruktorn och tilldela egenskaper en i taget.

Skapa en Windows Runtime-komponent

Om du skriver en Windows Runtime-komponent som kan användas av appar som skrivits i C++ eller JavaScript kontrollerar du att komponenten är utformad för bra prestanda. Alla förslag för att få bra prestanda i appar gäller för att få bra prestanda i komponenter. Mät din komponent för att ta reda på vilka API:er som har höga trafikmönster och för dessa områden bör du överväga att tillhandahålla API:er som gör det möjligt för användarna att arbeta med få anrop.

Håll appen snabb när du använder interop i hanterad kod

Windows Runtime gör det enkelt att samverka mellan intern och hanterad kod, men om du inte är försiktig kan det medföra prestandakostnader. Här visar vi hur du får bra prestanda när du använder interop i dina hanterade UWP-appar.

Med Widows Runtime kan utvecklare skriva appar med XAML med valfritt språk tack vare prognoserna för Windows Runtime-API:erna som är tillgängliga på varje språk. När du skriver en app i C# eller Visual Basic kommer den här bekvämligheten till en interopkostnad eftersom Windows Runtime-API:erna vanligtvis implementeras i ursprunglig kod, och alla Windows Runtime-anrop från C# eller Visual Basic kräver att CLR övergår från en hanterad till en ursprunglig stackram och marskera funktionsparametrar till representationer som är tillgängliga för ursprunglig kod. Den här kostnaden är försumbar för de flesta appar. Men när du gör många anrop (hundratusentals till miljoner) till Windows Runtime-API:er i den kritiska vägen för en app kan den här kostnaden bli märkbar. I allmänhet vill du se till att den tid som ägnas åt övergången mellan språk är liten i förhållande till körningen av resten av koden. Detta illustreras av följande diagram.

De typer som anges i .NET för Windows-appar medför inte den här interop-kostnaden när de används från C# eller Visual Basic. Som tumregel kan du anta att typer i namnområden som börjar med "Windows". är en del av Windows Runtime API-uppsättningen som tillhandahålls av Windows och typer i namnområden som börjar med "System". är .NET-typer. Tänk på att även enkel användning av Windows Runtime-typer medför en interopkostnad för allokering eller egenskapsåtkomst.

Du bör mäta din app och avgöra om interop tar upp en stor del av appkörningstiden innan du optimerar dina interop-kostnader. När du analyserar appens prestanda med Visual Studio kan du enkelt få en övre gräns för dina interop-kostnader genom att använda vyn Funktioner och titta på inkluderande tid som ägnas åt metoder som anropar till Windows Runtime.

Om din app är långsam på grund av interop overhead kan du förbättra dess prestanda genom att minska anropen till Windows Runtime-API:er på sökvägar för frekvent kod. Till exempel kan en spelmotor som gör massor av fysikberäkningar genom att ständigt fråga efter position och dimensioner för UIElements spara mycket tid genom att lagra nödvändig information från UIElements till lokala variabler, göra beräkningar på dessa cachelagrade värden och tilldela slutresultatet tillbaka till UIElements när beräkningarna är klara. Ett annat exempel: om en samling ofta används av C# eller Visual Basic-kod är det mer effektivt att använda en samling från System.Collections namnrymd i stället för en samling från Windows.Foundation.Collections namnrymd. Du kan också överväga att kombinera anrop till Windows Runtime-komponenter. Ett exempel där detta är möjligt är med hjälp av API:erna Windows.Storage.BulkAccess .

Skapa en UWP-komponent

Om du skriver en Windows Runtime-komponent för användning i appar som skrivits i C++ eller JavaScript kontrollerar du att komponenten är utformad för bra prestanda. API-ytan definierar din interopgräns och definierar i vilken utsträckning användarna måste tänka på vägledningen i det här avsnittet. Om du distribuerar dina komponenter till andra parter blir detta särskilt viktigt.

Alla förslag för att få bra prestanda i appar gäller för att få bra prestanda i komponenter. Mät din komponent för att ta reda på vilka API:er som har höga trafikmönster, och för dessa områden bör du överväga att tillhandahålla API:er som gör det möjligt för användarna att arbeta med få anrop. Stora ansträngningar har lagts på att utforma Windows Runtime så att appar kan använda den utan att kräva frekvent korsning av interop-gränsen.