Urządzenia mobile vs emulatory

Jednym z najpopularniejszych tematów poruszanych przez blogerów i firmy, które chcą pokazać, że są "mobile aware" jest porównywanie emulatorów z fizycznymi urządzeniami. Niestety większość wpisów jest bardzo poglądowa i nie opisuje faktycznego stanu rzeczy. W pamięci czytelników pzoostaje jedynie informacja, że emulatory praktycznie zawsze są złe i nie powinno się z nich korzystać. Jest to według mnie krzywdzące dla tego tematu. Pewnego razu postanowiłem więc odpowiedzieć na jeden z wpisów, który pojawił się na blogu firmy SauceLabs (wtedy jeszcze TestObject).

Moja odpowiedź nie jest oczywiście idealna i nie została później przeredagowana. Ten tekst pisałem w chwilę po przeczytaniu artykułu i "na kolanie" siedziąc w pociągu :)

Odpowiadam na ten wpis: https://saucelabs.com/blog/mobile-device-emulator-and-simulator-vs-real-device

Nie mam nic do firm, które zamieszczają takie artykuły samych w sobie, ponieważ świadczone przez nich usługi są często na prawdę na wysokim poziomie. Oddziały techniczne są świetne a pracownicy przykładowo z TestDroid Wrocław to bardzo dobrzy specjaliści. Mam nadzieję, że kiedyś będę mógł odwiedzić wiele firm związanych z urządzeniami w chmurze, ponieważ temat i technologie są niezwykle inetresujące :)

Dlaczego wspominam o TestDroid? Ponieważ też popełnili nie jeden artykuł po którym podniosło mi się ciśnienie. Marketing mnie olał, komentarze usunął a na maile nie odpisał.

Dział marketingu jednak zasługuje według mnie na kopa w tyłek. Rozumiem, że to (zapewne) nie ich wina.

Sprzedaż, targety, deadline. Welcome to korporacja.

Tak niestety jest także w tym artykule. Rzetelność jest tylko i wyłącznie w najwyższej warstwie tekstu. W rzeczywistości każde hasło jest prawdą, wystarczy postawić je w odpowiednim kontekście. Więc samo rzucanie nimi nie jest według mnie ani wartościowe ani rzetelne.

Wpis jest bardzo ogólny, nie wchodzi w ogóle w szczegóły i nie edukuje czytelników.

Autorka jedynie rzuca hasłami, które tester bez doświadczenia czy też test lead lub manager rzuci na prezentacji lub użyje w celu zargumentowania kupna jakiegoś produktu.

No dobrze, pomarudziłem sobie - tak to może każdy. Prawda? W końcu jesteśmy w internetach.

Tak się złożyło, że siedzę sobie w pociągu, więc zamiast drzemki z racji braku internetu w naszych najnowocześniejszych pociągach uznałem, że pozwolę sobie skomentować rzetelność tego artykułu.

Postaram się przejść punkt po punkcie.

Nie jestem autorytetem na skalę kraju i jak każdy mogę się mylić. Chętnie przyjmę krytykę popartą własnym doświadczeniem.

Ja natomiast spróbuję na to spojrzeć z perspektywy kilku lat ramię w ramię z mobilem.

  • We will highlight advantages and disadvantages of both and we will also give an affordable solution to test on real devices, which are always a better choice!

Zawsze? Najprostszy przykład sytuacji w której fizyczne urządzenia nie są najlepszym rozwiązaniem: Fizyczne urządzenia mają opóźnienie w dostarczeniu premiera > sklep > tester. To samo w przypadku urządzeń w chmurze.

Są droższe, generalnie wymagają jakiejkolwiek inwestycji finansowej w przeciwieństiwe do emulatorów.

Patrząc z perspektywy porównania czas reakcji vs koszta emulatory wypadają najlepiej ze wszystkich dostępnych rozwiązań. Bierzemy wersję preview systemu i jedziemy ze wstępnymi testami nawet jeżeli nie mamy żadnych fizycznych urządzeń spełniających wymagania danego obrazu.

Jadąc teraz w pociągu w którym nie ma dostępu do internetu zestaw emulatorów jest najlepszym i najwygodniejszym sposobem na “szybki check” na kikudziesięciu zestawach konfiguracji. Chociażby przy tworzeniu testów automatycznych.

  • Mobile Device Emulator vs Simulator: What is the difference?

Jak najbardziej. Prawda. Jakby to ująć - fakty.

  • Advantages and disadvantages of simulators and emulators

Zasadniczo dobrze.

Disadvantages:

  • Mobile device emulators are very slow (because they simulate both hardware and software)

Emulatory są wolne jeżeli są uruchamiane niezgodne z założeniami, bądź bez wcześniejszego przemyślenia. Używając tego argumentu moglibyśmy napisać, że minusem gier jest to, że wszystkie i nie zawsze działają w ponad 60 fpsach.

Nie wspominając o tym, że jednak powinniśmy już mieć zasadzone w świadomości dostosowywanie sprzętu pod nasze potrzeby. Deweloperzy wielu Polskich banków rozpaczają pracując na starych macach przez długie ładowanie symulatorów czy też bardzo długie budowanie aplikacji, jednak jest to głównie wina długich i szeroko zakrojonych procesów bezpieczeństwa. A nie tego, że symulatory czy IDE działają wolno. To samo odnosi się do emulatorów. Nowe ADB o którym wspomniano na Google I/O czy też stary już Intel HAXM wspomagający dzięki procesorom oczywiście Intela. Można też w zależności od maszyny na której uruchamiamy emulator modyfikować wieloma parametrami takimi jak przydzielany RAM, czy też wspomaganie wydajnościowe hardware czy software. I nie tylko.

Osobnym tematem jest prędkość działania urządzeń fizycznych, które w wielu okolicznościach działają nawet wolniej.

  • A mobile device emulator doesn’t take into consideration factors like battery overheating/drainage or conflicts with other (default) apps

Nie bardzo rozumiem część w której autorka twierdzi, że emulatory mają problem z “conflicts with other (default) apps”.

To nie jest według mnie problem tylko emulatorów czy też nawet symulatorów. Jeżeli rozpatrujemy możliwe konflikty z preinstalowanymi aplikacjami (preinstalowanymi przez producentów czy operatorów) to w takim przypadku identyczny problem dotyczy wielu urządzeń z czystym androidem. Więc jest to bardziej problem dostosowywania środowiska testowego do swoich potrzeb. Jeżeli natomiast mówimy o konfliktach z aplikacjami instalowanymi przez użytkowników to tutaj emulatory mają wręcz w pewnym aspekcie przewagę nad fizycznymi urządzeniami, ponieważ nie będąc pracownikiem jednego z producentów urządzeń mobilnych możemy bez problemu zaprojektować sobie cały zestaw obrazów, które będziemy wrzucać na emulatory :)

W przypadku urządzeń fizycznych jesteśmy wciąż bardzo często blokowani różnymi zabezpieczeniami i groźbą utraty gwarancji. Nie licząc już przypadków losowych w którym możemy nasze urządzenie przemienić w cegiełkę.

  • Setting up a good emulator takes time and it is expensive

Kolejny punkt, który kompletnie nie wiem jak zinterpretować. Co autorka miała na myśli?

Patrząc z perspektywy historii takiego Androida skoro mówimy o emulatorach to czas jego postawienia waha się średnio pomiędzy 30 sekund a 5 minut w zależności od komponentów, które chcemy przygotować. Czyli tyle ile wyjęcie naładowanego gotowego do włączenia (i włączenie) urządzenia fizycznego z szafki. W końcu mówimy konkretnie o urządzeniach fizycznych wszelkiego typu a nie tylko tych w chmurze. Czy też wyjęcie rozładowanego urządzenia, które dodatkowo musimy podpiąć do zasilania, włączyć i wpisać hasło dostępu.

Czy emulatory są drogie? Kurcze, wydaje mi się, że jeżeli coś jest za darmo to nie jest to tak drogo.

Jednak oczywiście rozpatrzmy to rzetelniej. Jakie mamy emulatory?

Dostarczony od Google i dostarczane od firm zewnętrznych. Ten od Google, jest oczywiście w pełni darmowy.

Jeżeli chcemy aby urządzenie zachowało więcej parametrów podobnych do urządzenia fizycznego, czyli pełen pakiet GMS możemy skorzystać z emulatora jakiejś firmy zewnętrznej na przykład GenyMotion. Czy jest najlepszy? Nie wiadomo. Tak emulatory jak i urządzenia fizyczne służą innym celom i nie powinny być aż tak bezpośrednio porównywane z nakreślaniem, że trzeba wybrać.

Jest oczywiście wiele innych emulatorów jak Andyroid, Bluestack (świetny do gier!) jak też wiele innych.

Natomiast czy taki GM jest drogi? Skoro mówimy o kosztach. Kosztuje $299 za rok (12 miesięcy). Czy jest to cena wysoka to zależy od naszych potrzeb. GenyMotion daje następujące “dodatki”:

Jeżeli ich nie potrzebujemy to na pewno jest drogo. Jednak, po co w ogóle korzystać z GM skoro ich nie potrzebujemy? W takim przypadku wystarczyłoby skorzystać z emulatora Google. Jeżeli za wysoki koszt natomiast uznajemy regularne odpalanie testów na emulatorach po każdym buildzie na CI. W takim przypadku może nie potrzebujemy korzystać z testów jednostkowych na CI przy każdym buildzie? Może trzeba w fazie projektowania farmy serwerów pamiętać o procesorach intela i wsparciu HAXM? Może należy zoptymalizować same testy? A może pokrycie środowisk.

  • They may be incompatible with the app or app elements, meaning that you will need to create patches here and there to keep on using the emulator

Witamy w świecie mobilnym! Gdzie nakładki takich producentów jak Sony czy Samsung rozwalają pół aplikacji a pomysły rodem ze stajni HTC potrafią w ogóle uniemożliwić korzystanie ze zrobionych zdjęć przechowywanych w pamięci urządzenia :D Przedstawiony punkt zdecydowanie nie jest charakterystyczny dla emulatorów czy też nawet symulatorów.

No dobrze, idziemy dalej. Co gdyby faktycznie skupić się na emulatorach.

Możemy skorzystać z jednego z emulatorów, które emulują gotowe urządzenia (GM daje ze 40 zestawów) czy też wgrać GMS, dzięki któremu aplikacja powinna działać bez najmniejszego problemu. Jeśli nie działa, to trzeba zdecydowanie zastanowić się czy nie został popełniony błąd w samej aplikacji :) Co oczywiście mogło nie nastąpić, emulatory jak i fizyczne urządzenia to bardzo wybredne bestie.

  • Emulators may support only certain OS versions

Faktycznie, emulator Google wspiera (z miejsca) zaledwie wersje od Eclair (2.1) resztę obrazów trzeba niestety pobrać z internetów. Możliwe ktoś tworzy jeszcze aplikacje dla pączka.

Anyhow. Przyjmijmy, że autorka miała na myśli nakładki producentów i/lub operatorów. Faktycznie będąc testerem w firmie jedynie produkującej aplikacje nie mamy dostępu do odpowiednich obrazów. Jednak czy nei to samo dotyczy urządzeń fizycznych? Ponownie. Czy rozpatrujemy czy testować na urządzeniach fizycznych czy emulatorach. Dostosowujmy narzędzia do swoich potrzeb.

Patrząc z perspektywy porównania czas reakcji vs koszta emulatory wypadają najlepiej ze wszystkich dostępnych rozwiązań. Bierzemy wersję preview systemu i jedziemy ze wstępnymi testami nawet jeżeli nie mamy żadnych fizycznych urządzeń spełniających wymagania danego obrazu.

Advantages and disadvantages of mobile device simulator

Advantages:

  • Fast (because they simulate only the software)

Hahaha… :D No dobra pośmialiśmy się a teraz zapraszam do skorzystania z symulatora iOS na 5 letnim macu :) Sytuacja taka jak w przypadku wspomnianych wolnych emulatorów. Dostosujmy sprzęt do naszych potrzeb a wszystko będzie szybkie. Miejmy z jakiegoś powodu słąby sprzęt lub inne potrzeby a będziemy liczyć owce w trakcie budowania projektu czy ładowania obrazu systemu. Argument, że symulator jest szybki, ponieważ symuluje tylko oprogramowanie jest… trochę słaby. Jest mnóstwo czynników takich jak sprzęt na których uruchamiamy symulator, wsparcie systemowe, biblioteki zewnętrzne czy też samo Apple API, które potrafią bardzo namieszać. Argument jest bardzo, bardzo ogólny.

  • Relatively easy to set up

Ponownie. Wszystko zależy od konfiguracji, nie ma większej różnicy pomiędzy setupowaniem i dbaniem później o symulator niż o emulator.

  • Can be used to study the behaviour of an app

Emulatory i fizyczne urządzenia także. Więc ta zaleta powinna być wymieniona wszędzie.

Przykładowe emulatory warte sprawdzenia:

PreviousModyfikacja sieciNextFragmentacja

Last updated