En jämförelse mellan native-, hybrid- och webbapplikationer : En undersökning om applikationernas prestandaskillnader i användargränssnittet.

Postadress: Besöksadress: Telefon:

En jämförelse mellan

native-, hybrid- och

webbapplikationer

HUVUDOMRÅDE: Datateknik FÖRFATTARE: Victoria Dahlquist HANDLEDARE:Johan Kohlin

JÖNKÖPING 2018 maj

En undersökning om applikationernas

Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom [se huvudområde på föregående sida]. Författarna svarar själva för framförda åsikter, slutsatser och resultat. Examinator: Anna-Karin Cartstensen

Handledare: Johan Kohlin Omfattning: 15 hp (grundnivå)

Förord

Jag vill tacka Consid AB för förtroendet att genomföra studien och all det stöd som givits under arbetets gång. Jag vill även tacka min handledare Johan Kohlin som hjälpt mig med idéer samt givit mig värdefulla tips. Ett extra stort tack till Peter Larsson-Green som bidrog till strukturering samt planering av studiens experiment.

Abstract

Purpose – The purpose of this thesis is to examine which parameters may affect

application rendering of the user interface and how it differs in web application, hybrid application and native application. This thesis intends to answer the following research questions:

1. Which parameters can affect the rendering of the user interface on a mobile application?

2. How does the rendering of the user interface differ from web application, hybrid application and native application?

Method – The study uses a literature study to answer the first research question and

uses an experimental study in which a hypothesis and prediction are formulated and tested to answer the second research question.

Results – The result of the study shows that the performance of the native application’s

user interface does not always perform better when performing the same task as the corresponding web and hybrid application. The web application in general had the best performance in the user interface, while hybrid application often performed inferior to the corresponding application types.

Implications – The study contributes to extend the knowledge of native application’s,

hybrid application’s and web application’s performance in the user interface, and can give companies and developers reference data to base their decision on the choice of application type. The study shows that all application types are worth considering, but the web and native application performed slightly better.

Limitations – No long-term tests could be compared because ADB does not read

graphical data for web applications and Chrome DevTools cannot perform long running tests.

Keywords – Native Application, Hybrid Application, Web Application, JavaScript,

Sammanfattning

Syfte - Syftet med studien är att undersöka vilka parametrar som kan komma att

påverka applikationens rendering av användargränssnittet samt hur den skiljer sig i webbapplikation, hybridapplikation och nativeapplikation. Denna undersökning har för avsikt att besvara följande frågeställningar:

1. Vilka parametrar kan påverka rendering av användargränssnittet på en mobil applikation?

2. Hur skiljer sig renderingen av användargränssnittet hos webbapplikation, hybridapplikation och nativeapplikation?

Metod - Studien använder sig av en litteraturstudie för att besvara första

frågeställningen och en experimentell studie där en hypotes samt förutsägelse formuleras och testas för att besvara andra frågeställningen.

Resultat – Resultatet från studien visar att nativeapplikationen inte alltid ger bättre

prestanda vid utförande av samma uppgifter gentemot motsvarande webb- och hybridapplikation. Webbapplikationen hade genomgående bäst prestanda i användargränssnittet, medan hybridapplikation ofta gav sämre prestanda än de motsvarande applikationstyperna.

Implikationer - Studien bidrar till att utvidga kunskapen inom native-, hybrid- och

webbapplikationers prestanda i användargränssnittet och kan ge företag samt

utvecklare referensdata att grunda deras val av applikationstyp på. Studien påvisar att alla applikationstyper är värda att överväga, men webb- och nativeapplikationen presterade något bättre.

Begränsningar - Inga långtidstester kunde jämföras eftersom ADB inte läser av

grafiskdata för webbapplikationer och Chrome DevTools inte kan utföra långa tester.

Nyckelord - Nativeapplikation, Hybridapplikation, Webbapplikation, JavaScript,

Innehållsförteckning

1

Introduktion ... 1

1.3 SYFTE OCH FRÅGESTÄLLNINGAR ... 4

1.4 OMFÅNG OCH AVGRÄNSNINGAR... 4

1.5 DISPOSITION ... 5

1.6 BEGREPPSDEFINITION ... 6

2

Metod och genomförande ... 9

2.1 KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH METOD... 9

2.2 EXPERIMENT ... 9

2.2.1 Hypotes och förutsägelse ... 10

2.3 ARBETSPROCESSEN ... 10 2.3.1 Utvecklingsmiljöer ... 11 2.3.2 Enhet ... 11 2.3.3 Implementering ... 11 2.3.4 Datainsamling ... 16 2.4 DATAANALYS... 19 2.5 TROVÄRDIGHET ... 20

3

Teoretiskt ramverk ... 22

3.1 KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH TEORI ... 22

3.2 TIDIGARE FORSKNING ... 22

3.3 FPS ... 23

3.4 GPU OCH CPU ... 23

3.5 MOBILA APPLIKATIONER ... 26 3.5.1 Batterianvändning ... 27 3.5.2 Minnesanvändning ... 28 3.5.3 Webbapplikationer... 29 3.5.4 Hybridapplikationer ... 38 3.5.5 Nativeapplikationer ... 40

4

Empiri ... 44

5

Analys ... 54

5.2.5 Generell analys för alla test-vyer ... 59

5.2.6 Resultat av analys ... 59

6

Diskussion och slutsatser ... 60

6.1 RESULTAT ... 60

6.2 IMPLIKATIONER ... 63

6.3 BEGRÄNSNINGAR ... 63

6.4 SLUTSATSER OCH REKOMMENDATIONER ... 64

6.5 VIDARE FORSKNING ... 65

Referenser ... 66

Figurförteckning

Figur 1. Modell över tillvägagångssättet för den experimentella metoden. ... 10

Figur 2. Meny-vyn för nativeapplikation, webbapplikationen och hybridapplikationen. ... 12

Figur 3. Interaction-vyn för nativapplikation, hybridapplikation och webbapplikation. ... 13

Figur 4. Loading icon-vyn för nativapplikation, hybridapplikation och webbapplikation. ... 14

Figur 5. Animation-vyn för nativapplikation, hybridapplikation och webbapplikation. ... 15

Figur 6. Static View-vyn för nativapplikation, hybridapplikation och webbapplikation. ... 16

Figur 7. En modell över ett objekts väg för att målas ut på skärmen. ... 25

Figur 8. Beskrivande bild av en pixel pipeline och dess fem delar (Lewis, 2017). ... 29

Figur 9. Beskrivande bild av pixel pipeline där webbläsaren inte utför layout (Lewis, 2017). 30 Figur 10. Beskrivande bild av pixel pipeline där webbläsaren inte utför layout eller paint (Lewis, 2017). ... 31

Figur 11. Arkitektur för en hybridapplikation (Gok & Khanna, 2013) ... 39

Figur 12. Diagram över renderingstiden för varje bildruta i Loading icon för alla applikationstyper. ... 46

Figur 13. Diagram över renderingstiden för varje bildruta i Interaction för alla applikationstyper. ... 49

Figur 14. Diagram över renderingstiden för varje bildruta i Animation för alla applikationstyper. ... 52

Tabellförteckning

Tabell 2. Beräkningar för webbapplikationen ... 20

Tabell 3. Medelvärden på de tre applikationstypernas användning av RAM-minnet för de fem respektive testerna i Loading icon-vyn. ... 44

Tabell 4. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn. ... 45

Tabell 5. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn. ... 46

Tabell 6. Medelvärden på de tre applikationstypernas CPU-användningen av de fem respektive testerna i Loading icon-vyn. ... 46

Tabell 7. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Loading icon-vyn. ... 47

Tabell 8. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Interaction-vyn. ... 47

Tabell 9. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn. ... 48

Tabell 10. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn. ... 49

Tabell 11. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Interaction-vyn. ... 49

Tabell 12. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Static View-vyn. ...50

Tabell 13. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Static View-vyn. ...50

Tabell 14. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Static View-vyn. ...50

Tabell 15. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Animation-vyn. ... 51

Tabell 16. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn. ... 51

Tabell 17. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn. ... 52

Tabell 18. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Animation-vyn. ... 53

Tabell 19. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Animation-vyn. ... 53

1

Introduktion

I detta avsnitt ges en bakgrund till studiens problemområde för mobila applikationer och som studien bygger upp kring samt vad studien skall fördjupas inom.

1.1 Bakgrund

Under de senaste sex åren har användandet av internet i mobiler ökat och enligt en undersökning som gjordes 2016 av internetstiftelsen i Sverige (IIS) använder den svenska befolkningen internet 24 timmar i veckan. Cirka nio timmar av dessa är via mobilen och detta är en ökning med en timme sedan år 2015. Hela 81 procent av svenska befolkningen ägde 2016 en smarttelefon och användningen av mobila applikationer ökar ständigt, vilket gör det till ett intressant marknadsområde (Davidsson and Findahl, 2016).

Alla företag inom handel oavsett produkt, säljkanal eller branschtillhörighet påverkas av utvecklingen inom mobila applikationer och tillgänglighet. Denna typ av digitalisering förändrar kunders köpbeteende och skapar ett bredare utbud, både från landets aktörer och från de utländska. Digitaliseringen ger stora möjligheter för företagen att förbättra köpupplevelsen och kundrelationen, dock krävs ett balanserat, harmoniserat och teknikneutralt regelverk för att fördelaktigt kunna gynnas av digitaliseringen (Svenskt Näringsliv, 2016).

Mobila applikationer har med teknikens utveckling blivit ett intressant område för både företag och utvecklare marknadsområde (Davidsson and Findahl, 2016). Diskussionerna är stora kring vilken av de olika mobila applikationstyperna som bör utvecklas och åsikterna är spridda. Native-, hybrid- och webbapplikationer är de olika typerna som oftast omfattas av diskussionerna och de har alla sina för- och nackdelar. I de följande styckena kommer dessa att diskuteras mer ingående.

1.1.1 Native

En native mobilapplikation är benämningen på en applikation som är specifikt utvecklad för ett operativsystem och några bestämda enheter. Dessa applikationer har tillgång till enhetens mjuk- och hårdvara, vilket ger dem åtkomst till funktionaliteter som kamera och globala position system (GPS). Nativeapplikationen lagras på användarens enhet genom nerladdning från en app-butik och behöver manuellt uppdateras av användaren. Med rätt implementation kan applikationen även användas

utan tillgång till internetuppkoppling. Android och iOS är två operativsystem som många nativeapplikationer har utvecklats till och de använder sig av olika programmeringsspråk. Operativsystemet Android finns på ett flertal enheter med olika tillverkare, som Samsung och LG. Applikationerna till Anroid utvecklas oftast i programmeringsspråket JAVA. Operativsystemet iOS kan till skillnad från Android endast användas på enheter som tillverkats av Apple, exempelvis en iPhone och applikationerna utvecklas i programmeringsspråken Objectiv-C eller Swift (Georgiev, Jana & Shmatikov, 2014). I resterande delar av rapporten kommer denna applikationstyp att benämnas som nativeapplikation.

1.1.2 Webb

En mobil webbapplikation är egentligen en ordinarie hemsida, men utvecklad för att ge ett mobil-anpassat beteende. En mobil webbapplikation existerar i en webbläsare och är plattformsoberoende, vilket innebär att den fungerar på alla enheter oavsett operativsystem. En mobil webbapplikation bygger på programmeringsspråken HTML, CSS och JavaScript som tillsammans gör det möjligt att skapa en webbapplikation som påminner om en nativeapplikation (Georgiev, Jana & Shmatikov, 2014). JavaScriptkod behöver till skillnad från en nativeapplikation först tolkas och kompileras till maskinkod innan den exekveras genom en JIT-kompilator av webbläsaren (Laurens 2013). En mobil webbapplikation har inte direktåtkomst till enhetens alla hårdvarugränssnitt, men med HTML5 kan applikationen ges åtkomst till exempelvis geolocation, accelerometer och mikrofon (W3C, u.å.). En mobil webbapplikation kan sparas ner på enheten om användaren önskar detta och applikationen behöver aldrig uppdateras manuellt eftersom det sker automatiskt (Georgiev, Jana and Shmatikov, 2014). I resterande delar av rapporten kommer denna applikationstyp benämnas som webbapplikation.

1.1.3 Hybrid

En webbaserad hybrid mobilapplikation är en blandning mellan en webb- och nativeapplikation. Precis som en webbapplikation är den plattformsoberoende och använder sig av programmeringsspråken HTML, CSS och JavaScript. Precis som en nativeapplikation har en webbaserad hybrid mobilapplikation tillgång till lokala enhetsresurser som mikrofon. Hybrida mobilapplikationer kan utvecklas med hjälp av specifikt utformade ramverk för denna typ av applikationer som exempelvis PhoneGap,

men även av nativebiblioteken själva som exempelvis Android (Georgiev, Jana & Shmatikov, 2014). Det finns inbyggd funktionalitet inom Android som möjliggör att en webbapplikation kan presenteras direkt i nativeapplikationen som Webview. Det finns även funktionaliteter som JS-Java Bridge i Android som gör det möjligt för webbdelen att integrera med nativedelen (Gok & Khanna, 2013). En hybridapplikation kan skapas på många olika vis men det generella för en webbaserad hybrid mobilapplikation brukar vara att först tillhandahålla en inbäddad webbläsare som kör applikationens webbkod, exempelvis genom Webview. Webbkoden tillåts sedan att gå utanför webbläsaren och erhålla tillgång till lokala resurser (Georgiev, Jana & Shmatikov, 2014). I resterande delar av rapporten kommer denna applikationstyp benämnas som hybridapplikation.

1.1.4 Uppdragsgivare

Studien utförs på uppdrag av Consid i Jönköping som är ett konsultföretag som erbjuder marknaden konsultering inom IT, management samt digital marknadsföring. Deras arbetsområde är brett och marknadsberoende, vilket resulterar i att de bland annat arbetar med området mobila applikationer. En jämförelse mellan de olika mobila applikationstyperna är av stort intresse för både Consid och deras kunder. En rekommendation är tänkt att tas fram och användas som grund till beslutsfattande val och konsultering gällande framtida mobila applikationer.

1.2 Problembeskrivning

Den växande marknaden inom mobila applikationer och de åtskilliga valmöjligheterna inom applikationstyper gör det komplicerat för företag att fatta beslut gällande vilken applikationstyp som är mest lämpad för det specifika syftet. Det finns för- och nackdelar med alla mobila applikationstyper beroende på applikationens ändamål, vilket är en aspekt både företag och utvecklare bör ta hänsyn till. Exempelvis har nativeapplikationer tillgång till enheternas inbyggda mjuk- och hårdvara, men kan endast användas på ett specifikt operativsystem. För att ge åtkomst till applikationen på alla mobila operativsystem behöver ett flertal applikationer utvecklas.

Webbapplikationer är istället tillgängliga på alla enheter, men har inte direktåtkomst till enhetens alla hårdvarugränssnitt. Hybridapplikationer kan återanvända hemsidan i

applikationer till alla olika mobila operativsystem, dock krävs det fortfarande utveckling av både en hemsida och minst en mobilapplikation.

Det finns flera viktiga faktorer vid val av en applikationstyp och en av dem är prestandan. Tidigare undersökningar har gjorts gällande eventuella prestandaförluster på native- och hybridapplikationer där applikationens syfte varit att sortera och hantera data (Nilsson & Lagerqvist, 2015). Det är dock även av intresse för utvecklare samt företag att veta vilka parametrar som kan komma att påverka applikationens prestation i ett användargränssnitt (AppDynamics, 2014).

1.3 Syfte och frågeställningar

Syftet med studien är att undersöka vilka parametrar som kan komma att påverka rendering av en applikations användargränssnitt samt hur de skiljer sig i webbapplikation, hybridapplikation och nativeapplikation.

Denna undersökning har för avsikt att besvara följande frågeställningar:

1. Vilka parametrar kan påverka rendering av användargränssnittet på en mobil applikation?

2. Hur skiljer sig renderingen av användargränssnittet hos webbapplikation, hybridapplikation och nativeapplikation?

1.4 Omfång och avgränsningar

Studiens omfång är begränsat för att motsvara ett examensarbete på Tekniska Högskolan i Jönköping. Studien kommer avgränsas genom att endast använda och utveckla applikationer till operativsystemet Android samt utföra tester på enbart en enhet.

1.5 Disposition

Resterande delar av rapporten är disponerad enligt följande:

Kapitel 2 – Metod och genomförande

Vald forskningsmetod beskrivs samt en beskrivning av studiens arbetsprocess.

Kapitel 3 – Teoretiskt Ramverk

Relevant teori för studiens område redogörs.

Kapitel 4 – Empiri

Presentation av data som införskaffats genom metoden som beskrevs i kapitel 2.

Kapitel 5 – Analys

Insamlad data behandlas och de givna frågeställningarna besvaras.

Kapitel 6 – Diskussion och Slutsatser

1.6 Begreppsdefinition

Vanliga begrepp som används i denna studie definieras nedan:

Rendering – är den beräkning ett datorprogram utför för att framställa en bild eller

animering på en enhet (Slick, 2017).

FPS – står för Frames Per Second och är mätvärde på antal bildrutor som renderas under

en sekund (Techopedia, u.å.).

Refresh Rate – ett mätvärde som bestämmer hur många gånger skärmen ska

räknas/renderas om varje sekund. Om refresh rate understiger 60 Hz kommer bildflimmer vara synligt vilket innebär att skärmen synbart omräknas och inte visar en konstant bild (Techopedia, u.å.).

Main thread – när ett program startar upp, börjar en tråd köra direkt. Detta kallas oftast

för main thread av programmet och är den som exekveras när programmet börjar (Android Developers, u.å.).

DOM – The Document Object Model är ett gränssnitt som tillåter ett

programmeringsspråk att manipulera innehåll, struktur och style på en webbapplikation (W3C, 2005).

Web Workers – är en tråd som utför script i bakgrunden för att kunna hålla Main thread

mottaglig för användarinteraktioner (Niranga, 2015).

Selektorer – en mall/modell/struktur som används för att välja vilket/vilka element som

skall designas. Selektorer kan vara klass och id, där dessa attribut sätts för att sedan kunna hantera design med alla element med samma klass eller id på samma sätt (Bermes, 2015).

Head – är ett element som innehåller metadata och inte visas på skärmen. Metadata

Pixel pipeline – en process som sker när en applikation skall rendera ut pixlar på

skärmen (RMIT University, u.å.).

Opacity – är ett CSS attribut som specificerar hur transparant ett element skall vara

(W3C, u.å.).

Transform – är ett CSS attribut som tillämpar en 2D eller 3D transformation på ett

element. Dessa transformationer kan vara i form av att rotera, skala eller flytta ett element (Lewis, 2017).

Style-sheet – är en fil med samling av style-regler för element, exempelvis teckensnitt

och färg (W3C, u.å.).

Inline Styles – är när style-regler applicerar inuti en HTML tagg genom att använda

style-attributet (W3C, u.å.).

Request – när webbläsaren begär data (exempelvis en HTML-sida eller en bild) av en

webbserver och webbservern skickar tillbaka ett svar (IETF, 2014)

Overdraw – när en pixel målas om mer än en gång inom en och samma bildruta

(Android Developers, u.å.).

Nästlade vyer – när exempelvis flera layouts används i varandra och objekt ligger

nästlade där i (Sillars, 2015).

ConstraintLayout – inbyggd layout i Android som tillåter utvecklare att skapa en stor

och komplex layout utan vy-hierarki och nästlade vyer (Android Developers, u.å.).

RelativeLayout – inbyggd layout i Android som tillåter utvecklare att skapa layout

utan vy-hierarki samt nästlade vyer. Denna layout gör det möjligt att placera element efter relation med andra element (Android Developers, u.å.).

Källskript – Är ett skript med flertal kommandon som utförs av en kommandotolk

(Techopedia, u.å.).

Engelska termer kommer att användas i rapporten för att innehållets innebörd inte skall förloras eller skapa förvirring vid översättning. De flesta engelska ord kommer antingen att förklaras i text eller är förklarade i begreppsdefinitionslistan ovan.

2

Metod och genomförande

I detta avsnitt ges en översiktlig beskrivning av studiens metod och hur den genomförs. Avsnittet beskriver även hur studiens data samlas in och sedan analyseras.

2.1 Koppling mellan frågeställningar och metod

En litteraturstudie utförs först för att kunna besvara första frågeställningen ”Vilka

parametrar kan påverka rendering av användargränssnittet på en mobil applikation?”.

Litteraturstudie ansågs som en lämplig metod för att besvara denna frågeställning eftersom det redan finns befintliga kunskaper inom området och det ger även teori att grunda experimenten på i den andra frågeställningen.

För att besvara andra frågeställningen ”Hur skiljer sig renderingen av

användargränssnittet hos webbapplikationer, hybridapplikationer och nativeapplikationer?” utförs en experimentell studie. Experimentell studie ansågs som en

lämplig metod för att besvara andra frågeställningen då tidigare forskning inte täcker denna frågeställning och de framtagna parametrarna kan testas i en kontrollerad miljö.

2.2 Experiment

Enligt Wohlin (2012) görs experiment oftast i en laboratoriemiljö, vilket ger en hög kontrollnivå och experiment används för att stödja eller motbevisa en hypotes, teori eller modell. Vid en experimentell studie är det viktigt att hela experimentet kommer vara upprepningsbart under liknande omständigheter för att andra forskare skall kunna använda, pröva, motbevisa eller bygga vidare på forskningen (Claes Wohlin et al., 2012). Den experimentella metoden kommer följa den förenklade modellen i Figur 1 och i enlighet med denna modell ställs först en fråga som i det här fallet är den andra frågeställningen. Efteråt utförs en bakgrundsforskning som skall medföra en grundförståelse för ämnet samt ger en tillräcklig bas för formulering av en hypotes. Bakgrundsforskningen hjälper även till att besvara första frågeställningen, vilket ger vilka parametrar som kan komma att påverka renderingen. Med hjälp av bakgrundsforskningen och andra frågeställningen skapas en hypotes som skall vara av en generell princip. En förutsägelse används för att falsifiera eller verifiera hypotesen samt att grunda experimenten på. Förutsägelsen ger en kort förklaring till hur undersökaren tänker pröva hypotesen och vad som användas för att påverka resultatet. Experimenten designas utefter hypotesen och förutsägelsen och samlar in en mängd data. All data som erhålls från experimenten kommer analyseras för att sedan kunna dra slutsatser där hypotesen antingen

kommer falsifieras eller verifieras. Slutligen kommer resultatet att dokumenteras och presenteras i rapporten i form av text och tabeller.

2.2.1 Hypotes och förutsägelse

Eftersom både hybridapplikation och webbapplikation består av bland annat JavaScript-kod, kommer applikationernas kod först tolkas eller kompileras till maskinkod innan exekvering och detta kan påverka prestandan (Google, u.å.). Enligt tidigare forskning som gjorts av Nenzén (2014) väljs nativeapplikationer för att de upplevs som att de har bättre prestanda. Därav formuleras hypotesen enligt:

Nativeapplikationer presterar bättre än både hybrid- och webbapplikationer vid utförande av identiska uppgifter.

Förutsägelsen för hypotesen är:

Vid utförande av identiska uppgifter kommer nativeapplikationer alltid erhålla bättre resultatvärde än hybrid- och webbapplikation på samma enhet.

2.3 Arbetsprocessen

Litteraturstudien baseras på vetenskapliga artiklar, böcker och dokumentation från relevanta utvecklingsföretag. Artiklarna och böckerna kommer ifrån databaserna Google Scholar och Primo. All väsentlig teori dokumenteras och ligger till grund för experimenten i den andra frågeställningen. En webbapplikation, en hybridapplikation och en nativeapplikation kommer att utvecklas med ett liknande

Ställ en fråga Gör bakgrunds _forskning Skapa en _hypotes

Dokumentera resultatet

Analysera och

dra slutsatser _experimentet Utför

användargränssnitt. Alla experiment kommer ske i en kontrollerad miljö och med kontrollerad miljö menas att inställningar och applikationer på enheten som kan påverka experimentets resultat kommer att stängas av och förhållandena kommer att hållas lika mellan testerna. Experimenten kommer att mäta användningen av RAM-minnet, CPU:s minnesanvändning, GPU:s minnesanvändning samt batterianvändning. Hur experimenten implementerades och utfördes beskrivs i avsnitt 2.3.3 och 2.3.4.

2.3.1 Utvecklingsmiljöer

Nativeapplikationen och skalet till hybridapplikationen utvecklas i Android Studio med version 2.3.3 och i programmeringsspråket JAVA. Webbapplikationen utvecklas med Atom i programmeringsspråken HTML, JavaScript och CSS. Hybridapplikationen använde sig också av koden som utvecklades till webbapplikationen.

2.3.2 Enhet

Experimenten utförs på en Android-enhet med AMOLED-skärm samt med Android som operativsystem. Enheten är en Samsung Galaxy S6, modellnummer SM-G920F med Android Nougat version 7.0.

2.3.3 Implementering

För att besvara andra frågeställningen utvecklades tre applikationer: en native-, en hybrid- och en webbapplikation. Applikationerna har motsvarande vyer och dessa vyer skall representera aktiviteter som kan förekomma i verkliga applikationer. Första synliga vyn i alla applikationer är en enkel meny med fyra knappar som leder användaren till de fyra olika test-vyerna, se Figur 2. Denna vy skapar en lättarbetad navigering för att underlätta utförandet av studiens experiment, men ingen data erhålls från denna vyn. Hybridapplikationen använder sig av webbapplikationens kod och därav dess vyer som nås genom Androids WebView-modul. Applikationerna har utvecklats i största möjligt mån efter rekommendationer från första frågeställningen. Därav har faktorer som overdraw, hierarki, nästlade vyer, framework, bibliotek och onödiga omberäkningar samt ommålningar undvikts. Samtidigt som transform och ConstraintLayout har använts vid utveckling utefter dessa rekommendationer.

Vyn Interaction skall representera en användares interaktion med applikationen och denna interaktion är i det här fallet ett finger som drar en fyrkantig ruta. De parametrar som kommer att mätas i denna vy är användning av CPU, användning av GPU, användning av RAM-minnet, totalt antal bildrutor som renderades och renderingstiden för varje bildruta. I testerna sker interaktionen via kod för att alla tester skall utföras exakt likadant och inga mänskliga faktorer skall påverka resultatet. Den automatiserade dragningen sker från kant till kant och resultatet blir att bilden dras runt i en fyrkant. Alla applikationer använder samma bild som tagits från samma källa, se Figur 3. I nativeapplikationen består fyrkanten av en Imageview som innehåller bilden och som ligger i en RelativeLayout, se Bilaga 1. RelativeLayout är en inbyggd layout som presenterar vyer och dess barn-vyer i relativa positioner. RelativeLayout användes för att det skulle fungera att endast flytta på själva bilden och inte hela vyn, med den koden som skrivits. I koden sätts OnTouchListener på Imageviewn som kontrollerar om användaren rör på bilden. Vid beröring kontrolleras Imageviewns position i koordinater och förflyttas sedan med hjälp av margins, se Bilaga 2. Webb- och hybridapplikationen använder sig av en img-tagg som fylls med bilden och som använder sig av EvenListener i JavaScript-koden. Testernas EventListener är en form av interaktionshanterare och kontrollerar om användaren rör eller drar i bilden. Bilden förflyttas sedan med hjälp av transform, se Bilaga 3.

Loading icon är en annan test-vy som utvecklades och denna vy skall representera när

en enstaka animation körs i applikationen. I alla applikationer innehåller vyn en knapp som startar en snurrande cirkel, se Figur 4. En loading icon valdes som animation eftersom det är vanligt att den typen av animation förekommer i applikationer för att upplysa användaren om att något laddas. De parametrar som mäts är batterianvändning, användning av CPU, användning av RAM-minnet, totalt antal bildrutor som renderades, renderingstiden för varje bildruta och användning av GPU. Animationstiden bestämdes i koden och kunde enkelt ändras efter önskad tid för de olika experimenten. I nativeapplikationen används ConstraintLayout och i den ligger en knapp samt Android inbyggda progressbar, se Bilaga 4. På knappen sitter OnClick-funktionalitet som känner av när knappen blir nedtryckt och då blir progressbaren synlig. Vid knapptrycket startas även en räknare som räknar ner den angivna tiden i koden och vid noll försvinner progressbaren igen, se Bilaga 5. Webb- och hybridapplikationen använder sig av EventListener på knappen som startar en funktion som i sin tur startar en räknare och även visar en loading icon genom en div-tagg med klassen loader. Med hjälp av CSS-kod efterliknades div-taggen Androids runda

progressbar. Div-taggen roteras sedan med hjälp av transform och objektet försvinner när räknaren blir noll, se Bilaga 6.

Vyn Animation innehåller 20 snurrande fyrkanter med en bild som är densamma för alla applikationers vyer och kommer från samma källa, se Figur 5. Vyn skall representera en applikation som utför många animationer på en och samma gång, därav flera snurrande objekt. Alla animationer startas automatiskt när användaren kommer in i vyn och parametrar som batterianvändning, användning av RAM-minnet, användning av CPU, totalt antal bildrutor som renderades, renderingstiden för varje bildruta och användning av GPU kommer mätas. I nativeapplikationen används ConstraintLayout som innehåller 20 fragment, se Bilaga 7. I fragmentet finns en ImageView som fylls med den valda bilden och det är fragmentets JAVA-kod som startar samt anger hur bilden skall rotera, se Bilaga 8. Webb- och hybridapplikationen använder sig av 20 img-taggar som innehåller bilden och som roteras med hjälp av transform, se Bilaga 9.

Vyn Static view är en statisk vy som skall representera en vy där användaren exempelvis läser innehållet, men inte utför någon interaktion med applikationen. Vyn består av en bild som är densamma för alla applikationer, en editerbar textruta med exakt samma text, två radio-buttons, två checkboxar och två knappar, se Figur 6. Denna vy skall ge en uppfattning om hur de olika applikationerna påverkas utan att något inträffar eller ändras och dessa tester mäter parametrar som batterianvändning, användning av CPU, användning av RAM-minnet, totalt antal bildrutor som renderades, renderingstiden för varje bildruta och användning av GPU. Nativeapplikationen använder ConstraintLayout och i den ligger inbyggda Android-objekt som ImageView och Checkbox. Dessa objekt placeras sedan ut med hjälp av constrains, se Bilaga 10. Webb- och hybridapplikationen använder sig av en img-tagg, en textarea, två button-taggar och en osorterad lista som innehåller input-taggar av typerna radio button och checkbox, se

Bilaga 11.

2.3.4 Datainsamling

Studiens datainsamling består dels av en litteraturstudie för att kunna besvara första frågeställningen och dels av empiriskdata insamlad från experimenten för att besvara andra frågeställningen. Experimenten för att mäta RAM-minne, CPU-användning, rendering av bildrutor och GPU-användning på alla test-vyer utförs på exakt samma sätt fem gånger på varje applikationstyp och varje test varade i 60 sekunder. Testerna utfördes fem gånger på varje test-vy för att minimera att tillfälliga avvikelser påverkade resultatet och för att eventuella felaktiga mätningar som exkluderas inte skall påverka det slutgiltiga resultatet. Experimenten för att mäta batterianvändningen utförs endast tre gånger på vyerna Loading icon, Static view och Animation i alla applikationstyper, men varje test varar i 30 minuter. Testerna valdes att utföras i 30 minuter för att minimera eventuella tillfälliga avvikelser och för att framhäva en större förändring i batterianvändningen. Batteri-testerna utförs endast tre gånger på varje test-vy för varje applikationstyp för att alla tester skulle hinnas med under testperioden. Innan testerna genomfördes sattes enheten alltid i flygplansläge samt startades enheten om för att minimera risken att bakomliggande applikationer samt sparad data skulle påverka resultatet. För att kunna använda en webbapplikation i flygplansläge måste filerna

sparas ner (cachas) på enheten och detta utförs genom att använda en service worker. En service worker är ett script som webbläsaren kör i bakgrunden och utvecklas i studien för att kunna använda webb- och hybridapplikationen utan nätverksåtkomst.

För att utföra alla tester som mäter rendering av bildrutor, RAM-minne, CPU-användning och GPU-CPU-användning kopplades testenheten till en dator via en USB-kabel. För att mäta av native- och hybridapplikationen användes ADB (Android Debugging Bridge) samt egenskrivna källscript och för att mäta av webbapplikationen användes Chrome DevTools samt egenskrivna källscript. ADB är vad Android (u.å.) kallar ett mångsidigt kommandoverktyg som gör det möjligt att kommunicera med en enhet. Via ADB erhölls antal bildrutor renderade under testet, renderingstiden per bildruta angivet i ms, antal ojämna bildrutor under testet, GPU:s minnesanvändning angivet i MB, användning av RAM-minnet angivet i MB och CPU-användning angivet i procent. Chrome DevTools innehåller en samling utvecklingsverktyg för webben och är inbyggd i webbläsaren Google Chrome (Google Developer, 2018). Via Chrome DevTools erhölls renderingstiden per bildruta angivet i ms, GPU:s minnesanvändning angivet i MB, användning av RAM-minnet angivet i MB och CPU-användning angivet i procent. Bas-källscriptet som skrevs säger åt ADB att tömma all insamlad data och sedan faller scriptet ner i sleep så länge som bestämts i koden och när scriptet går ur sleep samlas den önskade data in från ADB, se Bilaga 12. Beroende på vilket test som skall utföras anropas olika källscript från bas-källscriptet och varje experiement startas på den vy som skall testas.

För testerna i Loading icon-vyn sker ett automatiserat klick av bas-källscriptet på startknappen för att alla tester skall starta och börja mäta samtidigt. För testerna i Interaction-vyn finns två olika källscript som kan anropas av bas-källscriptet, ett för hybrid- och nativeapplikationen och ett eget script för webbapplikationen. Det behövs två olika script för att dragningsfunktionaliteten bygger på koordinater som talar om var dragningen skall börja och sen sluta. Objektet har inte exakt samma startkoordinat för applikationerna och därav behövs två olika script. Dessa två script har varsin while-loop som ser till att objektet fortsätter att dras tills testets bestämda sluttid. Dragningen som sker kant till kant har en bestämd tid hur lång tid det får ta. Scriptet för hybrid- och nativeapplikationen kan ses i Bilaga 13 och scriptet för webbapplikationen kan ses i

Bilaga 14. För alla tester anropas ytterligare två källscript av bas-källscriptet och det

ena scriptet är för att mäta CPU:ns utnyttjandegrad och det andra scriptet är för att erhålla mätningar från RAM-minnet och grafiken, se Bilaga 15–16. Alla applikationer använder de nämnda källscripten ovan, men för webbapplikationen kunde ADB inte ge data för grafiken utan istället fick Chrome DevTools användas. I Chrome DevTools hämtades data från timelinen via konsolen. Alla korttidstester filmades i 240 FPS på en iPhone 8 för att kunna kontrollera eventuella synliga resultat på skärmen samt jämföra detta mot den insamlade data.

För att mäta batterianvändningen gick det inte att ha enheten ihopkopplad med en dator via en USB-kabel. Det går inte att stänga av laddnings funktionaliteten som automatiskt sker varje gång ström tillförs via USB-kabel. Av den anledningen utfördes inga batterimätningar i Interaction-vyn eftersom automatiserade dragningar sker via källscript från datorn. Manuella dragningar ansågs frambringa en stor mänsklig faktor som skulle kunna påverka resultat och istället beslutades det att inga batterimätningar skulle utföras i Interaction-vyn. Testenheten hade även en maxtid den tillät skärmen vara tänd utan att någon form av interaktion skedde och denna tiden var på 10 minuter. Testerna för att mäta av batterianvändningen skedde i 30 minuter där enheten vid start var fulladdad och dess exakta värden lästes snabbt innan testets start. Mätningen utfördes genom att snabbt koppla in enheten till en dator med USB-kabel och säga åt ADB att hämta batteri-värdet på enheten. Via ADB erhölls nivå som är en skala där 100 anses vara ett fulladdat batteri och noll anses vara ett urladdat batteri. Det erhölls även spänning i millivolt. USB-kabeln togs sedan bort och testet startade direkt efter. En timer sattes på åtta minuter och upprepades tre gånger och varje gång timern blev noll utfördes ett snabbt tryck på skärmen för att hålla skärmen igång. Andra alternativ för att hålla enhetens skärm igång var antingen att använda en applikation som ligger och kör i bakgrunden eller utföra rooting på enheten. Rooting är en typ av manipulering av enhetens källkod och kan ses som olagligt inom Europa (Directive 2009/24/EC). Applikationerna som finns för att hålla en skärm vaken skickar olika former av processer i bakgrunden, vilket resulterar i att den också påverkar batterianvändningen. Av dessa anledningar valdes ett snabbt tryck som skedde var åttonde minut på alla tester. När testerna hade pågått i 30 min kopplades enheten snabbt ihop med en dator och data lästes av. De mätvärden som erhölls vid start subtraherades sedan med de

mätvärden som erhölls efter utfört test. Differensen av dessa värden kommer senare i rapporten anges som nivåskillnad respektive spänningsskillnad.

Alla test-vyerna granskas efter uppdateringar av GPU på skärmen, alltså om pixlar målas om på skärmen. Detta görs via Chrome DevTools för webbapplikationen och via enhetens utvecklingsinställningar för native- och hybridapplikationen. Dessa verktyg färgar skärmen där pixlar målas om, vilket ger möjligheten att se när och vad som målas om. Det kontrollerades även om några av test-vyerna utförde någon overdraw i nativeapplikationen.

2.4 Dataanalys

Studiens dataanalys är en kvantitativ analys eftersom empirin som samlats in kommer vara av typen kvantitativ data. Data samlas in från de utförda experimenten för de olika applikationstyperna. Data som samlas in läggs först in ett Word-dokument med allt som erhålls från alla script och detta görs för att underlätta och effektivisera datainsamlingen under experimenten. Endast den önskade datan tas ut och struktureras upp i ett excel-dokument i form av tabeller och diagram. Från den data som erhållits görs även en del beräkningar för att få fram jämförbara mätdata som önskades och inte erhållits av ADB. Dessutom görs beräkningar för att erhålla mätdata som saknas för webbapplikationer som använt Chrome DevTools, men erhållits av andra applikationertyper som använt ADB. Generella beräkningar som görs för alla applikationstyper i excel presenteras i

Tabell 1. Webbapplikationens grafiska data kommer ifrån Chrome DevTools och

innehåller inte exakt samma data per automatik utan för webbapplikationen får även extra beräkningar göras för att kunna utföra en slutgiltig jämförelse, se Tabell 2.

Tabell 1. Generella beräkningar för alla applikationer.

Önskade värdet: Beräkningen:

FPS för en bildruta 1000/renderingstiden för en bildruta

Genomsnittlig FPS Summan av produkten (Antal bildrutor renderade vid den tiden * FPS för den bildrutan) för varje renderad bildruta och sedan dividerat på totala antalet renderade bildrutor.

Excel-func: PRODUKTSUMMA(TableX[Number of

frames:];(1000/TableX[Time(ms):]))/SUMMA(TableX[Number of frames:])

Medelvärde på alla mätvärden Summan/Antal utförda tester

Totalt antal bildrutor över 16ms (%)

Summan av alla testers bildrutor där renderingstiden översteg 16ms/Total antalet renderade bildrutor för alla tester.

Tabell 2. Beräkningar för webbapplikationen

Önskade värdet: Beräkningen:

Antal ojämna bildrutor på ett test (st)

Summering av alla bildrutor vars renderingstid översteg 16 ms.

Totalt antal renderade bildrutor för ett test (st)

Summering av alla renderade bildrutor under ett utfört test.

Alla applikationernas resultat jämförs för respektive test-vy med de genomsnittliga värdena, för att se hur applikationernas resultat skiljer sig åt och vilken av alternativen som presterar genomgående bäst. Resultaten kommer även analyseras utifrån första frågeställningen för att fastställa vilka parametrar som kan ha orsakat skillnader i resultatet.

2.5 Trovärdighet

Studien är beroende av dess trovärdighet och enligt Eliasson (2013) är två begrepp som tillsammans ger hög trovärdighet, reliabilitet samt validitet. Reliabilitet handlar om att undersökningen ska vara pålitlig och att resultatet ska gå att upprepa. För en kvantitativ undersökning innebär det att mätningarna ska försöka genomföras på exakt samma sätt oavsett när och var underökningen genomförs. Validitet handlar om undersökningen verkligen mäter det som är tanken att den ska mäta och att den information samt data som samlas in är sann (Eliasson, 2013).

För att ge alla experimentförsök samma förutsättningar, är det viktigt att kontrollera att inga andra applikationer på enheten påverkar resultatet. För att inga andra applikationer än testobjektet ska påverka experimentet och dess resultat, kommer alla användarkontrollerade applikationer att stängas av och enheternas flygplansläge att aktiveras innan varje test. Ett aktiverat flygplansläge innebär att enhetens wifi och radioförbindelse är avstängt. Alla tester på applikationerna kommer att utföras genom att applikationen stängs av och startas upp på nytt, för att undvika att tidigare tester ska

påverka nästa experiment samt att undvika att applikationer sparar påverkande data i bakgrundsläge.

3

Teoretiskt ramverk

Detta avsnittet ger en teoretisk grund för studien och vad som utförts inom området sedan tidigare.

3.1 Koppling mellan frågeställningar och teori

Frågeställningarna i denna rapport bygger på tidigare forskning som utförts inom ämnet och dessa presenteras i avsnitt 3.2. Den tidigare forskningen belyser vilka områden som redan undersökts inom ämnet, men ger även ett helhetsintryck på hur nativeapplikationer, webbapplikationer och hybridapplikationer kan skilja sig gentemot varandra. Detta helhetsintryck kommer användas för att kunna erbjuda Consid en rekommendation som bygger på studiens resultat samt tidigare forskning. I avsnitt 3.3 och 3.4 ges bakgrundsteori för att underlätta förståelsen av renderingsprocesserna i mobila applikationer som beskrivs i avsnitten 3.5.3.1 och 3.5.5.1. I avsnitt 3.5 presenteras förväntningar och krav som ställs på mobila applikationer. I avsnitt 3.5.1 och 3.5.2 beskrivs gemensamma faktorer och parametrar som kan påverka renderingen för alla tre applikationstyper. Applikationstyperna har även individuella faktorer som endast påverkar dess parametrar och därav har varje applikationstyp ett eget avsnitt under mobila applikationer.

3.2 Tidigare forskning

Tidigare studier inom området har gjorts, men oftast har två av applikationstyperna undersökts och inte alla tre mot varandra. Persson, Tillborg och Bentöv (2012) gjorde en undersökning på hybridapplikationer för flera plattformar där deras fokus var på prestandan i användargränssnittet. De drog slutsatserna att en hybridapplikations användargränssnitt kan upplevas som segt och en aning hackigt. Nenzén (2014) gjorde en annan studie på hybridapplikationer där han undersökte varför nativeapplikationer valdes framför hybridapplikationer. Nenzén förklarar att de företag som intervjuades av honom ansåg att hybridapplikationer kunde upplevas som långsamma och oresponsiva, samt ha dåliga animationer. Han utförde även en prestanda jämförelse på hybridapplikationer som körs på olika operativsystem, men ingen undersökning gjordes på prestandaskillnaden mellan hybridapplikationen och nativeapplikationen. Ett år senare utförde dock Nilsson och Lagerqvist (2015) en studie som fokuserade på prestandaskillnaden mellan native- och hybridapplikationer i form av beräkningskraft. De drog slutsatserna i sin studie att hybridapplikationer var underlägsna till dess

motsvarande nativeapplikation och att prestandan påverkas av vilken JavaScript-motor samt vilka JavaScript-bibliotek som användes. Nilsson och Lagerqvist ansåg att hybridapplikationer ändå är ett bra alternativ så länge applikationen inte är tänkt att utföra några tyngre beräkningar. Under vidare forskning menade de att det hade varit av intresse att undersöka prestanda som fokuserar på användargränssnittet. Pålsson (2014) utförde en jämförelse mellan nativeapplikationer och hybridapplikationer gällande prestanda och utvecklingskostnad. Han utförde sin studie på ett företaget och han menar på att hans uppställning av utvecklingsscenario är förenklad, men resultatet och slutsatserna är fortfarande relevanta. Han drog slutsatsen att hybridapplikationer reducerar utvecklingskostnader effektivt då utvecklingsgruppens storlek förminskas. År 2015 gjorde Andrade, Albuquerque, Frota, Silveira, och Silva en studie för att undersöka hybridapplikationer och drog slutsatserna att denna applikationstyp erbjuder reducerade kostnader tack vare förminskad utvecklingstid samt mindre förvaltningskostnader. De menar på att hybridapplikationer erbjuder företag att skriva kod en gång och sedan nå ut till fler kunder på en applikation istället för att behöva skriva kod till flera applikationer.

3.3 FPS

FPS används för att mäta bildhastigheten genom bild per sekund. En människas öga kan bearbeta 12 separata bilder per sekund, vilket innebär att en bildhastighet på 12 FPS kommer visa rörelser men de kommer visas hackigt. Bildhastigheten som används vid film är oftast 24 FPS och många videokameror spelar in i 30 eller 60 FPS (Christensson, u.å.). Det rekommenderas att på de flesta mobila enheter att hålla uppdateringen av bilderna på 60 FPS (Bermes, 2015).

3.4 GPU och CPU

GPU står för Graphics Processing Units och är fysiskt liten, men kan hantera upp till tusentals trådar parallellt. GPU är idag inte begränsad till enbart grafiska problem utan kan även hantera algoritmer. För att implementera en effektiv GPU-algoritm är aspekter som manuell cache-användning, parallellt minnesåtkomstmönster, kommunikation, kartläggning av trådar och synkronisering avgörande. År 2001 var första gången en GPU byggdes på en programmerbar arkitektur som tillät belysning, skugga, geometri och effekter att renderas i realtid (Navarro, C., Hitschfeld-Kahler, N., Mateu, L. 2014).

Utvecklare för webbapplikationer bör dock undvika att använda enhetens CPU (Central Processing Unit) och GPU så mycket som möjligt och istället låta webbläsaren utföra dessa handlingar istället. Det vore att föredra om CPU-enheten sätter upp den ursprungliga animationen och GPU endast ansvarar för att komponera olika lager under processen (Niranga, 2015). Trots de effektiva CPU och GPU i mobila enheter, är de fortfarande mindre kraftfulla än datorer vilket resulterar i långsammare exekvering av JavaScript (Bermes, 2015).

Google Developers (2015) använder en process vid namn Rasterization som omvandlar XML och markup språk till pixlar som användaren kan se på skärmen. Denna process tar väldigt lång tid och därav behövs en GPU för att kunna snabba på hela denna process. Ett objekt i användargränssnittet som skall ritas ut på skärmen som en knapp eller kryssrutor behöver först konverteras i CPU till polygoner och texturer. Först därefter kan CPU förflytta objektet till GPU som sedan utför rasterization processen. Efter processen kommer det finnas utmålade pixlar på skärmen och i Figur 7 ges en förtydligande bild över alla stegen. Själva processen att omvandla ett användargränssnitts objekt i CPU är inte den snabbaste processen och inte heller att ladda upp ett objekt från CPU till GPU går särskilt snabbt. På grund av dessa tidskrävande processer vill utvecklare minska antalet gånger ett objekt behöver konverteras samt även minska antalet gånger ett objekt behöver laddas upp för att ritas ut på skärmen. Det finns ett API vid namn OpenGL ES som tillåter utvecklare att ladda upp innehåll i GPU och sedan lämna kvar det där. Nästa gång det sparade objektet i GPU skall ritas ut behövs det endast refereras till och sedan behöver information om hur objektet skall ritas ut ges till OpenGL ES. För att optimera renderingen brukar en grund regel enligt Google Developers (2015) vara att spara in så mycket data i GPU så snabbt som möjligt och vänta med att modifiera det så länge som möjligt. Anledningen Google Developers (2015) ger till att modifieringar skall undvikas är för att det förloras dyrbar hanteringstid hos GPU vid varje ändring. Vyer med mer standardiserat utseende kommer därav gå väldigt snabbt att rita ut medan vyer med bilder eller mer komplicerade objekt kommer tvinga CPU att skicka massa data till GPU på nytt. GPU kommer behöva modifiera innehållet som sparats och en del vyer kommer tvinga GPU att modifiera innehållet vid varje bildruta, vid exempelvis animationer. Android och webbapplikationer sparar prestanda genom att endast uppdatera och rita ut de delar av

skärmen som blivit ändrade, dock behöver dessa ändringar och andra uppdateringar i GPU ske tillsammans med koduppdateringar, konverteringar i CPU och rendering. Allt detta bör ske under 16 millisekunder för varje bildruta och detta för att inte riskera ett ojämnt och laggigt användargränssnitt (Google Developers, 2015).

Polygoner Texturer

CPU GPU Skärmen

Rasterization

Figur 7. En modell över ett objekts väg för att målas ut på skärmen.

3.5 Mobila applikationer

Enligt Bermes (2015) förväntar sig användare att mobila applikationer idag skall vara interaktiva och smidiga. Applikationen skall ladda snabbt och animationer samt interaktioner skall ha ett konstant flöde. Det finns mycket statistik och fallstudier som visar att många användare lämnar en applikation på grund av dålig prestanda (Bermes, 2015). Enligt en undersökning som gjordes av Gomez (2010) lämnar nästan 40

procent av e-handelskunder en webbapplikation om den tar mer än 3 sekunder att ladda. En annan undersökning som gjordes av Aberdeen Group (2015) visar att en fördröjning med 1 sekund resulterar i 11 procent mindre sidvisningar och 16 procent mindre kundnöjdhet. Enrique López Mañas och Diego Grancini (2016) beskriver användarupplevelse i mjukvarusystem genom tre tidsramar. I den första tidsramen uppfattar användaren direkt respons inom 0,1 sekund och i sådana situationer behövs ingen visuell feedback eller meddelande ges till användaren. I den andra tidsramen som ligger mellan 0,1 och 1,0 sekunder behöver fortfarande ingen feedback ges men efter 1,0 sekund kommer användarens uppfattning inte längre vara att responsen är direkt. I den sista tidsramen tappar användaren koncentrationen och intresset för applikationen om väntetiden går upp emot 10 sekunder. Om en funktion överskrider 10 sekunder anser Mañas & Grancini att visuell feedback till användaren är viktig för att användaren inte skall bli frustrerad och avvisa applikationen.

De flesta enheter uppdaterar skärmen 60 gånger i sekunden enligt Lewis (2017), vilket kallas för refresh rate och om det exempelvis finns animeringar behöver enhetens refresh rate matchas genom att lägga upp en ny bildruta för varje uppdatering av skärmen. Varje bildruta får därför ha en maximal exekveringstid på drygt 16 millisekunder (1 sekund/60 = 16,66 ms) och om renderingen överskrider detta kommer en bildruta hoppas över vilket kommer resultera i en hackig och ojämn animation, vilket påverkar användarens erfarenhet negativt (Lewis, 2017). I grund och botten handlar det om att utmålningen av innehållet och uppdateringen av skärmen skall vara synkroniserade (Sillars, 2015).

Minnesanvändning och batterianvändningen kan påverka renderingsprocessen och gäller för alla applikationstyper. Dessa parametrar och deras faktorer kommer presenteras nedan, medan de faktorer som orsakar en påverkan på

renderingsprocessen för en specifik applikationstyp presenteras i egna stycken under tillhörande typ.

3.5.1 Batterianvändning

Sillars (2015) anser att de delar i en mobilenhet som påverkar batteritiden mest negativt är skärmen, CPU samt signaler som Wi-Fi och Bluetooth. Det som påverkar batteritiden hos en enhet påverkar även prestandan på en applikation och genom att optimera applikationens prestanda kommer även enhetens batteritid att optimeras. Skärmen är en av de största anledningarna till försämrad batteritid och Sillars (2015) menar att det beror på att skärmen behöver vara tänd medan applikationen körs för att kunna visa användargränssnittet.

Det finns tre skärmtyper som vanligtvis diskuteras, liquid crystal display som förkortas LCD, light-emitting diode som förkortas LED och organic light-emitting diode som förkortas OLED (LG, 2018). Sillars (2015) beskriver att en LCD-skärm består av tusentals flytande kristaller som generar färg till varje pixel och använder ett bakgrundsljus som tänder dem alla samtidigt. Varje pixel skapas genom ett

arrangemang av röda, blåa och gröna kristaller. Att skapa färgerna till varje pixel tar minimalt med energi och varje pixel kostar dessutom lika mycket energi (Sillars, 2015). Äldre och traditionella LCD-skärmar använde CCFL-bakgrundsljus men nuförtiden används LED-bakgrundsljus för att illuminera LCD skärmar, vilket istället kallas för LED-skärmar (LG, 2018). För LCD-skärmar och LED-skärmar används fortfarande bakgrundsljus vid färgen svart, vilket resulterar att svarta bakgrunder i applikationer för mobila enheter med dessa skärmtyper ger minimala effektvinster (Sillars, 2015). OLED-skärmar behöver inte bakgrundsljus utan använder istället en organisk substans som lyser när en elektrisk ström introduceras (LG, 2018). En OLED-skärm består av miljontals pixlar och pixlarna i sin tur består av röda, gröna och blåa små OLEDs (OLED-info, 2017). Enligt LG kan OLED stänga av enskilda pixlar och Sillars (2015) påstår av den anledningen att färgen svart inte kostar OLED-skärmar någonting i energi att visa. Eftersom det finns tre olika ljuskällor och de har olika intensitet, påstår Sillars (2015) att de kräver olika mycket energi. Färgen vit som använder sig av alla tre färger och i väldig hög ljusstyrka, kostar enligt Sillars (2015) mer i energi. Det finns olika typer av OLED-skärmar och en av dem är AMOLED

som står för active matrix organic light-emitting diode. Det finns olika versioner av AMOLED och dessa olika versioner blir allt vanligare i smarttelefoner (OLED-info, 2017).

Enligt Sillars (2015) är CPU en annan faktor som påverkar batteritiden och det är i CPU där all bearbetning av kod sker för att kunna skapa en applikation. Han påstår att en applikation med många tunga beräkningar kommer belasta CPU, vilket i sin tid påverkar enhetens batteri. CPU påverkas inte enbart av beräkningar som utförs utan även av skärmuppdateringar och nätverksanvändning (Sillars, 2015).

3.5.2 Minnesanvändning

I Java och JavaScript finns något som kallas för Garbage Collection och

grundprincipen är att en garbage collector startar med sin uppgift att ta bort oanvända objekt när den övre gränsen för minnet är uppnått. Garbage collection pausar alla andra metoder, uppgifter, trådar samt processer som exekveras och dessa objekt kommer inte enligt Mañas & Grancini (2015) fortsätta förrän garbage collector har utfört sin uppgift. En garbage collection måste vara snabb då denna pausning inte får orsaka applikationen att missa sin bildruta på 16 ms. Mañas & Grancini (2015) förklarar att en långsam garbage collection kan alltså resultera i ett laggig och ojämt användargränssnitt då applikationen inte hinner förbereda alla bildrutor för att bli renderade på skärmen. Många uppdateringar och förbättringar har gjorts under åren men grundprincipen hur en garbage collection fungerar är densamma.

Ett sätt att undvika att garbage collection påverkar en applikations användargränssnitt är att ha en bra minneshantering (Mañas & Grancini, 2015). Ett exempel på en dålig minneshantering anser Google Developers (2015) är något som kallas för memory churn. Det är när ett högt antal objekt är allokerade och eventuellt frigjorda under en mycket kort tid. Den snabba allokeringen av så många objekt resulterar i en

översvämning av reserverade minnesblock. När dessa reserverade minnesblock når en viss nivå, kommer garbage collector köras igång för att rensa upp utrymmet (Google Developers, 2015). Även om minnes allokeringen är liten kommer volymen av dem trigga igång garbage collector oftare över tiden och i sin tur påverka minnet som helhet samt prestandan av användargränssnittet i applikationen (Mañas & Grancini, 2015). Ett annat exempel på dålig minneshantering enligt Google Developers (2015)

är när kod har minnesläckor och dessa läckor kan bero på olika saker. En av orsakerna till en sådan läcka kan vara att ett objekt inte längre används i koden, men fortfarande är refererad av ett annat objekt som fortfarande är aktivt. I en sådan situation kommer garbage collector hoppa över detta objekt eftersom det är tillräckligt för att lämna objektet i minne, vilket resulterar i att oanvända objekt ligger och tar upp minne i onödan (Google Developers, 2015).

Det finns tre ”mindre” aspekter som Mañas och Grancini (2015) menar att utvecklare bör tänka på vid programmering och minneshantering och det första är att inte använda större datatyper än vad som behövs. Det vore slöseri med minne och beräkningar varje gång CPU:n behöver hantera en onödigt stor datatyp. Den andra aspekten att tänka på är att rensa bort alla onödiga objekt i koden och den tredje är att använda sig av färre temporära objekt. Temporära objekt rensas ofta av garbage collector och onödiga objekt är dyra för minnet samt beräkningsprestanda och bör därav undvikas (Mañas & Grancini, 2015).

3.5.3 Webbapplikationer

Precis som för alla mobila applikationer skall webbapplikationer försöka rendera varje bildruta inom 16 millisekunder, men webbläsaren har andra uppgifter än bildrutans exekvering som den måste hinna utföra inom denna tidsram. Detta resulterar i att bildrutan egentligen bara har en exekveringstid inom 10 millisekunder och misslyckas applikationen med att hålla sig inom denna tidsram, kan en visuell ojämnhet synas på skärmen (Lewis, 2017).

3.5.3.1 Renderingssteg

Det finns fem områden inom webbapplikationer som Google rekommenderar att en utvecklare bör ha vetskap om: JavaScript, Style, Layout, Paint samt Composite. Dessa fem områden är huvuddelarna i den så kallade Pixel pipeline, se Figur 8 (Lewis, 2017). Pixel pipeline kan också kallas för graphics pipeline och är en konceptuell metod som beskriver stegen ett grafiskt system behöver utföra för att rendera en 3D- eller 2D-bild (RMIT University, u.å.).

JavaScript Style Layout Paint Composite

Lewis (2017) beskriver att det första steget i den konceptuella metoden är när webbläsaren skickar en request till en webbserver och webbservern skickar tillbaka ett svar med HTML-kod. Webbläsaren utför sedan parsing på HTML-koden, vilket innebär att koden delas upp och analyseras. Denna uppdelning är vad som kallas för ett DOM träd. CSS är den visuella layouten för elementen och kommer ifrån style-sheets eller inline styles. I ett steg som kallas Recalculate Style kommer DOM och CSS kombineras och skapa ett nytt träd vid namn renderings träd. Renderings trädet innehåller endast element som kommer visas på skärmen. Efter denna process vet webbläsaren vilka regler som kommer appliceras på alla element och kan istället börja beräkna layouten. Att beräkna layouten innebär att beräkna hur mycket utrymme ett element tar och vart det skall vara placerat på skärmen. I layouten kan ett element påverka andra element som exempelvis elementets barn och sen kan det vandra neråt i trädet, vilket kan resultera i en invecklad process för webbläsaren. Efter layouten arbetar webbläsaren vidare till paint-processen där rasterizer ritar ut vektorer och figurer som fyller pixlarna. En applikation kan bestå av ett lager eller flertal lager och paint-processen fungerar på alla individuella lager. Efter att alla lager fått ifyllda pixlar fortsätter webbläsaren till composite. I composite förs de olika lagerna samman och placeras i rätt ordning. Allt webbläsaren har utfört hittills har skett i CPU och det är först nu composite laddar upp alla lager och dess innehåll till GPU. Slutligen instrueras GPU att placera alla bilder på skärmen och en synlig vy kommer att finnas (Lewis, 2015). Det ovannämnda tillvägagångssättet var en kortfattad genomgång om stegen i en pixel pipeline när en applikation skall rendera en 2D- eller 3D-bild.

Alla stegen som nämndes ovan behöver inte alltid ske när något skall förändras visuellt på skärmen, utan det finns vanligtvis tre olika sätt enligt Lewis (2017), som en pixel pipeline utförs på för en given bildruta. För att en visuell förändring skall ske kan JavaScript och CSS animation användas. Beroende på vad som förändras, kan olika steg i pipelinen triggas. Ett av tillvägagångssätten är att en förändring sker i JavaScript

och då behöver webbläsaren omberäkna style på alla de element som blivit påverkade. Förändringen i JavaScript innebär i det här fallet en ändring i en layoutegenskap, exempelvis elementets storlek eller position. Webbläsaren behöver kontrollera alla andra element och layouten på sidan behöver beräknas om. Alla påverkade områden behöver genomgå paint-processen igen för att sedan sättas ihop av composite. På det här viset går webbläsaren igenom alla fem områden som i Figur 8. Andra tillvägagångssättet är en förändring i JavaScript som ändrar en paint-egenskap, som bakgrundsbild, textfärg eller skuggor. Style omberäknas på alla element som påverkas men ingen layout sker den här gången. Paint utförs och även composite. För att förtydliga tillvägagångsättet visar Figur 9 vilka steg som webbläsaren tar och vilka som hoppas över (Lewis, 2017).

Tredje tillvägagångssättet är en förändring i JavaScript, men som inte ändrar något på egenskaperna hos layout eller paint. Style omberäknas på alla element som påverkas och sedan hoppar webbläsaren direkt till composite (Lewis, 2017). En förtydligande bild över detta ges i Figur 10.

3.5.3.2 JavaScript

JavaScript är ett programmeringsspråk som framkallar visuella förändringar, både via manipulationer i style och beräkningar (Niranga, 2015). JavaScript som exekveras vid opassande tidpunkter eller har lång exekveringstid är en vanlig orsak till prestandaproblem och då den skrivna JavaScript-koden inte är koden som exekveras i webbläsaren, kan dessa problem vara utmanande att lösa. Moderna webbläsare använder JIT-kompilatorer enligt Lewis (2017) och många andra optimeringar samt tricks för att snabba på exekveringen, vilket förändrar dynamiken i koden. För att utveckla en applikation med effektivt exekverande JavaScriptkod finns det viktiga aspekter att vara medveten om och dessa kommer att beskrivas i detta stycke (Lewis, 2017). Som tidigare nämnt kan JavaScript exekvering vara långsammare på mobila

Figur 10. Beskrivande bild av pixel pipeline där webbläsaren inte utför layout eller paint (Lewis, 2017).