Składniki środowiska uruchomieniowego systemu Windows i optymalizowanie współdziałania

Utwórz aplikacje systemu Windows, które wykorzystują składniki środowiska uruchomieniowego Windows i interoperacyjność między typami natywnymi i zarządzanymi, unikając jednocześnie problemów z wydajnością interop.

Najlepsze rozwiązania dotyczące współdziałania ze składnikami środowiska uruchomieniowego systemu Windows

Jeśli nie będziesz ostrożny, użycie komponentów środowiska uruchomieniowego Windows może mieć duży wpływ na wydajność aplikacji. W tej sekcji omówiono sposób uzyskiwania dobrej wydajności, gdy aplikacja używa składników środowiska uruchomieniowego systemu Windows.

Wprowadzenie

Współdziałanie może mieć duży wpływ na wydajność, a ty możesz z niego korzystać, nawet nie zdając sobie z tego sprawy. Środowisko uruchomieniowe systemu Windows obsługuje wiele współdziałania, dzięki czemu można pracować wydajniej i ponownie użyć kodu napisanego w innych językach. Zachęcamy do korzystania z tego, co robi środowisko uruchomieniowe systemu Windows, ale należy pamiętać, że może to mieć wpływ na wydajność. W tej sekcji omówiono rzeczy, które można zrobić, aby zmniejszyć wpływ współdziałania na wydajność aplikacji.

Środowisko uruchomieniowe systemu Windows ma bibliotekę typów, które są dostępne z dowolnego języka, który może pisać aplikację platformy uniwersalnej systemu Windows. Typy środowiska uruchomieniowego systemu Windows są używane w języku C# lub Microsoft Visual Basic w taki sam sposób, jak obiekty platformy .NET. Nie musisz wykonywać wywołań metod wywoływanych przez platformę w celu uzyskania dostępu do składników środowiska uruchomieniowego systemu Windows. Dzięki temu pisanie aplikacji jest znacznie mniej złożone, ale ważne jest, aby pamiętać, że może wystąpić więcej współdziałania niż oczekiwano. Jeśli składnik środowiska uruchomieniowego systemu Windows jest napisany w języku innym niż C# lub Visual Basic, przekraczasz granice współdziałania podczas korzystania z tego składnika. Przekraczanie granic współdziałania może mieć wpływ na wydajność aplikacji.

Podczas tworzenia aplikacji platformy uniwersalnej systemu Windows w języku C# lub Visual Basic dwa najbardziej typowe zestawy interfejsów API, których używasz, to interfejsy API środowiska uruchomieniowego systemu Windows i interfejsy API platformy .NET dla aplikacji platformy UWP. Ogólnie rzecz biorąc, typy udostępniane przez system Windows, które są oparte na środowisku uruchomieniowym systemu Windows w przestrzeniach nazw rozpoczynających się od "Windows", a typy platformy .NET znajdują się w przestrzeniach nazw rozpoczynających się od "System". Istnieją jednak wyjątki. Typy na platformie .NET dla aplikacji platformy UWP nie wymagają współdziałania, gdy są używane. Jeśli zauważysz, że w obszarze korzystającym ze środowiska uruchomieniowego Windows masz słabą wydajność, możesz spróbować użyć platformy .NET dla aplikacji UWP, aby uzyskać lepszą wydajność.

Nuta Większość składników środowiska uruchomieniowego systemu Windows, które są dostarczane z systemem Windows 10, są implementowane w języku C++, dzięki czemu przekraczasz granice współdziałania podczas korzystania z nich z języka C# lub Visual Basic. Jak zawsze należy zmierzyć aplikację, aby sprawdzić, czy użycie składników środowiska uruchomieniowego systemu Windows wpływa na wydajność aplikacji, zanim zainwestujesz w wprowadzanie zmian w kodzie.

W tym temacie, gdy wspominamy o "składnikach środowiska uruchomieniowego systemu Windows", oznaczamy składniki środowiska uruchomieniowego systemu Windows napisane w języku innym niż C# lub Visual Basic.

Za każdym razem, gdy uzyskujesz dostęp do właściwości lub wywołujesz metodę w składniku środowiska uruchomieniowego systemu Windows, naliczany jest koszt współdziałania. W rzeczywistości tworzenie składnika środowiska uruchomieniowego systemu Windows jest bardziej kosztowne niż tworzenie obiektu platformy .NET. Przyczyną tego jest to, że środowisko uruchomieniowe systemu Windows musi wykonać kod, który przechodzi z języka aplikacji do języka składnika. Ponadto, jeżeli przekazujesz dane do składnika, dane muszą być konwertowane między typami zarządzanymi i niezarządzanymi.

Wydajne korzystanie ze składników środowiska uruchomieniowego systemu Windows

Jeśli okaże się, że potrzebujesz uzyskać lepszą wydajność, możesz upewnić się, że kod używa składników środowiska uruchomieniowego systemu Windows tak wydajnie, jak to możliwe. W tej sekcji omówiono kilka wskazówek dotyczących poprawy wydajności podczas korzystania ze składników środowiska uruchomieniowego systemu Windows.

Aby wpływ na wydajność był zauważalny, potrzebna jest znaczna liczba wywołań w krótkim czasie. Dobrze zaprojektowana aplikacja, która hermetyzuje wywołania składników środowiska uruchomieniowego systemu Windows z logiki biznesowej i innego kodu zarządzanego, nie powinna ponosić ogromnych kosztów współdziałania. Jeśli jednak testy wskazują, że użycie składników środowiska uruchomieniowego systemu Windows wpływa na wydajność aplikacji, porady omówione w tej sekcji pomagają zwiększyć wydajność.

Rozważ użycie typów udostępnianych przez platformę .NET dla aplikacji platformy UWP

Istnieją pewne przypadki, w których można wykonać zadanie przy użyciu typu środowiska uruchomieniowego systemu Windows lub typu dostarczonego przez platformę .NET dla aplikacji platformy UWP. Warto spróbować nie mieszać typów platformy .NET i typów środowiska uruchomieniowego systemu Windows. Spróbuj pozostać w jednym lub drugim. Można na przykład przeanalizować strumień XML, używając typu Windows.Data.Xml.Dom.XmlDocument (typ Windows Runtime) lub typu System.Xml.XmlReader (typ .NET). Użyj interfejsu API, który pochodzi z tej samej technologii co strumień. Jeśli na przykład odczytujesz kod XML z MemoryStream, użyj typu System.Xml.XmlReader, ponieważ oba typy są typami platformy .NET. Jeśli odczytujesz z pliku, użyj typu Windows.Data.Xml.Dom.XmlDocument, gdyż interfejsy API plików i XmlDocument zostały zaimplementowane jako natywne składniki środowiska uruchomieniowego Windows.

Kopiuj obiekty środowiska uruchomieniowego Windows do typów platformy .NET

Gdy składnik środowiska uruchomieniowego systemu Windows zwraca obiekt Środowiska uruchomieniowego systemu Windows, może być korzystne skopiowanie zwróconego obiektu do obiektu platformy .NET. Dwa miejsca, w których jest to szczególnie ważne, to praca z kolekcjami i strumieniami.

Jeśli wywołujesz interfejs API środowiska uruchomieniowego systemu Windows, który zwraca kolekcję, a następnie zapisujesz kolekcję i uzyskujesz do niej dostęp wiele razy, warto skopiować kolekcję do kolekcji platformy .NET i użyć wersji platformy .NET od tego czasu.

Buforowanie wyników wywołań do składników środowiska uruchomieniowego systemu Windows do późniejszego użycia

Możesz uzyskać lepszą wydajność, zapisując wartości w zmiennych lokalnych zamiast wielokrotnego uzyskiwania dostępu do typu środowiska uruchomieniowego systemu Windows. Może to być szczególnie korzystne, jeśli używasz wartości wewnątrz pętli. Zmierz aplikację, aby sprawdzić, czy użycie zmiennych lokalnych poprawia wydajność aplikacji. Użycie buforowanych wartości może zwiększyć szybkość aplikacji, ponieważ poświęca mniej czasu na współdziałanie.

Łączenie wywołań ze składnikami środowiska uruchomieniowego systemu Windows

Spróbuj wykonać zadania z najmniejszą liczbą wywołań do obiektów platformy UWP, jak to możliwe. Na przykład zwykle lepiej jest odczytywać dużą ilość danych ze strumienia niż odczytywać małe ilości naraz.

Używaj interfejsów API, które łączą pracę w jak najmniejszej liczbie wywołań, zamiast interfejsów API, które wykonują mniej pracy i wymagają większej liczby wywołań. Na przykład wolisz utworzyć obiekt, wywołując konstruktory, które inicjują wiele właściwości raz, zamiast wywoływać konstruktor domyślny i przypisywać właściwości pojedynczo.

Kompilowanie składników środowiska uruchomieniowego systemu Windows

Jeśli napiszesz składnik środowiska uruchomieniowego systemu Windows, który może być używany przez aplikacje napisane w języku C++ lub JavaScript, upewnij się, że składnik został zaprojektowany pod kątem dobrej wydajności. Wszystkie sugestie dotyczące uzyskiwania dobrej wydajności w aplikacjach mają zastosowanie do uzyskania dobrej wydajności w składnikach. Zmierz składnik, aby dowiedzieć się, które interfejsy API mają wysoki ruch i dla tych obszarów, rozważ udostępnienie interfejsów API, które umożliwiają użytkownikom pracę przy minimalnej liczbie wywołań.

Zachowaj szybkość aplikacji, gdy używasz międzyoperajności w kodzie zarządzanym

Środowisko uruchomieniowe systemu Windows ułatwia współpracę między natywnym i zarządzanym kodem, ale jeśli się nie uważa, może wiązać się z kosztami związanymi z wydajnością. W tym miejscu pokazano, jak uzyskać dobrą wydajność w przypadku korzystania z międzyoperacjności w zarządzanych aplikacjach platformy UWP.

Środowisko Uruchomieniowe Widows umożliwia deweloperom pisanie aplikacji przy użyciu języka XAML z wybranym językiem dzięki projekcjom interfejsów API środowiska uruchomieniowego systemu Windows dostępnych w każdym języku. Podczas pisania aplikacji w języku C# lub Visual Basic ta wygoda wiąże się z kosztami międzyoperacyjności, ponieważ interfejsy API środowiska wykonawczego systemu Windows są zwykle implementowane w kodzie natywnym, a każde wywołanie środowiska wykonawczego Windows z języka C# lub Visual Basic wymaga przejścia środowiska CLR z zarządzanego do natywnej ramki stosu i marshalingu parametrów funkcji do reprezentacji dostępnych dla kodu natywnego. To obciążenie jest niewielkie w przypadku większości aplikacji. Jednak jeśli wykonujesz wiele wywołań (setki tysięcy, do milionów) do interfejsów API środowiska uruchomieniowego systemu Windows w krytycznej ścieżce aplikacji, ten koszt może stać się zauważalny. Ogólnie rzecz biorąc, chcesz mieć pewność, że czas spędzony w przejściu między językami jest niewielki w stosunku do wykonywania pozostałej części kodu. Jest to zilustrowane na poniższym diagramie.

Typy wymienione w .NET dla aplikacji Windows nie generują kosztu interoperacyjności przy użyciu w językach C# lub Visual Basic. Jako ogólną zasadę można założyć, że typy w przestrzeni nazw, które zaczynają się od „Windows”. są częścią zestawu interfejsu API środowiska uruchomieniowego systemu Windows, dostarczonego przez Windows, oraz typy w przestrzeniach nazw, które zaczynają się od „System”. są to typy .NET. Należy pamiętać, że nawet proste użycie typów Windows Runtime wiąże się z kosztem międzyoperacyjnym związanym z alokacją lub dostępem do właściwości.

Należy zmierzyć swoje aplikacje i określić, czy interoperacyjność zajmuje dużą część czasu ich wykonywania, zanim rozpoczniesz optymalizację kosztów. Podczas analizowania wydajności aplikacji za pomocą programu Visual Studio można łatwo uzyskać górną granicę kosztów międzyoperacyjnych, korzystając z widoku Functions i przyglądając się łącznemu czasowi spędzonemu w metodach wywołujących Windows Runtime.

Jeśli aplikacja działa wolno ze względu na obciążenie międzyoperacyjne, możesz zwiększyć jej wydajność, zmniejszając liczbę wywołań interfejsów API środowiska uruchomieniowego systemu Windows w ścieżkach kodu gorącego. Na przykład silnik gry, który wykonuje mnóstwo obliczeń fizycznych, nieustannie zapytując o położenie i wymiary elementów interfejsu użytkownika, może zaoszczędzić dużo czasu, przechowując niezbędne informacje z elementów interfejsu użytkownika w zmiennych lokalnych, wykonując obliczenia na tych zbuforowanych wartościach, a następnie przypisując wynik końcowy z powrotem do elementów interfejsu użytkownika po zakończeniu obliczeń. Inny przykład: jeśli dostęp do kolekcji jest w dużym stopniu uzyskiwany przez kod języka C# lub Visual Basic, bardziej wydajne jest użycie kolekcji z przestrzeni nazw System.Collections , a nie kolekcji z przestrzeni nazw Windows.Foundation.Collections . Możesz również rozważyć połączenie wywołań ze składnikami środowiska uruchomieniowego systemu Windows; jednym z przykładów, w których jest to możliwe, jest użycie interfejsów API Windows.Storage.BulkAccess .

Tworzenie składnika platformy UWP

Jeśli napiszesz składnik środowiska uruchomieniowego systemu Windows do użycia w aplikacjach napisanych w języku C++ lub JavaScript, upewnij się, że składnik został zaprojektowany pod kątem dobrej wydajności. Interfejs API definiuje granicę współdziałania i określa stopień, w jakim użytkownicy będą musieli rozważyć wskazówki w tym temacie. W przypadku dystrybucji składników do innych stron staje się to szczególnie ważne.

Wszystkie sugestie dotyczące uzyskiwania dobrej wydajności w aplikacjach mają zastosowanie do uzyskania dobrej wydajności w składnikach. Zmierz swój komponent, aby dowiedzieć się, które interfejsy API mają wzorce dużego ruchu, i rozważ udostępnienie takich API, które pozwalają użytkownikom wykonywać zadania za pomocą niewielkiej liczby wywołań. Znaczne nakłady pracy zostały wprowadzone do projektowania środowiska uruchomieniowego systemu Windows, aby umożliwić aplikacjom korzystanie z niego bez konieczności częstego przekraczania granicy międzyoperacyjnej.