En jämförelse mellan native-, hybrid- och webbapplikationer

Transkript

1 En jämförelse mellan native-, hybrid- och webbapplikationer En undersökning om applikationernas prestandaskillnader i användargränssnittet. HUVUDOMRÅDE: Datateknik FÖRFATTARE: Victoria Dahlquist HANDLEDARE: Johan Kohlin JÖNKÖPING 2018 maj Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan (vx) Jönköping

2 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å) Datum:

3 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.

4 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, JAVA, User Interface, Performance, Experiment, Literature Study i

5 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, JAVA, Användargränssnitt, Prestanda, Experiment, Litteraturstudie ii

6 Innehållsförteckning 1 Introduktion BAKGRUND Native Webb Hybrid Uppdragsgivare PROBLEMBESKRIVNING SYFTE OCH FRÅGESTÄLLNINGAR OMFÅNG OCH AVGRÄNSNINGAR DISPOSITION BEGREPPSDEFINITION Metod och genomförande KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH METOD EXPERIMENT Hypotes och förutsägelse ARBETSPROCESSEN Utvecklingsmiljöer Enhet Implementering Datainsamling DATAANALYS TROVÄRDIGHET Teoretiskt ramverk KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH TEORI TIDIGARE FORSKNING FPS GPU OCH CPU MOBILA APPLIKATIONER Batterianvändning Minnesanvändning Webbapplikationer Hybridapplikationer Nativeapplikationer iii

7 4 Empiri LOADING ICON INTERACTION STATIC VIEW ANIMATION Analys FRÅGESTÄLLNING FRÅGESTÄLLNING Loading icon Interaction Static View Animation Generell analys för alla test-vyer Resultat av analys Diskussion och slutsatser RESULTAT IMPLIKATIONER BEGRÄNSNINGAR SLUTSATSER OCH REKOMMENDATIONER VIDARE FORSKNING Referenser Bilagor iv

8 Figurförteckning Figur 1. Modell över tillvägagångssättet för den experimentella metoden Figur 2. Meny-vyn för nativeapplikation, webbapplikationen och hybridapplikationen Figur 3. Interaction-vyn för nativapplikation, hybridapplikation och webbapplikation Figur 4. Loading icon-vyn för nativapplikation, hybridapplikation och webbapplikation Figur 5. Animation-vyn för nativapplikation, hybridapplikation och webbapplikation Figur 6. Static View-vyn för nativapplikation, hybridapplikation och webbapplikation Figur 7. En modell över ett objekts väg för att målas ut på skärmen Figur 8. Beskrivande bild av en pixel pipeline och dess fem delar (Lewis, 2017) 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) Figur 11. Arkitektur för en hybridapplikation (Gok & Khanna, 2013) Figur 12. Diagram över renderingstiden för varje bildruta i Loading icon för alla applikationstyper Figur 13. Diagram över renderingstiden för varje bildruta i Interaction för alla applikationstyper Figur 14. Diagram över renderingstiden för varje bildruta i Animation för alla applikationstyper Tabellförteckning Tabell 1. Generella beräkningar för alla applikationer Tabell 2. Beräkningar för webbapplikationen Tabell 3. Medelvärden på de tre applikationstypernas användning av RAM-minnet för de fem respektive testerna i Loading icon-vyn Tabell 4. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn Tabell 5. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn Tabell 6. Medelvärden på de tre applikationstypernas CPU-användningen av de fem respektive testerna i Loading icon-vyn Tabell 7. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Loading icon-vyn Tabell 8. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Interaction-vyn Tabell 9. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn Tabell 10. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn Tabell 11. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Interaction-vyn Tabell 12. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Static View-vyn Tabell 13. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Static View-vyn Tabell 14. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Static View-vyn Tabell 15. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Animation-vyn Tabell 16. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn Tabell 17. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn Tabell 18. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Animation-vyn Tabell 19. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Animation-vyn v

9 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 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 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 1

10 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 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 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, 2

11 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 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 3

12 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. 4

13 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 En sammanfattade diskussion och slutsats av studien presenteras. 5

14 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 definierar bland annat dokumenttitel, style, länkar och script (W3C, u.å.). 6

15 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.å.). 7

16 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. 8

17 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 9

18 kommer falsifieras eller verifieras. Slutligen kommer resultatet att dokumenteras och presenteras i rapporten i form av text och tabeller. Ställ en fråga Gör bakgrunds forskning Skapa en hypotes Dokumentera resultatet Analysera och dra slutsatser Utför experimentet Figur 1. Modell över tillvägagångssättet för den experimentella metoden Hypotes och förutsägelse Eftersom både hybridapplikation och webbapplikation består av bland annat JavaScriptkod, 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 10

19 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 RAMminnet, CPU:s minnesanvändning, GPU:s minnesanvändning samt batterianvändning. Hur experimenten implementerades och utfördes beskrivs i avsnitt och Utvecklingsmiljöer Nativeapplikationen och skalet till hybridapplikationen utvecklas i Android Studio med version 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 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 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. 11

20 Figur 2. Meny-vyn för nativeapplikation, webbapplikationen och hybridapplikationen. 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. 12

21 Figur 3. Interaction-vyn för nativapplikation, hybridapplikation och webbapplikation. 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 OnClickfunktionalitet 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 13

22 progressbar. Div-taggen roteras sedan med hjälp av transform och objektet försvinner när räknaren blir noll, se Bilaga 6. Figur 4. Loading icon-vyn för nativapplikation, hybridapplikation och webbapplikation. 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 imgtaggar som innehåller bilden och som roteras med hjälp av transform, se Bilaga 9. 14

23 Figur 5. Animation-vyn för nativapplikation, hybridapplikation och webbapplikation. 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. Webboch 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

24 Figur 6. Static View-vyn för nativapplikation, hybridapplikation och webbapplikation 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 16

25 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, CPUanvändning och GPU-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 whileloop 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 17

26 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 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 18

27 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 exceldokument 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: FPS för en bildruta Genomsnittlig FPS Beräkningen: 1000/renderingstiden för en bildruta 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:]) 19

28 Medelvärde på alla mätvärden Totalt antal bildrutor över 16ms (%) Summan/Antal utförda tester 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: Antal ojämna bildrutor på ett test (st) Totalt antal renderade bildrutor för ett test (st) Beräkningen: Summering av alla bildrutor vars renderingstid översteg 16 ms. 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 20

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

30 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 och I avsnitt 3.5 presenteras förväntningar och krav som ställs på mobila applikationer. I avsnitt och 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 22

31 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). 23

32 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 24

33 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 Rasterization GPU Skärmen Figur 7. En modell över ett objekts väg för att målas ut på skärmen. 25

34 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å 26

35 renderingsprocessen för en specifik applikationstyp presenteras i egna stycken under tillhörande typ 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 OLEDskä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 27

36 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) 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) 28

37 ä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) 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) 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 Figur 8. Beskrivande bild av en pixel pipeline och dess fem delar (Lewis, 2017). 29

38 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 Figur 9. Beskrivande bild av pixel pipeline där webbläsaren inte utför layout (Lewis, 2017). 30

39 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. Figur 10. Beskrivande bild av pixel pipeline där webbläsaren inte utför layout eller paint (Lewis, 2017) 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 31

40 applikationer och därav bör omberäkning och flödesomformning undvikas om möjligt samt försöka undvika att ha funktioner som ändrar i DOM (Bermes, 2015). När visuella förändringar skall ske på skärmen som en animation, bör exekveringen av en visuell förändring ske i början av renderingsprocessen av en bildruta och undvika funktioner med callback. En callback funktion är en funktion som skickas med som argument i en annan funktion, för att sedan anropas inuti funktionen för att slutföra en rutin eller handling. Vid användning av callbacks går det inte att avgöra när de kommer att exekveras utan det kan ske i slutet av renderingsprocessen av en bildruta. Detta kan resultera i att renderingen tar längre än 16 ms och effekten kan bli en hackig visuell förändring som användare kan kalla för lagg eller ojämn renderad bildruta (Lewis, 2017). Ett sätt att vara säker på att en animation körs i början av renderingsprocessen av en bildruta är enligt Lewis (2017) att använda sig av requestanimationfunction. Detta tillvägagångssätt kräver dessutom färre CPU cykler och gör att animationen är bättre synkroniserad med enhetens GPU (Bermes, 2015). JavaScript-kod exekveras tillsammans med layout, paint och beräkningarna i style på webbläsarens main thread och om JavaScript-koden tar för lång tid att exekvera kommer JavaScripten att blockera andra uppgifter på tråden. Denna blockering kan resultera i fördröjningar men också att en bildruta missas. Det är av den anledningen av stor vikt att vara taktisk med när och hur länge en JavaScript kod kommer att köras (Lewis, 2017). Om koden inte behöver tillgång till DOM kan det vara lämpligt att använda sig av Web Workers, vilket innebär att koden inte kommer utföras på main thread (Niranga, 2015). Sortering och sökning av data är två exempel på uppgifter som är lämpliga att utföra på en web worker och möjliggör att main thread kan hållas mottaglig till användarinteraktioner (Lewis, 2017). Varje gång DOM-element ändras via JavaScript är det prestandan av applikationen som får betala priset. Detta beror på att DOM sitter utanför JavaScriptens virtuella maskin, vilket innebär att ändringar i layout, composite eller paint är mycket dyrt pris i prestanda. Om ändringar i DOM görs med JavaScript och om denna ändringen exempelvis sker i en loop kan allvarliga inverkan ske på sidans prestanda. Loopar går om i flertal varv och om DOM-ändringar sker i loopen kommer webbläsaren behöva ändra och hantera det i varje varv. Det är därför viktigt att kontrollera om det går att flytta ut DOM-operationen utanför loopen 32

41 och en tumregel enligt Bermes (2015) är att alltid försöka göra så mycket arbete utanför loopen som möjligt. Ett framework eller bibliotek kan följaktligen vara en av anledningarna till att en bildruta kan missas och resultera i lagg. Färdiga frameworks eller bibliotek i JavaScript kan ha långsam JavaScriptkod och det är därav stor betydelse vilka frameworks samt bibliotek som används. Det finns två sätt att förhindra att dessa påverkar applikationen alltför mycket och ett tillvägagångssätt är att kontrollera hur lång exekveringstid funktionerna i dem tar samt utvärdera om de lämpar sig för applikationen. Det andra tillvägagångssättet är använda sig av Web worker och inte låta frameworks och biblioteken exekveras på main thread (Lewis, 2017) CSS CSS står för Cascading Style Sheets och är den visuella layouten för en mängd applikationer. CSS har en viktig betydelse för webbapplikationer, men påverkar även applikationens prestanda (W3C, u.å.). Oavsett om externa style sheets används eller om inline styles på element används, bör CSS-koden hållas kort och mager. I synnerhet skall selektorer som aldrig används undvikas eftersom de endast kommer skada renderingstiden på sidan. Style och layout är två delar i CSS och som även ingår i pipeline processen och vid omberäkning av element eller ändringar i layouten kommer de påverka sidans prestanda negativt (Bermes, 2015) Style Vid förändringar i DOM som exempelvis tillägg, förändring eller borttagning av element, attribut, klasser eller animationer, kommer webbläsaren bli tvungen att omberäkna elementens utseende och i många fall delar eller hela layouten av en applikation (Bermes, 2015). Detta sker i området style (se Figur 8) och denna process kallas för computed style calculation. I computes style calculation behöver det först skapas en uppsättning av matchande selektorer och det är webbläsarens sätt att veta vilka element som skall ändras. Den andra delen av processen innefattar att ta alla design-bestämmelser från de matchande selektorer och räkna ut vilken design som elementet slutligen har (Lewis, 2017). Enligt Rune Lillesveen (2014) på Opera används 50 procent av tiden i style-processen för att sammanställa den design som ett element 33

42 slutligen skall få och detta med hjälp av de matchande selektorerna. Den andra halvan av tiden menar han på används för att konstruera den renderade designen som tidigare sammanställdes. För att förhindra att denna process orsakar att prestandan påverkas, anser Lewis (2017) på Google att det är viktigt att reducera komplexiteten av selektorer och han rekommenderar utvecklare att använda en klass-centrerad metodik som exempelvis BEM. En annan faktor som kan påverka prestandan anser Lewis (2017) är alla designuppdateringar och den stora arbetsvolymen som tillkommer när ett element skall ändras. Generellt är värsta fallet av prestanda påverkan enligt Lewis (2017) när alla elementet måste jämföras med alla selektorer minst en gång för att säkerställa att elementen följer designbestämmelserna som angivits. De design-beräkningar som behöver göras kan oftast riktas direkt mot några element istället för att ogiltighetsförklara hela sidan. I moderna webbläsare behöver inte alla element som potentiellt påverkas av en förändring bli kontrollerade, men de äldre webbläsarna är däremot inte nödvändigtvis lika optimerade. Äldre webbläsare kan behöva kontrollera alla element om det finns möjlighet att de kan komma att påverkas av en förändring och därav bör alla ogiltiga elements tas bort från applikationen för att minska påverkan på prestandan (Lewis, 2017) Layout Lewis (2017) beskriver layout som den del där webbläsaren hanterat den geometriska informationen för ett element, exempelvis storlek och positionering på sidan. Elementens storlek beror på vilken CSS-kod som använts, elementets innehåll samt eventuella moderelement. Med moderelement menas ett element som innehåller andra element och dessa barn kan ärva en del av design-bestämmelserna från självaste moderelementet. Processen som sker kallas antingen för layout eller reflow beroende på vilken webbläsare som arbetas med (Lewis, 2017). Det som kan orsaka att prestandan påverkas i denna process är antalet element som kräver layout samt komplexiteten av layouten. När design förändras kollar webbläsaren om några av dessa ändringar kräver att layouten behöver beräknas om och sedan uppdatera renderingsträdet. Förändring av geometriska egenskaper som höjd och bredd kräver alltid omräkning av layout och om det finns många element kommer det ta lång tid att räkna ut alla positioner samt dimensioner (Bermes, 2015). Det finns en rad 34

43 layoutmodeller för webbapplikationer och en del av dem stöds mer av webbläsare än andra. Lewis (2017) rekommenderar utvecklare att använda sig av nyare layoutmodeller som exempelvis flexbox, men dessa modeller stöds mindre av webbläsare än de äldre och kanske inte existerar på en del webbläsare. Det som i grund och botten är viktigast är att kontrollera hur stor inverkan layoutmodellen som valts har på prestandan och undvika omberäkning av layout under högt belastade tillfällen på applikationen, som animation (Lewis, 2017). Med JavaScript är det möjligt att tvinga webbläsaren att köra layouten tidigare och detta kallas för forced synchronous layout. Detta påverkar prestandan negativt då det naturliga flödet rubbas och style samt layout tvingas att beräknas om. Att förvärra forced synchronous layout är att göra det flera gånger, snabbt efter varandra. Ett sätt att uppnå detta vore att lägga forced synchronous layout i en loop och hela situationen kallas för layout trashing (Lewis, 2017) Paint Lewis (2017) kallar processen att fylla i en pixel som slutligen presenteras på användarens skärm för paint. Denna process är oftast den som tar längst tid av alla uppgifter i pipelinen och den som bör undvikas om det är möjligt. Om några andra egenskaper än transform eller opacity ändras kommer paint-processen enligt Lewis (2017) att triggas. Opacity är en CSS-egenskap som bestämmer ett elements genomskinlighet medan transform är en CSS-egenskap som möjliggör bland annat förflyttning, rotering och skalning av ett element. Exempelvis om ett elements layout triggas kommer automatiskt paint-processen triggas eftersom ändringar i geometrin hos ett element innebär att elementets pixlar behöver förändras. Paint-processen sker inte alltid på en ensam bild i minnet, utan webbläsaren kan utföra detta på flertal bilder eller olika composite-lager om det behövs. Composite-lager är olika lager som slutligen samlas ihop och sorteras av composite för att bli en bildruta en process kallad compositing. Fördelen med detta tillvägagångssätt är att de element som regelbundet gör om paint-processen eller förflyttas på skärmen med hjälp av transform kan hanteras utan att påverka andra element. I princip fungerar det som i Photoshop, där enskilda lager kan hanteras och sättas ovanpå varandra för att skapa den slutliga bilden. Det får 35

44 dock inte skapas för många lager, då varje lager kräver både minne och hantering (Lewis, 2017). En stor utmaning med paint-processen är att webbläsare förenar två områden som behöver utföra paint-processen och enligt Lewis (2017) kan det i värsta fall leda till att hela skärmen går igenom processen. Detta fall kan ske om en rubrik finns längst upp på en sida och skall gå igenom paint-processen samtidigt som ett element längst ner på sidan. Att minska området som skall gå igenom paint-processen uppnås ofta genom att orkestrera animationer och övergångar på ett sådant vis att de inte överlappar lika mycket eller att undvika att animera vissa delar av sidan. När det kommer till paintprocessen tar olika uppgifter olika långt tid och Lewis (2017) anser därav att prestandan påverkas olika. Exempelvis kommer uppgifter som innehåller suddigheter som skuggor att ta längre tid att måla ut än en röd ruta. Ett bra mål att sträva efter är att uppnå effekter utan att bekosta prestandan något nämnvärt och att försöka undvika att starta en paintprocess under animationer. De tio millisekunder per bildruta som finns för animationer är normalt inte tillräckligt lång tid för att fylla i alla pixlar och speciellt inte på mobila enheter (Lewis, 2017) Composite Compositing är den process i composite där alla utmålade pixlar för en sida sammanställs för att visas på en skärm. Enligt Lewis (2017) finns det två faktorer i composite som kan påverka en applikations prestanda och en av dem är hur många lager som behöver hanteras. Den andra faktorn är vilka egenskaper som används för animation. Lewis (2017) beskriver att en applikation får bäst prestanda när både layout och paint kan undvikas och att endast ändringar i composite behöver ske i pipelineprocessen, se Figur 10. För att uppnå detta mål skall endast de egenskaper ändras som kan hanteras av enbart composite, vilket idag endast är transform och opacity. Ett element som skall ha sina egenskaper ändrade bör vara placerad på ett eget composite-lager. För att skapa ett lager kan elementet förvarna webbläsaren att förändringar på elementet kommer att ske. Detta görs genom att använda will-change- eller translatez-attribut på elementet. Beroende på vad förändringen gäller kan webbläsaren förbereda sig genom exempelvis skapa ett composite-lager. Med vetskapen om att flera lager ofta hjälper till att förbättra prestandan kan det vara 36

45 frestande att promota alla element på en sida. Varje lager som skapas behöver dock minne och hantering, vilket innebär att på en enhet med begränsat minne kan fördelen vara betydligt mindre än vad det skulle kosta i prestanda. Varje lagers struktur behöver laddas upp till GPU, vilket ger ytterligare begränsningar vad gäller bandbredd mellan CPU och GPU samt tillgängligt minne för struktur på GPU:n (Lewis, 2017). Willchange-attributet skall undvikas att användas i för många element, i situationer där webbläsaren inte hinner förberedda nödvändiga åtgärder inför en förändring av elementet och om en applikation inte har några prestandaproblem (MDN, 2018) Interaktionshanterare Interaktionshanterare är potentiella källor för prestandaproblem i en applikation enligt Lewis (2017) då dessa hanterare kan blockera bildrutor från att slutföras och kan orsaka onödigt layout-arbete. I det snabbaste scenariot kan sidans composite-tråd hantera användarens interaktion och enkelt flytta runt innehållet. Detta skapar inget arbete för main thread utan låter JavaScript, style, layout och paint exekveras utan problem. Om interaktionshanterare säger att composite-tråd måste vänta till hanteraren är klar med exekveringen kan detta resultera i hackningar och missade bildrutor. Lewis (2017) anser därför att det är av stor vikt att hanterarna exekverar snabbt och låter composite utföra sina sysslor. De interaktionshanterare som hanterar scrollning och skärmtryck är planerade att köras precis innan callbacks för en animation. Om visuella förändringar sker inuti några av dessa hanterare kommer style förändringar ligga väntade i början av animationsfunktionen. Om dessa visuella egenskaper sker i början av funktionens callback som är rekommenderat av Google kommer detta resultera i forced synchronous layout, vilket helst skall undvikas (Lewis, 2017) HTML HTML är en förkortning för Hypertext Markup Language och är ett av huvudspråken för att utveckla en webbapplikation. HTML ger strukturen av en webbapplikation med hjälp av markup (W3C, u.å.). Bermes (2015) anser att det är viktigt att skriva HTMLkoden med korrekt syntax och giltig kod för att inte belasta webbläsaren med mer arbete i onödan. Han menar på att glömma en stängande tagg till ett element som kräver ett, kan förvirra webbläsaren och orsaka fördröjning och en bruten layout. En annan faktor som fördröjer webbläsarensarbete är alla oanvända element och dessa borde tas 37

46 bort då de inte fyller någon funktion utan snarar förhindrar en snabb och effektiv applikation. Något annat som är viktigt att tänka på enligt Bermes (2015) är att tillämpa smart innehållslayout för att snabba på renderingsprocessen. Det kan göras genom att placera det viktigaste innehållet högre upp i källkoden och låta det mindre viktiga innehållet som exempelvis en sidomeny laddas längre ner i renderings trädet. Han anser även att det är betydelsefullt att hålla kodens head så liten och ren som möjligt för att kunna prioritera grafiskt innehåll. Ju fler länkar, script och andra kodrader i head, desto längre tid tar det för webbläsaren att faktiskt hämta hela webbapplikationens sida (Bermes, 2015) Hybridapplikationer I en hybridapplikation kan användaren integrera med webbläsarens alla tillgängliga funktioner genom webbläsaren och webbläsaren i sin tur integrerar med den inbyggda plattforms-miljön. Androids implementering av funktionaliteten att kontrollera en webbläsare heter WebView. WebView använder sig av WebKit, som är en webbläsaremotor med öppen källkod och WebKit används även av webbläsare som Safari. WebKit ger möjligheten att visa och exekvera webb-innehåll och i Android är det via WebView. Gok & Khanna (2013) har tagit fram ett exempel på hur en hybridapplikations arkitektur kan se ut och den identifieras i Figur 11, dock behöver inte alla komponenter nödvändigtvis finnas med och användas. Gok & Khanna (2013) anser att en hybridapplikation huvudsakligen är en webbapplikation, men som har tillgång till enhetens kapacitet genom en uppsättning APIer. Deras arkitekturs delar i Figur 11 förklaras nedan. 38

47 Figur 11. Arkitektur för en hybridapplikation (Gok & Khanna, 2013) Webbapplikationen kräver att WebView renderar innehållet och är värd för logiken (1). Om applikationen är skriven i mestadels i JavaScript kommer någon form av model-, view-, och controller-komponenter implementeras, dock beror denna implementering även på vilka JavaScript-bibliotek som används (2). Det finns ett lager i arkitekturen som Gok & Khanna kallar för JS-Java Bridge och är det lager som tillåter native- och webb-miljön integrera med varandra. Lagret bör tillåta exekvering av både synkrona och asynkrona APIer. JS-Java Bridge är ett viktigt lager vad gäller säkerhet och prestanda (3). Java-Plugin är kopplat till JS-Java Bridge och är ett användardefinierat utvidgnings API som är synligt för JavaScript-miljön (4). Native Components är ett samlings ord Gok & Khanna (2013) använder för de inbyggda tjänster och komponenter som en hybridapplikation kan vilja ha tillgång till. Dessa tjänster och komponenter kan vara inbyggda dialogrutor, åtkomst till platstjänst och så vidare (5). HTML5 ger vissa möjligheter till datalagring, men ibland vill utvecklare lagra data i ett anpassat format och det är vad Application data erbjuder (6). Assets and resources innehåller de 39

48 statistiska artefakterna som skickas med i applikationerna och kan användas för att lokalisera text (7). Native business logic är en viktigt arkitektonisk splittring vid utformning av hybridapplikationer och denna splittring existerar för att åtskilja logiken mellan native- och webb-komponenter (8). Många fallgropar i hybridapplikationen som kan kommat att påverka renderingen är desamma som för en webbapplikation, eftersom WebView använder sig av WebKit. Precis som för alla mobila applikationer bör renderingen ske inom 16 ms för att applikationen skall ha ett jämnt flöde (Gok & Khanna, 2013). I webbapplikationer kan renderingen påverkas negativt av områdena JavaScript, style, layout, paint samt composite och likaså är det för en hybridapplikation. Det står mer om hur dessa områden kan påverka renderingen i avsnittet En hybridapplikations rendering kan även påverkas av batterianvändning och minnesanvändning, vilket beskrivs mer i avsnitt och Nativeapplikationer Som för många enheter har Android-enheter enligt Sillars (2015) en refresh rate på 60 Hz och varje bildruta skall försöka rendera inom 16 ms. Utvecklare skall alltid försöka tänka på att minska skärmberäkningar genom att undvika omberäkningar av skärmen samt åstadkomma fast och konsekvent hastighet för en bildruta, för att undvika lagg. Sillars rekommenderar alla Android-utvecklare att hålla bearbetning av interaktionshanterare och animationsutvärdering under 2 ms. Det finns många saker som kan orsaka att intervallet 16 ms missas och en av dem kan vara att vy-hierarkin blir omberäknad för många gånger, vilket resulterar i att det tas upp för många CPU-cykler. Detta leder till att användargränssnittet inte kan uppdateras och samma grafiska vy kommer visas under en längre period. En hel bildruta kan hoppas över och detta sker om renderingen är blockerad av att CPU:n är upptagen med något helt annat (Sillars, 2015) Renderingssteg I webbapplikationer diskuteras och fördelas renderingsprocessen i fem steg, men i Android delas renderingsprocessen upp i tre steg enligt Sillars (2015): mätning, layout och måla ut pixlar på skärmen. Mätningar görs för varje dimension på en vy som 40

49 kommer visas på skärmen och mätningen börjar i översta noden i layout-hierarkin och följer sedan renderings-trädet av layouten. Varje vy kommer ge varje moderelement dimensioner för positionering och om moderelementet upptäcker något problem med mätningen av elementets egna dimensioner eller några av barnens, kan moderelementet tvinga barn och barnbarn att utföra en ommätning. Ommätningen görs för att kunna lösa problemen och Sillars (2015) beskriver att ommätningen kan potentiellt dubblera eller även tredubblera mätningstiden. Om vy-trädet är nästlat och har noder som går djupt ner i trädet blir mätningen samt kalkyleringstiden längre. Av den anledningen är det viktigt med ett mindre nästlat vy-träd och färre noder som går djupt ner i trädet. Efter att alla vyer har mätts kommer varje vy att applicera layout på alla barnen som sedan kan föra vyn upp till moderelementet och hela vägen upp till grund vyn. Efter att all layout är klar, kommer varje vy att ritas ut på skärmen. Alla vyer kommer ritas ut och inte enbart de som är synliga för användaren. Om det finns många vyer kommer hela renderingsprocessen ta längre tid och Sillars (2015) rekommenderar därför att undvika nästlade vyer samt att avlägsna alla vyer som inte är viktiga för renderingen. Att avlägsna vyer kommer minska tiden för renderingsprocessen betydligt och kan vara avgörande för att hinna klart under 16 ms, som är målet. Att ha för många objekt i en vy påverkar också prestandan och när Instagram 2014 reducerade antalet objekt i titelfältet minskade uppstartningstiden av applikationen med 10 20% enlig Sillars (2015) Hierarki Vyn som ligger högst upp i hierarkin är DecorView och den innehåller aktivitetens bakgrund som är definierad genom temat. Många utvecklare täcker dock denna bakgrund med en egen som passar deras layout. Detta påverkar GPU:n samt reducerar renderingshastigheten och bildhastigheten. Applikationen kommer nämligen använda standardbakgrunden och sedan lägga utvecklarens bakgrund över, vilket gör att applikationen måste hantera och rita över varje gång (Mañas & Grancini, 2016). Android rekommenderar att använda ConstraintLayout vid utveckling eftersom de ger möjlighet att skapa stora och komplexa vyer med en platt vy hierarki utan nästlade vyer. ConstraintLayout placerar ut alla barnelement i relation till varandra i form av exempelvis avstånd, vilket resulterar i att färre element skapas som barnbarn-element (Android Developers, u.å.). 41

50 Nästlade vyer Vid utveckling av Android-applikationer är det som tidigare nämnts viktigt att undvika nästlade vyer. Ju mer nästlade de är, desto mer komplicerat blir vy-trädet och det leder till längre renderingsprocess (Sillars, 2015). Anledningen är att varje gång ett element i vyn ändras kommer vyn behöva mäta om sig men också alla vyer från botten upp till den högsta i hierarkin. Detta kan ske flera gånger på grund av små ändringar som exempelvis textbyte. Hierarkin bör av den orsaken vara plan och enkel för att beräkna om alla vyer snabbt när det behövs (Mañas & Grancini, 2016) Overdraw När Android ritar ut på en skärm kommer moderelementet ritas ut först och sedan barn- och barnbarnselementen som ritas ut ovanpå moderelementet. Att måla skärmen ett flertal gånger skall undvikas enligt Sillars (2015) eftersom att det kan ge lagg till applikationens layout. Att måla om samma pixel flera gånger i samma bildruta kallas overdraw och problemet med overdraw är att varje gång en uppdatering sker på vyn, måste pixlarna för den vyn ommålas. Android vet inte vilken vy som är grafiskt synlig, utan måste måla om alla vyer som associeras med just de pixlarna (Sillars, 2015). Ur systemperspektiv måste varje pixel på skärmen uppdateras lika många gånger som antalet överlappande vyer för varje bildruta (Mañas & Grancini, 2016). Om flera lager och vyer hör till sådana pixlar kommer ommålningen att resultera i prestandaproblem. Kitkat och nyare versioner av Androids operativsystem har lyckats minska effekten av overdraw dramatiskt och systemet kan automatiskt avlägsna enkla situationer med overdraw som exempelvis när en vy är helt täckt av en annan vy (Sillars, 2015). Utvecklare bör undvika overdraw och Android föreslår att detta görs genom att ta bort onödiga bakgrunder i layout, ha en plan och icke nästlade vy och minska antalet transparanta pixlar (Android Developers, u.å.) Trådar Main thread kallas inom Android ofta för UI thread och är den enda tråd som kan hantera funktioner och processer som påverkar och ändrar användargränssnittet. Om en specifik funktion eller process kommer blockera renderingen bör denna del förflyttas till en annan tråd än main thread (Sillars, 2015). Funktioner och processer som kan 42

51 blockera en UI thread är de som är tids- och driftkrävande och om ingen respons sker inom fem sekunder kommer Android systemet aktivera ANR. ANR står för Application Not Responding och innebär att Android visar en dialog-ruta för användaren där hen kan välja att tvinga applikationen att stängas. Mañas & Grancini (2016) anser att sådana problem i en applikation bör vara prioriterade att åtgärda. 43

52 4 Empiri I avsnittet ges en beskrivning av den empiriska data som samlats in under studiens experiment för de olika applikationerna. För att besvara den andra frågeställningen Hur skiljer sig renderingen av användargränssnittet hos webbapplikation, hybridapplikation och nativeapplikation?, utvecklades en applikation för varje applikationstyp och mätningar utfördes på fyra testvyer för alla applikationer. De fyra test-vyerna presenteras nedan med deras resultat för varje applikation och nativeapplikationen utförde ingen overdraw på någon av testvyerna. 4.1 Loading icon I Loading icon-vyn utfördes processen att måla om pixlarna i nativeapplikationen vid knapptrycket och sedan varje gång progressbaren roterade, dock målades enbart själva progressbaren om. För hybridapplikationen utfördes också paint-processen vid knapptrycket, dock målades alla pixlar om i hela WebView-modulen och detta upprepades under hela animationen. Webbapplikationen gick igenom paint-processen vid knapptrycket och när ikonen dök upp, men sedan utfördes ingen mer paint-process under testet. Mätdata av RAM-minnets användning som samlats in vid applikationernas utförande av Loading icon presenteras nedan i Tabell 3 och webbapplikationen använde i genomsnitt mest RAM-minne, medan nativeapplikationen i genomsnitt använde minst minne. Tabell 3. Medelvärden på de tre applikationstypernas användning av RAM-minnet för de fem respektive testerna i Loading icon-vyn. Användning av RAM-minnet: Native Hybrid Webb Medelvärde av total användning (MB): Mätdata av den grafiska prestandan för applikationerna i Loading icon-vyn presenteras nedan i Tabell 4 och de beräkningar som utförts för att erhålla medelvärdet på mätdatan beskrivs i Tabell 1 och Tabell 2. Nativeapplikationen renderade flest antal bildrutor under dessa tester och bildrutorna renderades inom intervallet 5 30ms. 44

53 Nativeapplikationen hade flest bildrutor renderade vid 19ms, vilket kan ses Figur 12 eller i Bilaga 17 för en enklare överskådning av bara nativeapplikationens rendering. Hybridapplikationen renderade i snitt 3 bildrutor färre än nativeapplikationen och bildrutorna renderades inom intervallet 6-40ms, se Figur 12 eller Bilaga 17 för att enbart se hybridapplikationens rendering. Hybridapplikationen renderade flest bildrutor vid 19ms och hade i medel lägst FPS vid testerna. Webbapplikationen som renderade minst antal bildrutor, var den applikation vars renderingstid hade störst intervall. Bildrutorna renderades inom intervallet 8-101ms och även denna rendering kan ses i Figur 12 eller i Bilaga 17. Webbapplikationen hade den högsta genomsnittliga tiden per bildruta, alltså högst FPS. Diagrammet i Figur 12 och de enskilda diagrammen i Bilaga 17 grundar sig i data från Tabell 5 som är de totala antal bildrutor som sammanlagt renderades i alla fem tester. Native- och hybridapplikationen hamnade runt 98% ojämna bildrutor sammanlagt i alla fem tester, vilket kan ses i Tabell 5. Totala antalet ojämna bildrutor renderade för native- och hybridapplikationer gentemot totala antal renderade bildrutor för de applikationerna var ganska högt och i diagrammet i Figur 12 är det tydligt att många bildrutor renderades efter 16ms i dessa tester. Webbapplikationen hade istället 67 % ojämna bildrutor totalt renderade och webbapplikationen hade sin högsta punkt vid 17ms. Tabell 4. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn. Medelvärde på grafisk Native Hybrid Webb prestanda: Antal bildrutor renderade: FPS: 51,2 48,6 59,6 Antal ojämna bildrutor: Minnesanvändning (MB): 1,7 1,0 5,2 45

54 Figur 12. Diagram över renderingstiden för varje bildruta i Loading icon för alla applikationstyper. Tabell 5. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Loading icon-vyn. Sammanställning av grafisk prestanda: Native Hybrid Webb Totalt antal bildrutor renderade: Antal bildrutor med renderingstid över 16ms (%): 98,9% 98,5% 67,0% I Tabell 6 presenteras den genomsnittliga användningen av CPU i applikationernas testmätningar i Loading icon-vyn. Hybridapplikationen använder i snitt mest CPU medan webbapplikationen använde minst. Tabell 6. Medelvärden på de tre applikationstypernas CPU-användningen av de fem respektive testerna i Loading icon-vyn. Medelvärdet av CPUanvändning Native Hybrid Webb CPU-användning (%): 10% 14% 4% 46

55 I Tabell 7 presenteras batterianvändning i applikationernas tester i Loading icon-vyn. Webbapplikationen hade högst nivåskillnad i genomsnitt på batterianvändningen och nativeapplikationen hade minst. I spänningsskillnad hade dock nativeapplikationen det högsta snittet och webbapplikationen hade det lägsta. Tabell 7. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Loading icon-vyn. Medelvärdet för batterianvändning: Native Hybrid Webb Nivåskillnad: 9,0 10,0 10,3 Spänningsskillnad (mv): Spänningsskillnad (%): 6,3% 6,2% 5,9% 4.2 Interaction I Interaction-vyn utförde nativeapplikationen processen att måla om pixlarna varje gång bilden förflyttades, men det var bara bildens pixlar som målades om. För hybridapplikationen utfördes också paint-processen vid förflyttning av bilden, dock målades alla pixlar om i hela WebView-modulen och detta upprepades vid varje förflyttning. Webbapplikationen gick igenom paint-processen när bilden förflyttas, men bara bildens pixlar målades om. Det var endast i Interaction-testerna på webbapplikationen som det var visuellt synligt på skärm och inspelade filmer att ojämna bildrutor renderades. Applikationernas användning av RAM-minnet vid Interaction-vyn presenteras nedan i Tabell 8, där det är urskiljbart att nativeapplikationen använde i snitt mest RAM-minne och hybridapplikationen använde minst. Tabell 8. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Interaction-vyn. Användning av RAM-minnet: Native Hybrid Webb Medelvärdet av total användning (MB): Mätdata av den grafiska prestandan för applikationstyperna i Interaction-vyn presenteras nedan i Tabell 9 och beräkningarna som gjordes för denna tabell presenteras 47

56 i Tabell 1 och Tabell 2. GPU:s minnesanvändning var i snitt 87 % högre i nativeapplikationen jämfört med GPU:s minnesanvändning i webbapplikationen. Nativeapplikationen renderade 65% färre ojämna bildrutor än hybridapplikationen samt 54% färre än webbapplikationen. Hybridapplikationen hade lägst GPU-användning, men renderade flest ojämna bildrutor av alla applikationer och renderade 25 % mer av dem än webbapplikationen. Tabell 9. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn. Medelvärde på grafisk Native Hybrid Webb prestanda: Antal bildrutor renderade: FPS: 92,3 56,3 56,4 Antal ojämna bildrutor: Minnesanvändning (MB): 1,4 1,0 10,7 Nativeapplikationen renderade bildrutor inom intervallet 5-27ms och renderade flest av dem vid 9ms, vilket kan ses i Figur 13 eller i Bilaga 18 för att endast se nativeapplikations rendering. Nativeapplikationen renderade sammanlagt för alla tester i Interaction minst antal ojämna bildrutor, medan hybridapplikationen renderade mest antal ojämna bildrutor. Hybridapplikationen hade ett renderingsintervall på 5-53ms och där flest bildrutor renderades vid 18ms. Denna renderingsintervall kan ses i Figur 13, eller i Bilaga 18 för enklare överskådning av endast hybridapplikationens rendering. Webbapplikationen renderade minst antal bildrutor, men hade ett renderingsintervall på ms för bildrutorna. De flesta bildrutorna för webbapplikationen renderades på 17ms och det kan ses i Figur 13 eller Bilaga 18. Diagrammet i Figur 13 och de enskilda diagrammen i Bilaga 18 grundar sig i data från Tabell 10 som är de totala antal bildrutor som sammanlagt renderades i alla fem tester. 48

57 Figur 13. Diagram över renderingstiden för varje bildruta i Interaction för alla applikationstyper. Tabell 10. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Interaction-vyn. Sammanställning av grafisk prestanda: Totalt antal bildrutor renderade: Antal bildrutor med renderingstid över 16ms (%): Native Hybrid Webb ,2% 81,3% 66,4% I Tabell 11 presenteras den genomsnittliga användningen av CPU för de olika applikationernas testmätningar i Interaction-vyn och hybridapplikationen hade högst CPU-användning i denna vy. Webbapplikationen hade lägst CPU-användning, men använde endast 1% mindre utnyttjandegrad än nativeapplikationen. Tabell 11. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Interaction-vyn. Medelvärdet av CPUanvändning Native Hybrid Webb CPU-användning (%): 5% 13% 4% 49

58 4.3 Static View Applikationernas användning av RAM-minnet för Static View presenteras nedan i Tabell 12. Webbapplikationen använde i snitt mest RAM-minne av alla applikationerna, medan nativeapplikationen använde i genomsnitt minst av RAMminnet. Tabell 12. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Static View-vyn. Användning av RAM-minnet: Native Hybrid Webb Medelvärdet av total användning (MB): Inga bildrutor renderades i Static View för applikationerna och kan ses i Tabell 13. GPU:s minnesanvändning utnyttjades dock fortfarande i applikationerna och webbapplikationen utnyttjade i snitt 95% högre GPU-användning än hybridapplikationen och 52% mer än nativeapplikationen. Tabell 13. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Static View-vyn. Medelvärdet på grafiska prestanda: Native Hybrid Webb Bildrutor renderade: FPS: Ojämna bildrutor: Minnesanvändning (MB): 10,0 1,0 20,8 Ingen av applikationerna utnyttjade någon CPU-användning i testerna, vilket kan ses i Bilaga 19. I Tabell 14 presenteras batterianvändningen av applikationernas genomsnittliga testvärden i Static View-vyn. Hybridapplikationen hade högst nivåskillnad i snitt som låg vid 4,3 till skillnad från webbapplikation, som hade det lägsta snittet på 3. Webbapplikationen hade även lägst genomsnitt i spänningsskillnad, men applikationen med högst genomsnittlig spänningsskillnad var nativeapplikationen. Tabell 14. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Static View-vyn. Medelvärdet för Native Hybrid Webb batterianvändning: Nivåskillnad: 3,3 4,3 3,0 50

59 Spänningsskillnad (mv): 180,3 148,0 87,7 Spänningsskillnad (%): 4,2% 3,5% 2,1% 4.4 Animation I Animation-vyn utförde nativeapplikationen processen att måla om pixlarna hela tiden, dock ommålades enbart de roterande bilderna. För hybridapplikationen utfördes också paint-processen hela tiden, dock målades alla pixlar om i hela WebView-modulen och detta upprepades under hela animationen. Webbapplikationen gick inte igenom paintprocessen i denna test-vy på grund av att transform användes för att rotera objektet på skärmen. Applikationernas användning av RAM-minnet i Animation-vyn presenteras nedan i Tabell 15 och webbapplikationen använde mest av RAM-minnet medan nativapplikationen använde minst av RAM-minnet. Tabell 15. Medelvärden på de tre applikationstypernas användningen av RAM-minnet för de fem respektive testerna i Animation-vyn. Användning av RAM-minnet: Native Hybrid Webb Medelvärdet av total användning (MB): I Animation-vyn hade webbapplikationen 88% högra GPU:s minnesanvändning än nativeapplikationen och hela 92% högre minnesanvändning än hybridapplikationen, se Tabell 16. Webbapplikationen hade dock det lägsta medelvärdet av antal ojämna bildrutor medan nativeapplikationen hade det högsta. Beräkningarna som gjordes för Tabell 16 presenteras i Tabell 1 och Tabell 2. Tabell 16. Medelvärden på de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn. Medelvärdet på grafiska Native Hybrid Webb prestanda: Antal bildrutor renderade: FPS: 49,5 46,9 59,5 Antal ojämna bildrutor: Minnesanvändning (MB): 1,4 1,0 12,0 Nedanför i Figur 14 presenteras de sammanlagda testernas rendering av antal bildrutor samt antalet ojämna bildrutor renderade för alla applikationstyper. Diagrammet i Figur 51

60 14 och diagrammen i Bilaga 20 bygger på data som kan ses i Tabell 17. Nativeapplikationen renderade den högsta andelen ojämna bildrutor av de totalt antal renderade bildrutorna i de utförda testerna i Animation-vyn. Nativeapplikationen hade även ett renderingsintervall på 8-44ms med flest bildrutor renderade vid tiden 19ms, se Figur 14 eller Bilaga 20 för att enklare överskåda nativeapplikationens rendering. Hybridapplikationen hade ett renderingsintervall på 10-40ms där flest bildrutor renderades vid 19ms, se Figur 14 och Bilaga 20. Webbapplikationen renderade minst antal ojämna bildrutor i de sammanställda testerna och hade ett renderingsintervall på 8-48ms med flest bildrutor renderade vid 17ms, vilket också kan ses i Figur 14 och Bilaga 20. Figur 14. Diagram över renderingstiden för varje bildruta i Animation för alla applikationstyper. Tabell 17. Sammanställning av de tre applikationstypernas grafiska prestanda av de fem respektive testerna i Animation-vyn. Sammanställning av grafisk prestanda: Totalt antal bildrutor renderade: Antal bildrutor med renderingstid över 16ms (%): Native Hybrid Webb ,1% 96,2% 25,4% 52

61 I Tabell 18 presenteras användning av CPU för de olika applikationstyperna i Animation-vyn. Hybridapplikationen använde i Animation mest CPU i snitt och använde hela 13% mer än webbapplikationen, som i genomsnitt hade lägst CPUanvändning. Tabell 18. Medelvärden på de tre applikationstypernas CPU-användning av de fem respektive testerna i Animation-vyn. Medelvärdet av CPUanvändning: Native Hybrid Webb CPU-användning (%): 13% 16% 3% I Tabell 19 presenteras den genomsnittliga batterianvändningen för de olika applikationerna i Animation-vyn. Native- och hybridapplikationen hade båda ett genomsnitt på 12,3 i nivåskillnad på batterianvändningen, men hybridapplikationen har högst genomsnitt i spänningsskillnad. Webbapplikationen som hade lägst medelvärde på nivåskillnad i batteri, hade ett högre medelvärde i spänningsskillnad än nativeapplikationen. Tabell 19. Medelvärden på de tre applikationstypernas batterianvändning av de tre respektive testerna i Animation-vyn. Medelvärdet för Native Hybrid Webb batterianvändning: Nivåskillnad: 12,3 12,3 11,7 Spänningsskillnad (mv): Spänningsskillnad (%): 6,2% 7,6% 7,0% 53

62 5 Analys I avsnittet ges svar på studiens två frågeställningar genom att behandla samt analysera insamlad teori och empiri. 5.1 Frågeställning 1 En analys av insamlad data från en litteraturstudie har gjorts och nedan följer en analys för att besvara studiens första frågeställning: Vilka parametrar kan påverka rendering av användargränssnittet på en mobil applikation? De parametrar som kan påverka renderingen av en bildruta är batterietanvändningen, RAM-minnet, GPU-användning och CPU-användning (Lewis, 2017). Dessa parametrar påverkas av olika faktorer som kan leda till negativ påverkan av renderingen i användargränssnittet och de påverkande faktorerna är olika för de tre applikationstyperna. Genom att optimera batterianvändningen kommer även applikationens prestanda att optimeras. Batterianvändningen påverkas av enhetens skärm, CPU och signaler som Wifi och Bluetooth. När CPU genomför tunga beräkningar, skärmuppdateringar eller hanterar nätverksanvändning belastas CPU och därmed belastas batteriet (Sillars, 2015). För att hantera minne i programmeringsspråk som Java och JavaScript finns Garbage Collection som är en faktor som kan påverka renderingsprocessen genom att pausa och försena renderingen. Det är viktigt att ha en bra minneshantering för att undvika att garbage collection tar för lång tid att utföra sitt arbete. Bra minneshantering fås genom att bland annat använda rätt datatyp, rensa onödiga objekt i kod, använda få temporära objekt, undvika memory churn och minnesläckor (Mañas & Grancini, 2015). För webb- och hybridapplikationer är de påverkande faktorerna på parametrarna desamma och kommer följande nämnas och beskrivas kortfattat, men finns beskrivna i mer detalj i avsnitt och JavaScript är en faktor som påverkar renderingsprocessen och kan i många fall vara långsam att exekvera i mobila applikationer. Vid utveckling av mobil applikation i JavaScript är det viktigt att tänka på att undvika omberäkningar, ändringar i DOM, callbacks och speciellt undvika att 54

63 belasta main thread. För att undvika denna belastning skall istället web workers användas för tid- och drift-krävande funktioner och processer (Bermes, 2015). Framework och bibliotek som innehåller JavaScript-kod kan påverkar renderingsprocessen och kan därav vara långsamma att exekvera (Lewis, 2017). Style i renderingsprocessen är ytterligare en faktor som kan påverka renderingen och här är det av intresse att reducera komplexiteten hos selektorerna samt undvika designändringar på element. Vid design-uppdateringar behöver nämligen elementen kontrolleras gentemot selektorerna för att se att de följer design-bestämmelserna. Ett mardrömsfall är om alla element måste kontrolleras gentemot alla selektorer. Layout och Paint i renderingsprocessen är två stora faktorer som kan påverka renderingen och är två processer som helst skall undvikas helt om det är möjligt. De två CSS attributen transform och opacity är två bra sätt att ändra på element utan att trigga varken Layouteller Paint-processen. Om Layout-processen behöver utföras är det viktigt att undvika att ha en komplex layout samt att undvika att för många element kräver omberäkning av layouten. En av de viktigaste sakerna att undvika i layout är dock forced synchronous layout. Paint-processen är oftast den långsammaste processen i renderingsprocessen för webb- och hybridapplikationer och om den måste utföras är det viktigt att undvika att den sker i en animation. De steg som utförs i composite kan vara faktorer som påverkar renderingen om processen har för många lager att hantera, vilket både tar tid och minne. Fler påverkande faktorer kan vara interaktionshanterare och felaktig skriven samt felaktigt hanterad kod i HTML. Interaktionshanterare kan blockera rendering av bildrutor och orsaka onödigt arbete för layouten. Hanterarna bör exekvera snabbt och sedan låta composite utföra sitt arbete (Lewis, 2017). I HTML-kod bör fokusen enligt Bermes (2015) ligga vid att skriva korrekt syntax och avlägsna oanvända element, eftersom dessa förhindrar en snabb och effektiv applikation. För nativeapplikationer i Android kommer de faktorer som påverkar renderingsprocessen att beskrivas nedan, men beskrivs mer i detalj i avsnitt Två faktorer som kan ha en inverkan på de parametrar som kan påverka renderingsprocessen i nativeapplikationer är hierarki och nästlade vyer. Att ha en hierarki med många noder och nästlade vyer förlänger renderingstiden och är något som skall undvikas. Overdraw som innebär att pixlar ritas ut på varandra, är en annan orsakande faktor på de parametrar som påverkar renderingsprocessen och är något som är viktigt att undvika 55

64 (Sillars, 2015). Felaktig användning av trådar kan vara en annan faktor som orsakar att parametrar påverkar renderingen och speciellt om tid- och drift-krävande funktioner och processer sker på självaste UI Threaden. En sådan situation skulle resultera i att användargränssnittets rendering skulle blockeras och ett lagg skulle kunna vara synligt (Mañas & Grancini, 2016). Sillars (2015) rekommenderar att istället använda andra trådar och tillåta UI Thread att enbart hantera användargränssnittet. 5.2 Frågeställning 2 En analys av insamlad data från en experimentell studie har gjorts och nedan följer en analys för att besvara studiens andra frågeställning: Hur skiljer sig renderingen av användargränssnittet hos webbapplikation, hybridapplikation och nativeapplikation? För att besvara frågeställningen formulerades hypotesen Nativeapplikation prestera bättre än både webbaserad hybrid- och webbapplikation vid utförande av identiska uppgifter. Ur hypotesen formulerades förutsägelsen Vid utförande av identiska uppgifter kommer nativeapplikationer alltid erhålla bättre resultatvärde än hybrid- och webbapplikation på samma enhet Loading icon I test-vyn Loading icon presterade webbapplikation genomgående bäst och det innebär att applikationen hade en hög FPS samt renderade minst antal ojämna bildrutor. Det var en procentuellt stor skillnad på native- och hybridapplikationens antal ojämna bildrutor i totalt alla fem tester som låg på cirka 98 % gentemot webbapplikationens 67 %. Lewis (2017) förespråkar att ha ett lågt antal ojämna bildrutor renderade, vilket innebär att bildrutorna skall renderas inom 16ms. Webbapplikationen levererade minst ojämna bildrutor i Loading icon-vyn och hade flest bildrutor renderade vid 16-18ms. Webbapplikationen hade dock det största tidsintervall på renderingstiden och hade till och med några bildrutor renderade vid 101ms. Det långa tidsintervallet resulterar i att webbapplikationen missade några bildrutor och renderar totalt mindre bildrutor under testerna. Att de flesta bildrutor renderas kring 16ms resulterar dock i en hög FPS. Att webbapplikationen presterade bättre i dessa tester beror med stor sannolikhet på att transform användes för att rotera själva objektet. Med hjälp av transform kunde både 56

65 layout-processen och paint-processen undvikas enligt Lewis (2017), vilket möjliggjorde en snabbare rendering av bildrutorna. Nativeapplikationen renderade flest ojämna bildrutor i denna test-vy och detta beror troligtvis på att vid varje rotering behövde pixlarna målas om, vilket resulterade i att renderingen av bildrutorna tog längre tid. Hybridapplikationen presterade sämre i testerna än webbapplikationen och hade den lägsta FPS av alla applikationerna i dessa tester. Hybridapplikationen renderade flest bildrutor efter 19ms och var alltså inte lika nära 16ms som webbapplikationen. Hybridapplikationens prestation bör ha med att WebViewmodulen konstant uppdaterades och inte bara själva objektet målades om utan alla pixlar i WebView-modulen fick ritas om. Det är troligtvis av den anledningen som hybridapplikationen hade högst CPU-användning och webbapplikationen använde väldigt lite Interaction I test-vyn Interaction renderade nativeapplikationen flest bildrutor, minst antal ojämna bildrutor och hade högst FPS. Nativeapplikationen presterade alltså generellt sätt bättre än de andra applikationerna i denna test-vy. Webb- och hybridapplikationen presterade betydligt sämre i dessa tester och renderade betydligt fler ojämna bildrutor än nativeapplikationen. Nativeapplikationen fick genomgå hela renderingsprocessen från mätning till utmålning, men presterande ändå bättre än webb- och hybridapplikationen. Webbapplikationen hann inte rendera alls lika många bildrutor som de andra applikationerna. Detta kan bero på att renderingen på webbapplikationen varierade mycket i tid och bildrutor kunde ta upp mot 1,15 sekunder att rendera, vilket enligt Mañas & Grancini (2016) kan vara en synlig fördröjning som användaren kan uppfatta. Då vissa bildrutor tog så lång tid att rendera blev FPS låg, många bildrutor renderades ojämnt och webbapplikationen hann helt enkelt inte rendera ut fler bildrutor. Det var endast i dessa tester för webbapplikationen som det syntes på skärmen att ojämna bildrutor renderades. Webbapplikationens långa intervall berodde troligtvis på paintprocessen och även JavaScriptkoden som var tung att exekvera med sina eventlisteners som är en form av interaktionshanterare. Att paint-processen utfördes i dessa tester trots användning av transform beror på att Javascriptet uppdaterade DOM vid varje förflyttning av objektet och DOM i sin tur utförde en ändring i CSS-egenskaperna för ett HTML-element. Detta resulterade i att paint-processen ändå triggades och koden för 57

66 detta kan ses i Bilaga 3. Hybridapplikationen renderade flest ojämna bildrutor och hade även procentuellt flest ojämna bildrutor renderade sammanlagt i alla testerna för Interaction-vyn. FPS för hybridapplikationen är dock bättre än hos webbapplikationen, även om skillnaden är minimal. Att hybridapplikationen hade en acceptabel FPS med alla sina ojämna bildrutor är nog för att tidsintervallet för bildrutornas rendering inte alls är lika stor som för webbapplikationen. Fler bildrutor hade totalt sett hunnit renderas för hybridapplikationen och de ojämna bildrutorna ligger totalt sätt närmare 16ms än för webbapplikationen. Att hybridapplikationen renderade många ojämna bildrutor och hade en hög CPU-användning beror nog på WebView som målade om alla pixlar i hela modulen, istället för att endast uppdatera objektet som förflyttades Static View I Static View-vyn renderade ingen av applikationerna några bildrutor, men webbapplikationen använde mest av RAM-minnet och hade högst GPU-användning. Denna höga användning beror troligtvis på att applikationen exekverades i Chrome och GPU:s minnesanvändning i webbapplikationen var dubbel så stort som för nativeapplikationen. Applikationerna utnyttjade ingen CPU-användning, eftersom inga nya bildrutor behövde renderas och skickas till GPU Animation I test-vyn animation renderade alla applikationer nästan lika många bildrutor i snitt, men webbapplikationen hade en bättre FPS och presterade generellt sätt bättre än de andra två applikationerna i dessa tester. Nativeapplikationen hade flest ojämna bildrutor renderade i snitt, men även flest ojämna bildrutor procentuellt renderade i alla tester. Webbapplikationen hade lägst antal ojämna bildrutor renderade, vilket troligtvis berodde på att även i de här testerna användes transform. Nativeapplikationen behövde till skillnad från webbapplikationen mäta om objekten när de roterade och även måla ut dem på nytt. Hybridapplikationen som hade sämre FPS än nativeapplikationen behövde också mäta om och måla ut pixlarna på nytt på grund av WebView, men behövde till skillnad från nativeapplikationen utföra denna process på hela WebViewmodulen. På grund av alla stegen i renderingsprocessen som behövde genomgås för både native- och hybridapplikationen var CPU-användningen betydligt högre än i webbapplikationen. 58

67 5.2.5 Generell analys för alla test-vyer Generellt sätt i alla test-vyer var GPU-användningen betydligt högre i webbapplikationen än övriga applikationer och en anledning till detta kan vara att applikationen exekverades i Chrome. En annan anledning kan vara att i alla tester förutom Interaction-vyn undveks layout- och paint-processen med hjälp av transform. Resultatet blev att användargränssnittets alla objekt kunde laddas upp till GPU och förbli kvar där utan att skrivas över. Transform skapar även nya composite-lager som sparas i GPU och dessa lager tar mycket plats (Lewis, 2017). Webbapplikationen CPUanvändning var generellt sätt låg och kan ha med att mycket sparades i GPU. Då inga nya renderingsprocesser skedde förutom i Interaction-vyn så behövde inte CPU konvertera och ladda upp objekt till GPU (Google Developers, 2015). Native- och hybridapplikationen hade generellt sätt låg GPU-användning, då de istället utförde processen att måla om pixlar i alla test-vyer förutom Static View. Deras CPUanvändning var däremot betydligt högre. Hybridapplikationen som inte bara målade om det förändrade objektet utan hela WebView-modulen hade högst CPU-användning i alla tester förutom i Static View. Webbapplikationen använde mer RAM-minne än de andra applikationerna förutom i test-vyn Interaction och har troligtvis med att applikationen exekverades i Chrome. I batteritesterna var det inga större nivåskillnader mellan applikationen utan den största nivåskillnaden låg på 1,3 nivåer Resultat av analys Resultatet indikerar att förutsägelsen inte stämde då nativeapplikationen inte alltid gav bättre resultatvärde än webb- och hybridapplikationer på samma enhet och på identiska uppgifter. Följaktligen innebär detta att hypotesen är falsk och att en nativeapplikation inte alltid presterar bättre än webb- och hybridapplikationer i utförandet av identiska uppgifter. 59

68 6 Diskussion och slutsatser I detta avsnitt diskuteras och sammanfattas studiens resultat. Det ges även rekommendationer angående resultatet och vidare forskning inom studiens området. 6.1 Resultat Syftet med studien var att undersöka vilka parametrar som kan komma att påverka applikationens rendering av användargränssnittet samt hur den skiljer sig i webb-, hybrid- och nativeapplikation. För att uppfylla syftet utfördes en litteraturstudie och ett antal experiment för att besvara följande två 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? De parametrar som kan påverka renderingen av användargränssnittet för alla mobila applikationer är CPU-användning, GPU-användning, användning av RAM-minnet och batterianvändning. Det finns negativa faktorer som orsakar att de nämnda parametrarna ovan kan påverka renderingsprocessen ogynnsamt. Minneshantering är en av de negativa faktorerna som kan orsaka att garbage collection blockerar renderingen av användargränssnittet och det beror oftast på dålig hantering av minnet (Mañas & Grancini, 2015). Batterianvändningen påverkas av tunga CPU beräkningar, skärmtyp samt nätverksanvändning och dessa negativa faktorer kan i sin tur påverka renderingen (Sillars, 2015). Användningen av RAM-minnet och batterianvändningen har mätts i testerna, men har inte varit studiens fokus utan har istället samlats in för att kunna urskilja drastiska förändringar samt för ett helhetsperspektiv. Testerna visade att batterianvändningen för de olika applikationstyperna inte hade någon nämnvärd skillnad. En anledning till detta resultat kan vara att testerna utfördes i flygplansläge och batterianvändningen förlorade då en av sina påverkande faktorer (Sillars, 2015). En annan anledning kan vara att alla tester utfördes på enbart en enhet och alltså endast en skärmtyp, AMOLED (OLED-info, 2017). Ytterligare en anledning kan vara att testerna endast utfördes i 30 min. Den minimala skillnaden i batterianvändning kan också vara 60

69 för att nivåskillnad och spänningsskillnad inte är de rätta mätvärdena att jämföra, utan strömförbrukning hade kanske varit ett bättre mätvärde att jämföra. Strömförbrukning erhölls dock inte från ADB eller Chrome DevTools utan det hade behövts mer avancerade verktyg för att utföra sådana mätningar. En faktor som kan påverka renderingen för webb- och hybridapplikationer är JavaScript som enligt Bermes (2015) kan vara tung att exekvera för mobila applikationer och som dessutom kan ses i testerna för dessa applikationstyper i Interaction-vyn. Detta är väldigt tydligt i webbapplikationen då koden använder transform men ändå genomgår renderingsprocessen. Detta eftersom JavaScriptet hanterar fingrets positions samt skriver till DOM att ändra CSS-egenskaper för HTML-elementet så fort fingret byter position. Detta leder till att ommålningar av pixlar sker, trotts användning av transform och att JavaScriptet måste utföra flertal uppdateraringar i DOM. Resultatet blev att många ojämna bildrutor renderades, FPS blev låg och renderingsintervallet blev väldigt stort. I det stora hela presterade webb- och hybridapplikationen betydligt sämre i Interaction-vyn än nativeapplikationen. Hybridapplikationen renderade mest ojämna bildrutor i Interaction-vyn, men renderade även flest bildrutor av alla applikationerna totalt. Resultatet indikerar att om webbapplikationen hade fått rendera lika många bildrutor som hybridapplikationen gjort i detta test, hade antal ojämna bildrutor varit mer likvärdiga för de två applikationerna. I alla test-vyer undveks framework och bibliotek att användas då de är ytterligare två faktorer som kan påverka renderingen av användargränssnittet och speciellt om de innehåller JavaScript (Lewis, 2017). Fler faktorer för webb- och hybridapplikationer som kan påverka parametrarna är Style, Layout och Paint (Lewis, 2017). I webb- och hybridapplikationen användes transform som är en designändring i Style, dock är det en designändring som rekommenderas att användas för att ändra utseende på element samt skapa illusionen av en animation (Lewis, 2017). Vid användning av transform skippas både Layout- och Paint-processen enligt Lewis (2017) och är en stor faktor till varför webbapplikationen presterade bättre än nativeapplikationen i tester som Animation och Loading icon. I Animation skrevs koden för animationen manuellt i nativeapplikationen och det skulle kunna vara en anledning till den sämre prestationen, men i Loading icon användes till och med Androids inbyggda progressbar. Nativeapplikationen behövde fortfarande i dessa vyer 61

70 måla om pixlarna vid varje rotation och det är en möjlig förklaring till varför renderingsprocessen tog mycket längre tid för nativeapplikationen (Sillars, 2015). De steg som utförs i Composites kan vara faktorer för webb- och hybridapplikationen när för många composite-lager används och i testerna användes flera olika lager varje gång transform användes (Lewis, 2017). Dessa lager bör dock inte varit tillräckligt många i antal för att komma upp i den mängd som behövs för att vara en påverkande faktor i denna studie. Alla dessa lager kan dock vara en av anledningarna till att GPU:s minnesanvändning var hög i webbapplikationen (Lewis, 2017). Det finns fler påverkande faktorer för webb- och hybridapplikationer och en av dem är enligt Lewis (2017) Interaktionshanterare och en annan är enligt Bermes (2015) felaktig hantering av HTML-kod. Felaktig hantering av HTML-kod har med stor sannolikhet inte varit en påverkande faktor i denna studie då alla onödiga element har avlägsnats samt att syntaxen har kontrollerats noga. Interaktionshanteraren kan dock ha varit en påverkande faktor i dessa tester då en form av interaktionshanterare i JavaScriptkoden användes i webb- och hybridpplikationen för Interaction-vyn. Just i dessa tester presterade webb- och hybridapplikationen betydligt sämre än nativeapplikationen och för webbapplikationen var även några av de ojämna renderade bildrutorna synbara på test-enhetens skärm. I nativeapplikationer är hierarki och nästlade vyer två faktorer enligt Lewis (2017) som kan komma att påverka renderingsprocessen, men i studien användes ConstraintLayout i alla tester förutom i Interaction-vyn. ConstraintLayout förebygger enligt Android Developers (u.å.) mot dessa faktorer och Interaction var ett såpass litet test att inga hierarkier med nästlade vyer förekom. Overdraw är en viktig faktor att undvika i nativeapplikationer enligt både Sillars (2015) och Android Developers (u.å.), vilket har gjorts i dessa tester och är inte en av faktorerna som påverkade renderingsprocessen i studien. En annan faktor som också kan påverka renderingen i nativeapplikationen anser Sillars (2015) är trådar och i alla tester har allt skett på main thread eller UI Thread, eftersom inga tyngre beräkningar skulle utföras. Hybridapplikationen presterade oftast sämre än webbapplikationen trots att de exekverade samma kod och detta förklaras av WebView. WebView-modulen målade om pixlar på skärmen så fort en interaktion eller animation skedde och den målade om alla pixlar i hela WebView-modulen. Med alla pixlar inkluderas även de vita pixlarna som egentligen inte hade ändrats. En WebView-modul bör alltså inte vara större än 62

71 objektet den innehåller för att undvika att onödigt många pixlar målas om, då hybridapplikationen förlorar mycket tid på detta och var något som tydligt framkom från studiens experiment. I litteraturstudien nämndes det av bland annat Sillars (2015) att applikationer i Android skulle undvika omberäkning och ommålning av pixlar, dock beskrevs och diskuterades detta inte lika mycket som det görs inom webbapplikationer av bland annat Lewis (2017). Det finns en mängd rekommendationer inom webbapplikationer hur vissa steg i renderingsprocessen kan undvikas, medan i Android finns inte rekommendationer för sådana lösningar. Inom Android ges snarare rekommendationer hur utvecklare skall undvika att förlänga renderingsprocessens tid i onödan. Dessa rekommendationer kan vara att undvika faktorer som hierarkier och nästlade vyer (Sillars, 2015). Bristen på lösningsförslag på omberäkning och ommålning är antagligen för att det inom Android inte finns något liknande som transform, utan själva beräkning och ommålning av pixlar är något som bara får accepteras att det görs. Därav diskuteras det mer om de faktorer som kan påverka att ommålning av pixlar tar längre tid, som nästlade vyer. 6.2 Implikationer Den här 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 ha som grund i deras val av applikationstyp. Studien påvisar att alla applikationstyper är värda att överväga, dock presterade webb- och nativeapplikationen bättre i studien än vad hybridapplikationen gjorde. Webbapplikationer lämpar sig för företag som vill spara utvecklings- och förvaltningstid samt kan tänka sig att använda statiska animationer. Enligt studien lämpar sig nativeapplikationen för applikationer med mycket interaktioner från användare och interaktiva animationer. Hybridapplikationen är en lämplig applikation för de företag som inte är i behov av en allt för krävande applikation, men ändå vill spara utvecklingstid och ha en applikation som kan nås via app-butiker. 6.3 Begränsningar Även om studien resulterade i att syftet uppfylldes fanns det begränsningar och som påverkade utförandet och resultatet. Begränsningar som har funnit är bland annat att det 63

72 inte gick att få ut grafisk prestanda för webbapplikationer via ADB utan Chrome DevTools fick användas istället. Tyvärr går det inte att utföra längre tester via Chrome DevTools och de långtidstester som redan utförts på alla applikationer och test-vyer kunde inte längre användas. Ytterligare begränsningar har varit att ADB inte gav mycket information om batterianvändning förutom skillnader i nivå samt spänning. För att få ut mer information att jämföra behövdes mer avancerade verktyg och därav fick en enklare och mer översiktlig jämförelse utföras där drastiska skillnader undersöktes. 6.4 Slutsatser och rekommendationer Webbapplikationen presterar generellt bättre vid statiska animationer än vad native- och hybridapplikationer gjorde och en betydlig fördel för webbapplikationen är dess möjlighet att använda sig av attributen transform och opacity. Studien visar hur överlägsna dessa attribut kan vara gentemot Androids egna implementationer. Webbapplikationen är ett bra alternativ för de företag som vill spendera mindre tid och pengar på en mobilapplikation som fungerar på alla operativsystem. Möjligtvis bör webbapplikationen använda sig mer utav statiska animationer istället för interaktiva animationer så ofta som möjligt. Nativeapplikationer presterar överlägset bättre vid studiens interaktiva animationer och är en applikationstyp att överväga om tyngre beräkningar eller många interaktiva animationer skall ske. Hybridapplikationen som presterade sämre än de andra två applikationstyperna under studien bör användas på andra sätt än som gjorts under studien. Förslagsvis kan mer av logik och funktionalitet flyttas över till native-delen och mer av hybridapplikationens arkitekturdelar kan användas. Helt enkelt bör mindre krävande handlingar utföras i WebView och WebView bör eventuellt vara mindre när den inte behöver täcka hela skärmen. Det finns även färdiga ramverk som underlättar samt optimerar utvecklingen av hybridapplikationer. Hybridapplikationer kan dock fortfarande finnas med som ett alternativ, fast då för mindre krävande applikationer. En slutgiltig rekommendation är att alla applikationstyper bör finnas med som en valmöjlighet. Företag och utvecklare bör fastställa vad applikationens användarområde skall vara samt vart de vill placera sin fokus och med hjälp av studiens resultat kan de fastställa vilken applikationstyp som är mest lämplig för dem att använda. 64

73 6.5 Vidare forskning I den här studien testades applikationernas prestation vid en enstaka animation och även vid flera animationer som sker samtidigt, dock hade det varit av stort intresse att se när användargränssnittets prestanda först börjar påverkas i de olika applikationstyperna. Tidigare studier har gjorts på native- och hybridapplikationens prestanda vad gäller beräkning och datasortering, men det vore även av intresse att se hur en ren webbapplikation hade presterat under sådana tester. Det vore också av intresse att kontrollera och fokusera på minnesanvändning och batterianvändning. I denna studie gjordes endast enkla mätningar av dessa parametrar och det hade därmed varit intressant att utföra vidare studier som på djupet kontrollera vad minnet används till och hur det hanteras. Det hade också varit intressant att utföra vidare studier som undersöker hur batterianvändningen skiljer sig i de olika applikationstyperna i form av strömförbrukning och vilka faktorer som påverkar mest. Det utfördes långtidstester på alla applikationstyper, men efteråt upptäcktes det att webbapplikationen inte kunde få data gällande grafiken från ADB. Då Chrome DevTools inte kunde utföra långtidstester kunde inte de redan utförda testerna jämföras. Om verktyg skulle tillkomma som underlättar längre testmöjligheter för webbapplikationer hade det varit av intresse att utföra just långtidstester. Det hade även varit av intresse att utföra testerna på fler test-enheter eftersom de givna resultaten kan skiljas på andra enheter. Ett sista förslag på vidare forskning är att introducera ios i dessa tester för att kontrollera hur webb- och hybridapplikationer presterar på en ios-enhet jämfört med en nativeapplikation för ios-operativsystemet. 65

74 Referenser Android Developers. (u.å.). Testing UI Performance. Hämtad 6 november, 2017, från Android Developers. (u.å.). Performance and View Hierarchies. Hämtad 6 november, 2017, från Android Developers (u.å.). Reducing Overdraw. Hämtad 6 november, 2017, från ml Android Developers (u.å.) Build a Responsive UI with ConstraintLayout. Hämtad 8 februarui, 2018, från Android Developers (u.å.) Processes and Threads. Hämtad 10 oktober, 2018, från AppDynamics (2014). Mobile app performance explained. An AppDynamics Business White Paper, 1-4. Hämtad 4 november, 2017, från Bermes, B. (2015). Lean Websites. Australien: SitePoint Pty.Ldt. Tillgänglig via Blomkvist, P., & Hallin, A. (2015) Metod för teknologer: Examensarbete enligt 4- fasmodellen. Lund: Studentlitteratur. Christenssin, P. (u.å.). TechTerms. Hämtad 6 november, 2017, från Colby.edu. (u.å.). The Experimental Method. Hämtad 9 september, 2017, från: Davidsson, P., & Findahl, O. (2016). Svenskarna och internet 2016: Undersökning om svenskarnas internetvanor. Sverige: IIS. Hämtad 16 september, 2017, 66

75 från: Directive 2009/24/EC. On the legal protection of computer programs. Hämtad 6 mars, 2018, från 2:EN:PDF Eliasson, A. (2013) Kvantitativ metod från början. Lund: Studentlitteratur. Georgiev, M., Jana, S. and Shmatikov, V. (2014). Breaking and Fixing Origin-Based Access Control in Hybrid Web/Mobile Application Frameworks. Austin: NDDS Symp. Hämtad 11 september, 2017, från Gok, N. & Khanna, N. (2013) Building Hybrid Android Apps with Java and JavaScript. USA: O Reilly Media. Tillgänglig via d/ Google Developers (2015, 6 januari) Android Performance Patterns: Android UI and the GPU [Video]. Hämtad från PL6AVODi-Vyt9UEDC505r-Bn25lV6wQZX0 Google Developers (2015, 13 mars) Android Performance Patterns: Memory Churn and Performance [Video]. Hämtad från Google Developers (2018) Chrome DevTools. Hämtad 2 mars, 2018, från Laurens, T. (2013). How the V8 engine works?. Hämtad 4 oktober, 2017, från engine-works/ Lewis, P. (2017) Web fundamentals. Hämtad 10 november, 2017, från / LG (2018) What makes it the Best TV Ever. Hämtad 30 januari, 2018, från 67

76 Lillesveen, R. (2014) Style Invalidation in Blink. Hämtad 21 januari, 2018, från _xs9tcs1cs_eushrsgchgu8/view#heading=h.7wiu6661tens Lygnebrandt, E. & Holm, J. (2015) Prestanda av användargränssnitt i crossplatformappar. Kandidatuppsats, Jönköpings Tekniska Högskola. Hämtad från Mañas, E., Grancini, D. (2015). Android High Performance Programming: Build fast and efficient Android apps that run as reliably as clockwork in a multidecive world. Tillgänglig via jonk MDN. (2018). Will-change. Hämtad 14 februari, 2018, från Navarro, C., Hitschfeld-Kahler, N., & Mateu, L. (2014) A Survey on Parallel Computing and its Applications in Data-Parallel Problems Using GPU Architectures. Communications in Computational Physics, 15(2), Nenzén, J. (2014). Varför väljs nativeapplikationer istället för hybridapplikationer?: Prestandaskillnader hos hybridapplikationer. Magisteruppsats, Upsala Universitetet, Institutionen för informationsteknologi. Hämtad från Nilsson, E. & Lagerqvist, A. (2015). Mobila hybridapplikationers prestanda: En experimentell studie. Kanidatupppsats, Jönköpings tekniska högskola. Hämtad från Niranga, S. (2015) Mobile Web performance Optimization. Storbritannien: Packt Publishinh Ltd. Tillgänglig via nkop OLED-info. (2017). OLED vs. LED. Hämtad 30 januari, 2018, från 68

77 OLED-info. (2017). PMOLED vs AMOLED - what's the difference?. Hämtad 30 januari, 2018, från Persson.L, Tillborg. C. & Bentlöv. H. (2012). Utveckling av hybrid mobilapplikation fo r flera plattformar. Kanidatuppsats, Linnéuniveritetet Fakultetsnämnden för naturvetenskap och teknik, Institutionen för datavetenskap. Hämtad från Pålsson, M. (2014). Cross Platform Development tools for mobile applications, a performance and cost evaluation. KTH Skolan för datavetenskap och kommunikation. Hämtad från R.M.de Andrade, P., B.Albuquerque, A., F. Frota, O., V Silveira, R. and A. da Silva, F. (2015). Cross Platform App: A Comparative Study. International Journal of Computer Science and Information Technology, 7(1), Sillars, D. (2015) High performance Android apps : improve ratings with speed, optimizations, and testing. San Francisco: O Reilly Media. Tillgänglig via d/ Slick, J. (2017). What is Rendering?. Hämtad 4 oktober, 2017, från Svenskt Näringsliv (2016). Företagen och digitaliseringen. Hämtad från nionsmaterial/ Rapporter/foretagen-odigitaliseringenpdf_ html/BINARY/F%C3%B6retagen%20o%20 digitalisering en.pdf Techopedia. (u.å.). Frames Per Second (FPS). Hämtad 10 oktober, 2017, från Techopedia. (u.å.). Frames Per Second (FPS). Hämtad 10 oktober, 2017, från W3C. (2005). Document Object Model (DOM). Hämtad 10 oktober, 2017, från 69

78 W3C. (2018). WHAT IS CSS?. Hämtad 4 oktober, 2017, från W3C. (u.å.). The global structure of an HTML document. Hämtad 8 november, 2017, från W3C. (2017). Javascript APIs Current Status - W3C. Hämtad 5 november, 2017, från W3C. (u.å.). Painting: Filling, Stroking, Colors and Paint Servers. Hämtad 5 november, 2017, från IETF. (2014). Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Hämtad 10 november, 2017, från Wohlin, C. Runeson, P., Höst, M., Ohlsson, M., Regnell. B &Wesslén, A. (2012). Experimentation in Software Engineering. New York: Springer. Tillgänglig via 70

79 Bilagor Bilaga 1 XML-kod som används för test-vyn Interaction i nativeapplikationen. 71

80 Bilaga 2 JAVA-kod för test-vyn Interaction i nativeapplikation 72

81 Bilaga 3 hybridapplikationen. HTML-, JavaScript- och CSS-kod för test-vyn Interaction i webb- och 73

82 Bilaga 4 XML-kod för test-vyn Loading icon i nativeapplikationen. 74

83 Bilaga 5 JAVA-kod för test-vyn Loading icon i nativeapplikationen. 75

84 Bilaga 6 och hybridapplikationen. HTML-, JavaScript- och CSS-kod för test-vyn Loading icon i webb- 76

85 Bilaga 7 XML-kod som används för test-vyn Animation i nativeapplikationen. (1) (3) (2) (4) 77

86 (5) (6) 78

87 Bilaga 8 nativeapplikation. XML- och JAVA-kod gällande fragment för test-vyn Animation i 79

88 Bilaga 9 hybridapplikationen. HTML-, och CSS-kod för test-vyn Animation i webb- och 80

89 Bilaga 10 XML-kod för test-vyn Static View i nativeapplikation. (1) (2) (3) 81

90 Bilaga 11 hybridapplikationen HTML-, JavaScript- och CSS-kod för test-vyn Static View i webb- och 82

91 Bilaga 12 Egenskrivet källscript för avläsning av data 83

92 Bilaga 13 Egenskrivet källscript för interaktion i native- och hybridapplikationen. 84

93 Bilaga 14 Egenskrivet källscript för interaktion i webbapplikationen. 85

94 Bilaga 15 Egenskrivet källscript för avläsning av RAM, GPU och batteri data 86