Projekt Astoria, czyli możliwość prostego przenoszenia aplikacji androidowych (pisanych w Javie i C++) do Windowsa 10 Mobile, od początku budzi skrajne emocje. Jedni cieszą się z tej możliwości, inni skazują projekt na klęskę, sugerując że i tak nikt nie będzie chciał wkładać dodatkowej pracy w przenoszenie i publikowanie appek dla Windowsa.
O szansach powodzenia tego pomysłu można bezprzedmiotowo dyskutować bawiąc się w jasnowidzów, ale dużo ciekawsze (a może tylko mi się tak wydaje?) są szczegóły techniczne samego sposobu przenoszenia aplikacji i sposobu ich działania – szczególnie pod kątem wydajności i stabilności. Już teraz słyszy się opinie, że „będą chodzić wolniej niż na urządzeniach z Androidem, bo każda emulacja czy wirtualizacja spowalnia”. To prawda, każde użycie emulatora czy maszyny wirtualnej będzie wolniejsze niż rozwiązania natywne, jeśli wykonywać będziemy te same fragmenty kodu. Widać to na przykładzie takich emulatorów Androida, jak Bluestacks dla desktopowego Windowsa, dzięki któremu możemy odpalać androidowe aplikacje w microsoftowym systemie. Nie tylko jest on wolny i zasobożerny, ale też mocno ograniczony jeśli chodzi o wsparcie dla sensorów czy urządzeń peryferyjnych.
Jest jednak jedno „ale”. Android w Windowsie Mobile nie będzie emulowany. Nie będzie osobnym systemem operacyjnym z linuksowym jądrem. Innymi słowy – aplikacje natywnie będą komunikować się z jądrem Windows NT. Nie będzie tu Androida czy Linuksa w ogóle. Oczywiście swojego rodzaju maszyna wirtualna Javy jest potrzebna (tak jak Android wykorzystuje Dalvika i ART-a), ale kod C++ będzie w 100% wykonywany natywnie. Ja to możliwe? Dzięki strukturze jądra systemu Windows i warstwowości jej komunikacji.
Zabrzmiało bardzo tajemniczo, ale żeby to lepiej zrozumieć, warto uświadomić sobie, że Windows już od dawna składał się z kilku subsystemów działających niezależnie, ale komunikujących się z tym samym jądrem. W przeszłości były to podsystemy POSIX i OS/2, ale nawet teraz mamy dwa główne podsystemy w desktopowej wersji Windowsa – Win32 (do aplikacji desktopowych) i WinRT (dla aplikacji Modern). Jeszcze raz chciałbym podkreślić, że te niezależne podsystemy komunikują się z tym samym, wspólnym jądrem, które odpowiada z kolei za komunikację ze sprzętem (w tym procesorem). Powiedzieliśmy o Windowsie desktopowym i jego dwóch podsystemach. Windows Mobile również będzie miał dwa podsystemy – WinRT (dokładnie ten sam, znany z pełnego Windowsa) oraz Android (z natywnym wykonywaniem binarek C++ oraz maszyną wirtualną Javy).
W zasadzie, dla osób mniej obeznanych w informatycznym żargonie, te informacje wystarczą, żeby zrozumieć podstawy (współ)działania aplikacji portowanych z Androida i oryginalnych aplikacji pisanych dla środowiska uruchomieniowego WinRT. Myślę jednak, ze wśród czytelników Tabletowo jest sporo osób, które chciałyby poznać ten temat głębiej. Strukturę jądra Windows NT najłatwiej zrozumieć dzięki powyższemu schematowi. Warstwa jądra (kernel mode) i i warstwa użytkownika (user mode – tu znajdują się subsystemy WinRT i Android, czyli tak zwane „enviroment subsystems”) są od siebie odseparowane. Różnią się między innymi uprawnieniami dostępu do pamięci czy czasu procesora – ze względów bezpieczeństwa, wydajności oraz stabilności. Warstwy te komunikują się ze sobą przez zarządcę pamięci wirtualnej (Virtual Memory Manager – VMM), a nad kwestiami bezpieczeństwa zajmuje się „integral susbsystem” działający równolegle do WinRT czy subsystemu Androida. Jak to ostatnie wygląda w praktyce? Pewnie słyszeliście o sandboksach, czyli „piaskownicach”, w których uruchamiane są aplikacje. Jest to narzędzie bezpieczeństwa, które niejako „oplata” proces danej aplikacji i kontroluje jego zachowanie (komunikację z innymi aplikacjami, odwołania do funkcji systemu, wymianę danych i sygnałów ze sprzętem czy sensorami, itd…). Sandboks Windowsa należy do jednych z najbezpieczniejszych i będzie on wspólny zarówno dla aplikacji WinRT, jak i subsystemu Androida. Nie ma więc ryzyka, że aplikacje androidowe „będą mniej bezpieczne” pod względem odwołań do systemu (pomijam w tym momencie dużo ważniejszy temat, czyli uprawnienia aplikacji).
Czy Microsoft zatem użył Android Open Source Project (AOSP) i umieścił go obok swojego systemu? Jeszcze raz – nie. Trzeba podkreślić to bardzo wyraźnie – Windows 10 nie będzie korzystać z androidowego API (Application Programming Interface – zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych). Jak zatem to wszystko działa? W tym momencie może narobiłem więcej zamieszania niż zdążyłem wyjaśnić, ale postaram się to naprawić. Microsoft postanowił zrobić dwie rzeczy – cały ciężar zmian i kompensacji różnic w systemach wziąć na siebie – oraz – wybrać możliwie najwydajniejszą metodę implementacji.
Tym sposobem, wybrał najpopularniejsze androidowe API, które wykorzystywane są przez aplikacje i PRZEPISAŁ je na nowo tak, żeby natywnie komunikowały się z windowsowym jądrem systemu. Innymi słowy – programista nie musi (prawie) nic zmieniać, a kontrolki czy API takie jak „udostępnij”, „lista kontaktów”, „powiadomienia”, „zadania w tle” i wszelkie odwołania systemowe zostały przepisane przez Microsoft tak, żeby pasowały do Windowsa. Podobnie jest z API dla Wideo, które będzie natywnie akcelerowane sprzętowo. Nie może tu być mowy o żadnym poświęceniu wydajności, emulacji czy drodze na skróty. Cała idea polega na zmapowaniu (przepisaniu i podmienieniu) wszystkich odwołań do systemu, które wykonują aplikacje androidowe tak, żeby były natywne wykonywane przez jądro systemu, bez dodatkowych warstw i poziomów komunikacji, które zawsze negatywnie wpływają na szybkość działania. Dotyczy to też między innymi mapowania zachowania przycisków nawigacji, regulacji głośności czy wyświetlaniu odpowiedniej „systemowej” klawiatury ekranowej, a nie klawiatury z konkurencyjnego systemu operacyjnego.
Jak będzie zatem w teorii wyglądać przenoszenie aplikacji z Androida na Windowsa 10?
- deweloper wysyła istniejącą androidową aplikację (.apk) na serwer Microsoftu w celu automatycznej analizy,
- narzędzie zwraca informacje o tym, które elementy są całkowicie zgodne, które zostaną automatycznie podmienione, a które będą wymagać ręcznej zmiany (np. zamiana Google Maps na Bing czy zmiana serwera i usługi powiadomień) lub będą całkowicie niekompatybilne – to ostatnie też jest możliwe,
- narzędzie zasugeruje pobranie SDK, czyli zestawu narzędzi programistycznych dla tworzenia aplikacji windowsowych z Androida,
- programista w swoim środowisku programistycznym (np. Eclipse czy Android Studio) dokonuje niezbędnych zmian, opcjonalnie dodaje nowe funkcje (takie jak dynamiczne kafelki) i eksportuje projekt – dzięki ściągniętemu SDK, paczka .apk trafia do nadrzędnej paczki .AppX, która jest standardową paczką dla wszystkich aplikacji dla Windowsa 8.1 i Windowsa 10 – z automatycznym zachowaniem takich metadanych jak opis aplikacji do sklepu, cena, języki, dostępność, etc…,
- deweloper wrzuca aplikację do Windows Store, która będzie czekać na walidację. Po walidacji będzie ona widoczna użytkownikowi dokładnie tak samo jak aplikacje pisane specjalnie dla Windowsa 10 dla subsystemu WinRT.
Rozwiązanie idealne, tak? Nie. Po pierwsze, mapowanie API oparte jest na API dla Androida 4.4 KitKat. Co prawda większość aplikacji zapewnia zgodność aż do 4.0 a nawet wcześniej, ale w przyszłości może to być problem, szczególnie w nowych rozwiązaniach i funkcjach, które będą wyłączne dla systemu Android. Po drugie, Microsoft nie mógł zmapować (przepisać i dostosować) wszystkich API. Wybrał te najpopularniejsze, tak, żeby większość aplikacji dała się łatwo przenieść. Nie będzie na razie działać komunikacja z Android Wear, rzutowanie ekranów (”casting”) i wiele innych mniej popularnych androidowych API. Microsoft musi priorytetyzować i wybierać to, co najpotrzebniejsze. Z czasem będzie dodawał obsługę kolejnych funkcji, w zależności od zapotrzebowania na nie, ale nie możemy oczekiwać, że niektóre złożone aplikacje, korzystające z wielu sensorów czy komunikujące się z peryferiami będą łatwo portowane. Wręcz przeciwnie.
Jest jednak też druga strona medalu. Zanim zostanę okrzyknięty fanbojem, podkreślam, że część z tego, co zaraz powiem jest daleko idącą spekulacją. Nie jest jednak spekulacją to, że subsystem Androida będzie działał w dużo bardziej hermetycznym środowisku niż w przypadku urządzeń z Androidem i Dalvika oraz ART-a. Z jednej strony może to spowodować pewne ograniczenia przy przenoszeniu aplikacji ze względu na brak uprawnień dostępu do systemu plików, smsów czy czasu procesora. Z drugiej, najprawdopodobniej przełoży się to na większe bezpieczeństwo, mniej zasobożernych aplikacji działających w tle czy większą wydajność. A co jeśli ta androidowa aplikacja przeportowana na Windowsa będzie działać szybciej, bezpieczniej i stabilniej? A nie ma żadnych technicznych przeciwwskazań, żeby moja przepowiednia się sprawdziła. Wręcz przeciwnie…
