Niedawno napisałem obszerny artykuł opisujący mechanizm tworzenia, kompilowania i uruchamiania aplikacji na Androida i dotykowego Windowsa. Po niecałych dwóch tygodniach muszę to zrewidować z uwagi na duże zmiany, jakie pojawiły się na windowsowej platformie.
Pisałem:
Największym zaskoczeniem dla niektórych będzie pewnie informacja, że Windows Phone, Windows 10 czy Windows 10 Mobile, do aplikacji dotykowych działających w środowisku uruchomieniowym WinRT (Windows Runtime), również wykorzystuje maszynę wirtualną. Tak, C# jest językiem, który kompilowany jest do kodu pośredniego (bytecode) dokładnie tak jak Java. Dopiero Common Language Runtime (CLR), czyli maszyna wirtualna tego środowiska, kompiluje kod przejściowy do kodu maszynowego. Dokładnie tak jak w Androidzie.
W czasie powstawania tego artykułu było to prawdą, ale wkrótce ma się to diametralnie zmienić. .NET Native to technologia implementowana w Visual Studio, która sprawia, że uniwersalne aplikacje tworzone dla Windowsa 10 kompilowane będą bezpośrednio do kodu maszynowego, a nie tak jak to ma miejsce obecnie – do kodu pośredniego (bytecode), a dopiero potem, na urządzeniu, kompilowane do maszynówki przez lokalną maszynę wirtualną.
Po co to wszystko? Kompilacja do kodu natywnego to mniejsze zużycie zasobów (głównie RAM i procesora), do 60% szybszy zimny start aplikacji i do 40% szybsze wznawianie (wg Microsoftu), wydajność zbliżona do języków kompilowanych do kodu maszynowego (takich jak C++) – a to wszystko przy zachowaniu elastyczności i wygody programowania w C# czy VB.
Po szczegóły odsyłam tutaj i tutaj, ale w największym skrócie będzie to działać w następujący sposób. Kompilując do wersji „Release” wynikiem tego działania będą dwie paczki – .appx do sideloadowania na urządzenia testowe odblokowane dewelopersko i .appxupload z kodem pośrednim dla wysyłania paczek do sklepu. Dlaczego kod pośredni w tym drugim przypadku? I tutaj zaczyna być ciekawie. Kompilacja do kodu maszynowego będzie odbywać się na serwerach Microsoftu (w chmurze). Ale dlaczego nie lokalnie, na maszynie programisty? Microsoft wciąż będzie optymalizował kompilator i wysłane do sklepu paczki mogą być rekompilowane w chmurze przez Microsoft bez potrzeby angażowania w to programisty. Pozwoli to na poprawę szybkości i działania aplikacji oszczędzając jednocześnie czas deweloperów.
Czas pokaże na ile nowe podejście poprawi wydajność, a w szczególności czasy uruchamiania appek, które były piętą achillesową na słabszych smartfonach. Microsoft najwyraźniej rozumie ten problem i postanowił coś z tym zrobić. Warto podkreślić, że .NET Native to narzędzie tylko i wyłącznie dla platformy Universal Windows Platform, czyli uniwersalnych aplikacji pisanych dla Windowsa 10. Starsze aplikacje mobilne pisane dla WP8.1 nie skorzystają w żaden sposób z tej zmiany, a w systemie Windows 10 Mobile dalej będzie musiała istnieć maszyna wirtualna (CLR) do obsługi appek kompilowanych do bajtowego kodu pośredniego.
