Szczególne aspekty budowania aplikacji pod Windows Phone 7 « Pabloware + Windows Phone

Pabloware + Windows Phone

Niezależny blog firmy Pabloware o systemie Windows® Phone 7

Szczególne aspekty budowania aplikacji pod Windows Phone 7

Zdecydowana większość dodatkowych czynności, jakie należy podjąć budując aplikacje pod system Windows Phone 7 (podobnie jak pod inne systemy mobilne) związana jest z wydajnością tych aplikacji. Spowodowane jest to oczywiście ograniczoną mocą procesora telefonu komórkowego. Ważne jest również jak najmniejsze zużywanie baterii, na co ma wpływ m.in. stopień obciążenia procesora. We wpisie tym czytelnik pozna podstawowe zasady, jakimi należy kierować się, aby wydajność tworzonych aplikacji była jak najlepsza, a zużycie baterii było jak najmniejsze.

Omówione zostaną także szczególne aspekty, które są związane z interfejsem użytkownika.

Poprawa szybkości ładowania kodu i zasobów aplikacji

W przypadku średniej wielkości i dużych aplikacji, poprawienie ich szybkości ładowania do pamięci może być uzyskane poprzez podział aplikacji na kilka plików DLL. Możliwe są tu dwie strategie. Pierwszą z nich jest podział dużych aplikacji na pliki DLL odpowiadające poszczególnym częściom aplikacji i ładowane ich w miarę potrzeby. Drugą, adekwatną w przypadku średniej wielkości aplikacji możliwością, jest umieszczenie rzadko używanych elementów (np. stron opcje i o programie) w osobnym pliku DLL, a całej reszty aplikacji w innym pliku DLL. Bardzo małe aplikacje oczywiście znikomo zyskają na takim podziale.

Trzeba zaznaczyć, że powyższa porada dotyczy ładowania kodu samej aplikacji, a nie danych aplikacji. Wszelkie dystrybuowane z aplikacją pliki danych i np. zasoby multimedialne powinny być oznaczone w pliku projektu jako Content, a nie jako Resource. Tak oznaczone pliki nie będą weryfikowane pod kątem podpisu cyfrowego generowanego przez usługę Marketplace (nie będą nawet umieszczone w pliku XAP aplikacji [sic!]), co spowoduje szybsze ładowanie aplikacji, szczególnie za jej pierwszym uruchomieniem.

Gdy aplikacja ze względu na ładowanie zasobów potrzebuje więcej niż sekundę, aby pokazać pierwszą stronę, firma Microsoft zaleca pokazanie ekranu splash screen (domyślnie zresztą zawartego w każdym nowym projekcie), choć z drugiej strony zalecane jest też utrzymanie ciągłości przejścia między systemem i aplikacjami w wymiarze interfejsu użytkownika. W praktyce więc, korzystne jest załadowanie takiej liczby zasobów, żeby możliwe było pokazanie początkowego stanu pierwszej strony aplikacji zawierającego np. animację ładowania pozostałych zasobów. Tym samym ekrany splash screen okazują się rzeczywiście przydatne tylko, kiedy takie częściowe ładowanie nie jest z różnych względów możliwe.

Skrupulatne podejście do wydajności podczas programowania

Modny obecnie paradygmat odwrócenia sterowania jest przykładem techniki, która choć jest bardzo pożyteczna, podczas tworzenia dużych aplikacji (np. webowych), to intensywnie stosowana w aplikacjach na telefon komórkowy może doprowadzić do zbyt małej ich wydajności.

Innym przykładem ułatwienia w programowaniu, które na telefonie komórkowym w mniejszym lub większym stopniu nie jest korzystne, z powodu wydajności, jest korzystanie z mechanizmów wiązania danych (ang. binding) z kontrolkami interfejsu użytkownika w technologii Silverlight, co jest oczywiście wolniejsze od ręcznego przepisywania danych do interfejsu użytkownika, w kodzie aplikacji.

Dodatkowym spowolnieniem podczas wiązania danych z kontrolkami interfejsu użytkownika jest korzystanie ze zautomatyzowanych konwerterów (np. popularny konwerter Silverlight służy do zmiany wartości logicznej na typ wyliczeniowy, używany przez kontrolki do określenia ich widoczności). Konwertery takie są z powodzeniem stosowane, w celu uproszczenia kodu, w aplikacjach Silverlight lub WPF przeznaczonych na komputery biurkowe, ale na telefonach komórkowych, powodowane przez nie spowolnienie, jest już odczuwalne przez użytkownika, jeśli np. są stosowane w listach. Rozwiązaniem jest oczywiście ręczna konwersja wartości w kodzie, przed dowiązaniem lub przepisaniem ich do kontrolek.

Kolejnym, związanym z technologią Silverlight, wrażliwym punktem wydajności jest korzystanie z rozbudowanych szablonów kontrolek. W najgorszym przypadku elementy tych szablonów mogą posiadać zapętlające się współzależności renderowania (np. dotyczące rozmiaru), które będą dodatkowo spowalniać renderowanie strony. Najlepiej jest stosować jak najprostsze szablony kontrolek, o stałych rozmiarach, określając ten rozmiar na sztywno. Gdy zaś potrzeba zastosować bardziej skomplikowane szablony, można je zamknąć jako osobne kontrolki, w najlepszym przypadku nie korzystające z wiązania danych. Stosowanie kontrolek zamiast wiązania danych komplikuje implementację, ale powoduje wzrost wydajności.

Wymienione w tym punkcie optymalizacje sprowadzają się do rezygnacji z najbardziej kosztownych wydajnościowo ułatwień w budowaniu aplikacji i zarządzaniu kodem, na rzecz własnych rozwiązań. Jest to często konieczna czynność, aby uzyskać zadowalającą szybkość aplikacji na telefonie komórkowym, choć oczywiście nie znaczy to, że jest to czynność wystarczająca.

Opóźnione ładowanie danych

Zalecane przez firmę Microsoft jest nie ładowanie żadnych danych, podczas konstruowania stron Silverlight z kodu XAML, ponieważ konstruowanie to samo w sobie jest kosztowne czasowo. Poprawnym w związku z tym sposobem postępowania ma być odczekanie do wystąpienia odpowiedniego zdarzenia, oznajmiającego o skonstruowaniu wszystkich elementów wizualnych strony (LayoutUpdated) i dopiero potem dokonanie czasochłonnego ładowania danych. Spowoduje to, że użytkownik relatywnie szybko zobaczy stronę, na którą zostaną następnie załadowane dane, zamiast długo oczekiwać na pokazanie się strony.

Być może czytelnik zgodzi się, że możliwe wydaje się rozwinięcie powyższej idei i w przypadku statystycznych stron o niezmiennym podczas konstruowania z kodu XAML układzie wizualnym, udostępnienie jakiejś formy ich prekompilacji (w zasadzie hibernacji), aby skrócić czas konstruowania. Przypominałoby to per analogiam możliwość oznaczania klas, z których nie można dziedziczyć, jako sealed w języku C#, co powoduje, że nie są już dla tych klas szukane nadpisania metod wirtualnych i w związku z tym poprawiona jest szybkość wywołań tych metod. Prekompilowane strony mogłyby być modyfikowane wyłącznie po całkowitym załadowaniu, ale taki schemat postępowania i tak jest obecnie zalecany, więc z punktu widzenia autora aplikacji korzystającego z gotowych, odpowiednio przygotowanych kontrolek XAML, koszt takiego rozwiązania byłby niewidoczny, a strony byłyby konstruowane szybciej.

Oczywiście wyrażoną na początku tego punktu zasadę opóźnionego ładowania danych na stronę można uogólnić i zastosować na wszystkie składniki strony z osobna, a nie tylko na stronę jako całość. W ten sposób można ładować poszczególne dane dopiero, kiedy użytkownik przejdzie do takiego miejsca na stronie, w którym dane te są potrzebne. Przykładowym miejscem zastosowania są tu strony przewijane w pionie lub poziomie, jak również strony pokazujące okna wyskakujące, a może nawet listy rozwijane.

Minimalizacja użycia wątku interfejsu użytkownika

Wątek interfejsu użytkownika nie powinien być nigdy zablokowany długotrwałą pracą, bo jego najważniejszym zadaniem jest odpowiadanie na interakcje użytkownika z aplikacją. Kiedy np. użytkownik naciśnie przycisk powodujący jakąś długotrwałą czynność, interfejs użytkownika nie powinien zostać zablokowany. Jednym ze sposobów uzyskania takiego efektu, gdy do wykonania jest długotrwała praca po stronie aplikacji, jest zlecenie pracy do wątku działającego w tle. Nie jest to niczym nietypowym również w przypadku programowania na biurkowej wersji Windows, ale ponieważ procesor telefonu komórkowego ma słabsze możliwości, do blokowania wątku interfejsu użytkownika dochodzi na nim znacznie łatwiej, stąd konieczność zlecania pracy do wątku tła występuje częściej.

Taki sposób postępowania będzie przypuszczalnie przynosić korzyści także w Windows Phone 7.1, w którym obsługa dotyku zostanie przeniesiona, z wątku interfejsu użytkownika, do wątku Kompozytora (co ma poprawić czas reakcji kontrolek na dotyk), bowiem wątek interfejsu użytkownika, jako główny wątek aplikacji, przypuszczalnie nadal będzie jedynym wątkiem, zdolnym ostatecznie odpowiedzieć na interakcję użytkownika z aplikacją, np. inicjując jakąś logikę biznesową. Poza tym do wątku interfejsu użytkownika należy obecnie też m.in. rysowanie elementów wizualnych po raz pierwszy, a można sobie wyobrazić, że może nastąpić to podczas wykonywania intensywnej pracy przez aplikację, w wyniku przewinięcia w tym czasie strony przez użytkownika.

Postrzegany czas odpowiedzi

Ważną cechą interfejsu użytkownika w środowisku o ograniczonej wydajności, jest zdolność do natychmiastowej odpowiedzi na bodźce użytkownika. W systemie Windows Phone 7 mocno akcentowane są animacje, więc jest to najbardziej oczywista forma odpowiedzi. Można np. wyświetlić animację ładowania strony lub okna wyskakującego, jeśli czynność ta będzie czasochłonna, aby zmniejszyć postrzegany czas odpowiedzi, czyli czas, po którym użytkownik może najpóźniej otrzymać odpowiedź, przy czym może to być także odpowiedź informująca jedynie, że należy czekać, a czas ten nie powinien przekraczać jednej sekundy.

Innym sposobem odpowiedzi, jest uruchomienie wibracji na 100 ms, czyli na najkrótszy możliwy czas, jako odpowiedzi na naciśnięcie przycisku, przed pokazaniem okna wyskakującego. Oczywiście ten sposób odpowiedzi nie powinien być nadużywany, a czas wibracji powinien być krótki, w przeciwnym wypadku użytkownik może potraktować go jako sygnał błędu.

Odpowiednia wielkość aktywnych elementów interfejsu użytkownika

Elementy interfejsu użytkownika, które można nacisnąć palcem, powinny być na tyle duże, aby nie zdarzało się często przypadkowe naciśnięcie niewłaściwych elementów. Jest to oczywiście implikacja użycia pojemnościowego ekranu dotykowego.

Przyjmuje się, że elementy te nie powinny być mniejsze, niż kwadrat o bokach 9 mm (ok. 34 pikseli) lub wyjątkowo 7 mm (ok. 26 pikseli) i nie powinny znajdować się bliżej siebie, niż w odległości 2 mm (ok. 8 pikseli).

Wybór właściwej klawiatury ekranowej

Jak wspomniano już w tym wpisie, znacząca większość obecnych na rynku telefonów z systemem Windows Phone 7 nie posiada klawiatury sprzętowej, więc jedynym na nich sposobem wprowadzania znaków jest klawiatura ekranowa (SIP).

System Windows Phone 7 pozwala ustalić (poprzez właściwość InputScope), jakiego rodzaju klawiatura będzie wyświetlana użytkownikowi, podczas wprowadzania znaków do konkretnego pola tekstowego. Dostępnych jest 10 podstawowych rodzajów SIP i różnią się one od siebie nie tylko dostępnością i układem klawiszy, ale także funkcjami takimi jak słownik i automatyczna wielka litera na początku. Wybór właściwej SIP z pewnością przyspiesza wprowadzanie danych, więc warto ustalić SIP dla każdego pola tekstowego.

No Responses to “Szczególne aspekty budowania aplikacji pod Windows Phone 7”

Kanał RSS z komentarzami do tego wpisu. TrackBack URL

Leave a Response