Windows Runtime-onderdelen en het optimaliseren van interop

Ontwikkel Windows-apps die gebruikmaken van Windows Runtime-onderdelen en interoperabiliteit tussen systeemeigen en beheerde typen, terwijl prestatieproblemen met interoperabiliteit worden vermeden.

Aanbevolen procedures voor interoperabiliteit met Windows Runtime-onderdelen

Als u niet voorzichtig bent, kan het gebruik van Windows Runtime-onderdelen een grote invloed hebben op de prestaties van uw app. In deze sectie wordt beschreven hoe u goede prestaties krijgt wanneer uw app Gebruikmaakt van Windows Runtime-onderdelen.

Introductie

Interoperabiliteit kan een grote invloed hebben op de prestaties en u gebruikt deze mogelijk zonder dat u zich realiseert dat u dat bent. De Windows Runtime verwerkt veel van de interoperabiliteit voor u, zodat u productiever kunt zijn en code kunt hergebruiken die in andere talen is geschreven. We raden u aan om te profiteren van wat Windows Runtime voor u doet, maar houd er rekening mee dat dit van invloed kan zijn op de prestaties. In deze sectie worden de dingen besproken die u kunt doen om de impact die interoperabiliteit heeft op de prestaties van uw app te verminderen.

De Windows Runtime heeft een bibliotheek met typen die toegankelijk zijn vanuit elke taal die een Universeel Windows-platform-app kan schrijven. U gebruikt de Typen Windows Runtime in C# of Microsoft Visual Basic op dezelfde manier als u .NET-objecten gebruikt. U hoeft geen platform-aanroepmethode aan te roepen om toegang te krijgen tot de Windows Runtime-onderdelen. Dit maakt het schrijven van uw apps veel minder complex, maar het is belangrijk om te beseffen dat er mogelijk meer interoperabiliteit plaatsvindt dan verwacht. Als een Windows Runtime-onderdeel is geschreven in een andere taal dan C# of Visual Basic, overschrijdt u interoperabiliteitsgrenzen wanneer u dat onderdeel gebruikt. Het overschrijden van interoperabiliteitsgrenzen kan van invloed zijn op de prestaties van een app.

Wanneer u een Universal Windows Platform-app ontwikkelt in C# of Visual Basic, zijn de twee meest voorkomende API's die u gebruikt de Windows Runtime-API's en de .NET API's voor UWP-apps. In het algemeen zijn typen die worden geleverd door Windows die zijn gebouwd op Windows Runtime in naamruimten die beginnen met 'Windows'. en .NET-typen zich in naamruimten die beginnen met 'Systeem'. Er zijn echter uitzonderingen. De typen in .NET voor UWP-apps vereisen geen interoperabiliteit wanneer ze worden gebruikt. Als u merkt dat u slechte prestaties hebt in een gebied dat dan Windows Runtime gebruikt, kunt u in plaats daarvan .NET voor UWP-apps gebruiken om betere prestaties te krijgen.

Notitie De meeste Windows Runtime-onderdelen die worden geleverd met Windows 10, worden geïmplementeerd in C++ zodat u interoperabiliteitsgrenzen overschrijdt wanneer u deze gebruikt vanuit C# of Visual Basic. Zoals altijd moet u ervoor zorgen dat u uw app meet om te zien of het gebruik van Windows Runtime-onderdelen van invloed is op de prestaties van uw app voordat u investeert in het aanbrengen van wijzigingen in uw code.

In dit onderwerp, wanneer we 'Windows Runtime-onderdelen' noemen, bedoelen we Windows Runtime-onderdelen die zijn geschreven in een andere taal dan C# of Visual Basic.

Telkens wanneer u toegang krijgt tot een eigenschap of een methode aanroept in een Windows Runtime-onderdeel, worden er interoperabiliteitskosten gemaakt. Het maken van een Windows Runtime-onderdeel is zelfs duurder dan het maken van een .NET-object. De redenen hiervoor zijn dat De Windows Runtime code moet uitvoeren die van de taal van uw app overgaat naar de taal van het onderdeel. Als u gegevens doorgeeft aan het onderdeel, moeten de gegevens ook worden geconverteerd tussen beheerde en niet-beheerde typen.

Windows Runtime-onderdelen efficiënt gebruiken

Als u merkt dat u betere prestaties moet krijgen, kunt u ervoor zorgen dat uw code zo efficiënt mogelijk gebruikmaakt van Windows Runtime-onderdelen. In deze sectie worden enkele tips besproken voor het verbeteren van de prestaties wanneer u Windows Runtime-onderdelen gebruikt.

Het duurt een aanzienlijk aantal aanroepen in een korte periode om de invloed op de prestaties merkbaar te maken. Een goed ontworpen toepassing, waarin aanroepen naar Windows Runtime-onderdelen voor bedrijfslogica en andere beheerde code worden ingepakt, zou geen enorme interoperabiliteitskosten moeten meebrengen. Maar als uw tests aangeven dat het gebruik van Windows Runtime-onderdelen van invloed is op de prestaties van uw app, kunt u met de tips in deze sectie de prestaties verbeteren.

Overweeg het gebruik van typen die worden geleverd door .NET voor UWP-apps

Er zijn bepaalde gevallen waarin u een taak kunt uitvoeren met behulp van het Type Windows Runtime of een type dat wordt geleverd door .NET voor UWP-apps. Het is een goed idee om .NET-typen en Windows Runtime-typen niet te combineren. Probeer in een of andere te blijven. U kunt bijvoorbeeld een xml-stroom parseren met behulp van het type Windows.Data.Xml.Dom.XmlDocument (een Windows Runtime-type) of het type System.Xml.XmlReader (een .NET-type). Gebruik de API die afkomstig is van dezelfde technologie als de stream. Als u bijvoorbeeld xml uit een MemoryStream leest, gebruikt u het type System.Xml.XmlReader , omdat beide typen .NET-typen zijn. Als u uit een bestand leest, gebruikt u het type Windows.Data.Xml.Dom.XmlDocument omdat de bestands-API's en XmlDocument beide zijn geïmplementeerd in systeemeigen Windows Runtime-onderdelen .

Window Runtime-objecten kopiëren naar .NET-typen

Wanneer een Windows Runtime-onderdeel een Windows Runtime-object retourneert, kan het nuttig zijn om het geretourneerde object te kopiëren naar een .NET-object. Twee plaatsen waar dit vooral belangrijk is wanneer u met verzamelingen en streams werkt.

Als u een Windows Runtime-API aanroept die een verzameling retourneert en die verzameling vervolgens vaak opslaat en opent, kan het handig zijn om de verzameling te kopiëren naar een .NET-verzameling en de .NET-versie te gebruiken vanaf dat moment.

Cache de resultaten van aanroepen naar Windows Runtime-onderdelen voor later gebruik

U kunt mogelijk betere prestaties krijgen door waarden op te slaan in lokale variabelen in plaats van meerdere keren toegang te krijgen tot een Windows Runtime-type. Dit kan vooral nuttig zijn als u een waarde binnen een lus gebruikt. Meet uw app om te zien of het gebruik van lokale variabelen de prestaties van uw app verbetert. Als u waarden in de cache gebruikt, kan de snelheid van uw app toenemen, omdat deze minder tijd besteedt aan interoperabiliteit.

Aanroepen naar Windows Runtime-onderdelen combineren

Probeer taken te voltooien met het minste aantal aanroepen naar UWP-objecten, indien mogelijk. Het is bijvoorbeeld beter om een grote hoeveelheid gegevens uit een stroom te lezen dan om kleine hoeveelheden tegelijk te lezen.

Gebruik API's die werk bundelen in zo weinig mogelijk aanroepen in plaats van API's die minder werk doen en meer aanroepen vereisen. Maak bijvoorbeeld liever een object door constructors aan te roepen die meerdere eigenschappen eenmaal initialiseren in plaats van de standaardconstructor aan te roepen en eigenschappen één voor één toe te wijzen.

Windows Runtime-componenten bouwen

Als u een Windows Runtime-onderdeel schrijft dat kan worden gebruikt door apps die zijn geschreven in C++ of JavaScript, moet u ervoor zorgen dat uw onderdeel is ontworpen voor goede prestaties. Alle suggesties voor het verkrijgen van goede prestaties in apps zijn van toepassing op het verkrijgen van goede prestaties in onderdelen. Meet uw onderdeel om erachter te komen welke API's veel verkeerspatronen hebben en voor deze gebieden, overweeg om API's te bieden die uw gebruikers in staat stellen om met weinig aanroepen te werken.

Houd uw app snel wanneer u interop gebruikt in beheerde code

Met Windows Runtime kunt u eenvoudig samenwerken tussen systeemeigen en beheerde code, maar als u niet voorzichtig bent, kunnen er prestatiekosten in rekening worden gebracht. Hier ziet u hoe u goede prestaties krijgt wanneer u interop gebruikt in uw beheerde UWP-apps.

Met De Widows Runtime kunnen ontwikkelaars apps schrijven met behulp van XAML met hun gewenste taal dankzij de projecties van de Windows Runtime-API's die in elke taal beschikbaar zijn. Wanneer u een app schrijft in C# of Visual Basic, heeft dit gemak interoperabiliteitskosten omdat de Windows Runtime-API's meestal worden geïmplementeerd in systeemeigen code en elke aanroep van Windows Runtime vanuit C# of Visual Basic vereist dat de CLR overgaat van een beheerd naar een systeemeigen stackframe en dat marshalfunctieparameters worden weergegeven als representaties die toegankelijk zijn voor systeemeigen code. Deze overhead is te verwaarlozen voor de meeste apps. Maar wanneer u veel aanroepen doet (honderdduizenden, miljoenen) naar Windows Runtime-API's in het kritieke pad van een app, kunnen deze kosten merkbaar worden. Over het algemeen wilt u ervoor zorgen dat de tijd die is besteed aan de overgang tussen talen klein is ten opzichte van de uitvoering van de rest van uw code. Dit wordt geïllustreerd in het volgende diagram.

Voor de typen die worden vermeld in .NET voor Windows-apps worden deze interoperabiliteitskosten niet in rekening gebracht wanneer ze worden gebruikt vanuit C# of Visual Basic. Als vuistregel kunt u ervan uitgaan dat soorten in naamruimten die beginnen met 'Windows'. maken deel uit van de Windows Runtime-API-set die wordt geleverd door Windows en typen in naamruimten die beginnen met 'Systeem'. zijn .NET-typen. Houd er rekening mee dat zelfs bij eenvoudig gebruik van Windows Runtime-typen interoperabiliteitskosten ontstaan voor allocatie of toegang tot eigenschappen.

U moet uw app meten en bepalen of interop een groot deel van de uitvoeringstijd van uw apps in beslag neemt voordat u de kosten voor interoperabiliteit optimaliseert. Wanneer u de prestaties van uw app analyseert met Visual Studio, kunt u eenvoudig een bovengrens bepalen van uw interop-kosten met behulp van de Functions view en de inclusieve tijd bekijken die wordt besteed aan methoden, die de Windows Runtime aanroepen.

Als uw app traag is vanwege interoperabiliteitsoverhead, kunt u de prestaties verbeteren door aanroepen naar Windows Runtime-API's op hotcodepaden te verminderen. Een game-engine die bijvoorbeeld veel fysicaberekeningen uitvoert door voortdurend query's uit te voeren op de positie en dimensies van UIElements , kan veel tijd besparen door de benodigde informatie van UIElements op te slaan in lokale variabelen, berekeningen uit te voeren op deze waarden in de cache en het eindresultaat weer toe te wijzen aan de UIElements nadat de berekeningen zijn uitgevoerd. Een ander voorbeeld: als een verzameling intensief wordt geopend door C# of Visual Basic-code, is het efficiënter om een verzameling te gebruiken vanuit de naamruimte System.Collections in plaats van een verzameling uit de naamruimte Windows.Foundation.Collections . U kunt ook overwegen om aanroepen naar Windows Runtime-onderdelen te combineren; een voorbeeld waar dit mogelijk is, is door de API's voor Windows.Storage.BulkAccess te gebruiken.

Een UWP-onderdeel bouwen

Als u een Windows Runtime-onderdeel schrijft voor gebruik in apps die zijn geschreven in C++ of JavaScript, moet u ervoor zorgen dat uw onderdeel is ontworpen voor goede prestaties. Uw API-oppervlak definieert uw interop-grens en definieert de mate waarin uw gebruikers na moeten denken over de richtlijnen in dit onderwerp. Als u uw onderdelen naar andere partijen distribueert, wordt dit vooral belangrijk.

Alle suggesties voor het verkrijgen van goede prestaties in apps zijn van toepassing op het verkrijgen van goede prestaties in onderdelen. Meet uw onderdeel om erachter te komen welke API's veel verkeerspatronen hebben en voor deze gebieden kunt u overwegen API's te bieden waarmee uw gebruikers met weinig aanroepen kunnen werken. Er is veel werk gedaan aan het ontwerpen van De Windows Runtime, zodat apps deze kunnen gebruiken zonder dat de interopgrens regelmatig wordt overschreden.