Prestanda av användargränssnitt i crossplatformappar
Performance of user interface in crossplatform apps
Emil Lygnebrandt
Jonathan Holm
EXAMENSARBETE
2015
Datateknik
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom datateknik. Författarna svarar själva för framförda åsikter, slutsatser och resultat.
Examinator: Anders Carstensen Handledare: Peter LarssonGreen Omfattning: 15 hp
Abstract
The purpose of this study is to examine differences in delay during calculation and presentation of interfaces executing on different techniques. Specifically between native developed apps and generated apps. Since the work aims to contribute with information regarding performance, an experimental method was considered to be the best choice. Measurements of loading times was made with a video camera that captured the execution of the experiments which made the method simple and captures what the users would have experienced. Demarcation to the platforms Android and iOS was made and Xamarin was chosen as the framework for creating generated apps. Data from experiment that examined loading times, experiment with users that dealt with the responsiveness of lists and the analysis of CPU and memory usage indicate a recurring pattern. Xamarin Forms with XAML is the technique that has performed worst during the experiments, followed by Xamarin Forms. Xamarin Android/iOS didn’t have as big performance loss. Xamarin Forms does not manage the phones resources as efficient as Xamarin Android/iOS and native developed apps does. The results from this study can be used as material for making decisions witin organisations when choosing technology for creating apps. The study also contribute with data that can be used by other researchers. Keywords Crossplatform, Generated apps, Native apps, Xamarin, User interface, Performance, ExperimentSammanfattning
Syftet med denna studie är att undersöka fördröjningsskillnader inom användargränssnitt mellan nativeutvecklade appar (utveckling till varje plattform) och appar av typen generated apps. Eftersom arbetet syftar till att bidra med information om prestanda ansågs en experimentell metod vara det bästa valet. Mätning av laddningstider gjordes med hjälp av en videokamera som filmade utförandet av experimenten vilket gjorde metoden simpel och liknar det som en användare kommer att uppleva. Avgränsning till plattformarna Android och iOS gjordes där Xamarin valdes som ramverk inom tekniker som skapar generated apps. Mätdata från experiment som undersökte laddningstider, experiment med användare som hanterade listors respons samt undersökning av CPU och minnesanvändning tyder på ett återkommande mönster. Xamarin Forms med XAML är den teknik som presterat sämst under experimenten som sedan följs av Xamarin Forms. Xamarin Android/iOS hade inte lika stora prestandaförluster jämfört med nativeutvecklade delar. Generellt hanterar Xamarin Forms telefonens resurser sämre än vad Xamarin Android/iOS och native gör. Resultat från studien kan användas som beslutsstöd vid val av teknik. Studien bidrar även med data som kan användas vid vidare forskning inom området. Nyckelord Crossplatform, Generated apps, Native apps, Xamarin, Användargränssnitt, Prestanda, Experiment
Innehållsförteckning
1 Introduktion...7 1.1 Bakgrund...7 1.2 Problembeskrivning...7 1.3 Relaterad forskning...8 1.4 Prestanda av användargränssnitt...91.5 Syfte och frågeställningar...9
1.6 Omfång och avgränsningar...10
1.7 Disposition...10
1.8 Begreppsdefinition...11
2 Metod och genomförande...12
2.1 Koppling mellan frågeställning och metod...12
2.2 Arbetsprocessen...12
2.2.1 Experimentell metod...12
2.2.4 Utvecklingsmiljöer...13
2.2.5 Enheter...13
2.3 Hypotes och förutsägelse...14
2.4 Implementering...14
2.5 Mätmetod...18
2.6 Datainsamling och dataanalys...19
2.7 Trovärdighet...20 3 Teoretiskt ramverk...22 3.1 Olika apptyper...22 3.1.1 Native apps...22 3.1.2 Web apps...22 3.1.3 Hybrid apps...23 3.1.4 Generated apps...23 3.2 Xamarin...23 4 Empiri...25 4.1 Experiment av laddningstider...25
4.2 CPU- och minnesanvändning...28
4.3 Experiment med användare...31
5 Analys...33
5.1 Experiment av laddningstider...33
5.3 Experiment med användare...41
6 Diskussion och slutsatser...42
6.1 Resultat...42
6.2 Implikationer...43
6.3 Begränsningar...43
6.4 Slutsatser och rekommendationer...44
6.5 Vidare forskning...44
7 Referenser...46
8 Bilagor...48
Bilaga 1: Mätvärden för filmning av experiment...48
Bilaga 2: Stapeldiagram för mätdata från filmning av experiment....51
Bilaga 3: Enkät för experiment med användare...55
1
Introduktion
1.1
Bakgrund
Idag utvecklas mjukvara till många olika system och miljöer. Till dessa hör den mobila utvecklingen som har vuxit mycket under de senaste åren och förutspås fortsätta att växa [1]. Därmed finns även stor efterfråga på kompetens och nytänk. Ett problem som många företag blir tvungna att ta ställning till är vilka plattformar den aktuella produkten ska utvecklas till. Varje plattform har egna metoder för att utveckla sina appar. De har var och en olika operativsystem med sina programmeringsspråk och ramverk. Även utseénde, designriktlinjer och implementering skiljer sig. Detta gör att utvecklingen av en produkt för flera plattformar kan bli omfattande då det sker för varje enskild plattform, vilket fortsätter vid underhåll av produkten. Företagen har inte alltid resurser till detta och kan därmed bli tvungna att utesluta en del av marknaden. Dessutom behövs utvecklare med kompetens inom de olika teknikerna som används av de olika plattformarna. Inom crossplatformutveckling finns flera olika alternativ som är utformade för att hantera dessa problem men det kan dock vara svårt att veta vilka alternativ som fungerar bäst baserat på situationen. Sommaren 2015 utvecklade vi en crossplatformapp med ramverket Xamarin med delen Forms där användargränssnittet skapas gemensamt mellan plattformarna. Under utvecklingen upplevde vi att det genererade gränssnittet presterade sämre än nativeutvecklade appar. Det var främst laddning av en ny sida som kändes betydligt långsammare, men även listor hackade vid scrollning.1.2
Problembeskrivning
När företag ska besluta om vilken teknik de ska använda när de utvecklar sin produkt behövs underlag för att ta ett beslut som fungerar bra för deras situation. Det finns flera olika sätt att göra appar. Företagen behöver bestämma om det är värt att använda en crossplatformlösning eller om de ska utvecka native. Inom crossplatformlösningar finns det olika tekniker som resulterar i antingen web apps, hybrid apps eller generated apps. Med konkret data om vilka skillnader som finns mellan dessa alternativ och hur stor den eventuella skillnaden är så blir det lättare att fatta beslut angående tillvägagångssättet. Resultatet av studien är tänkt att bidra med ytterligare kunskap om prestandan för skapande av användargränssnittet inom apptypen generated apps (appar som görs i ett crossplatformramverk där kod för varje plattformgenereras) som Xamarin tillhör [2].
1.3
Relaterad forskning
Xanthopoulos och Xinogalos [3] beskriver vilka olika typer av alternativ det finns när det kommer till crossplatformutveckling och vad dessa kännetecknar. Vissa metoder och tekniker fungerar olika bra beroende på vad företaget är ute efter. Studien diskuterar om att lösningar genom generated apps verkar vara det mest uppskattade alternativet på grund av att dess resultat liknar det av nativeutveckling (utveckling till varje plattform). De uttrycker även ett behov av ytterligare forkning inom området. De föreslår bland annat undersökning av laddningstider och responsiviteten av användargränsnitt. Arbetet Mobila hybridapplikationers prestanda: En experimentell studie [4] jämför beräkningsmässig prestanda mellan crossplatformramverket PhoneGap som är av typen hybrid apps (crossplatformappar som utvecklas i ett ramverk där webbteknologi används men fortfarande tar tillvara på telefonens funktioner) och nativeutveckling. De kom fram till att det finns prestandaskillnader som varierade beroende på vilken plattform som kördes då många plattformar kör med olika JavaScriptmotorer. Även olika JavaScriptbibliotek som användes gav olika prestandaskillnader.Studien Varför väljs nativeapplikationer istället för hybridapplikationer [5] undersöker varför nativeutveckling ofta väljs före crossplatformutveckling. De kommer fram till en rad olika faktorer där en av dessa var hur prestandan upplevdes hos crossplatformvarianten. Intervjuer genomfördes där en del utvecklare som använt hybridlösningar samt nativeutveckling ansåg att appar blev söligare när de utvecklades till hybridlösningar. Det fanns flera delar av hybridlösningen som hackade eller inte hängde med vilket gjorde att appen upplevdes som segare än om den hade utvecklats till nativeplattformar. Vi ser tydligt att appar av typen generated apps är ett område som är i behov av mer forskning för att ta fram information som kan hjälpa företag att ta beslut när det kommer till utveklingen av deras produkt. Som Nenzén visar är företag intresserade av att minimera faktorer som fått dem att välja nativeutveckling där prestanda är en faktor i beslutsfattningen [5]. Nilsson och Lagerqvist undersökte prestanda för beräkningar inom ett sätt att utföra crossplatformutveckling och båda studierna saknar information om just generated apps [4].
1.4 Prestanda av användargränssnitt
Prestanda inom användargränssnitt kan innebära flera olika faktorer. Det kan handla om responstid, den tid det tar för att användaren ska se att det händer något efter en interaktion. Det kan också vara hur användare upplever animationer och småsaker vilket påverkar hur användaren uppfattar prestandan av appen. Det vi mäter är hur lång tid det tar för appen att presentera sitt innehåll efter en användarinteraktion. Det handlar alltså inte om att dokumentera hur animationer påverkar användarens upplevelse utan mer om hur snabbt de olika plattformarna kan beräkna och presentera användargränssnittet. Under tiden mäts även CPU och minnesanvändning för att se hur effektiva de olika plattformarna är. Listor som används för att presentera strukturellt repeterande data för användaren är som ett mellanting mellan animation och ren presentation av appens information. Dock så har vi valt att inkludera dessa eftersom dynamisk beräkning och hantering av användargränssnittet krävs för att visa dessa. Det är också ett vanligt sätt att presentera information i appar. Listors beteende gör det svårt att mäta och därför tas användares upplevelse upp till viss del i studien för att kunna dokumentera detta.1.5
Syfte och frågeställningar
Syftet med denna studie är att undersöka prestandan för användargränssnitt mellan nativeutvecklade appar (utveckling till varje plattform) och appar av typen generated apps. Fokus ligger på att identifiera eventuella prestandaskillnader. Lagerqvist och Nilsson undersöker prestandan för crossplatformappars logik och behandlar inte prestandan som krävs för att presentera användargränssnittet för användaren [4]. Prestandan för att presentera användargränssnittet är viktigt inom beslutsprocessen enligt Nazén och ett vanligt argument till varför företag inte väljer crossplatformmetoder [5]. Det finns studier som behandlar prestanda för crossplatformlösningar som använder sig av webbteknologier, därför vill vi utöka dessa med information om appar av typen generated apps. Därmed formulerar vi följande frågeställning: ● Hur stora fördröjningar inom presentation av användargränsnitt finns det mellan nativeutvecklade appar och crossplatformutvecklade appar av typen generated apps?1.6
Omfång och avgränsningar
Studiens mål är att undersöka fördröjningar i presenation av olika användargränssnitt mellan native och crossplatformutvecklade appar. Därmed inkluderas endast beräkningar som används för att presentera appars användargränssnitt. Studien omfattar inte om hur användare upplever fördröjningar baserat på animationer eller visuella trick utan helt enkelt från interaktion till presentation. Därför används inte animationer vid vypresentation i studien. Vi kände dock att det är viktigt att ta med listor eftersom det är ett vanligt sätt att presentera data för användaren. Till skillnad från vanliga animationer är listor mer som presentation av data än att förbättra användarupplevelsen. Studien kommer begränsa sig till ramverket Xamarin som är av apptypen generated apps. Xamarin omfattar Xamarin Android, Xamarin iOS, Xamarin Forms och Xamarin Forms med XAMLskapat användargränssnitt efter att vi exkluderat Windows Phone. Dessa jämförs sedan med de två vanligaste plattformarna, Andorid och iOS som tillsammans har 96,7% av marknaden [6].1.7
Disposition
Inledningen följs av kapitlet Metod och genomförande som beskriver hur arbetet genomfördes, vilka metoder som användes, hur data samlades in och hur den sammanställdes. Teoretiskt ramverk tar upp studiens teoretiska backgrund, vilka teorier som har använts och hur dessa hjälpte till att uppnå vårt syfte. Även viktiga grunder och begrepp inom området förklaras för att det ska bli lättare att följa med i arbetsprocessen och det resonemang som förs. Empiri sammanställer den data som införskaffats under projektets genomförande. Analyskapitlet går tillbaka till syftet med studien och jämför det med studiens resultat för att utvärdera arbetet. Därefter följer Diskussion och slutsatser där studiens resultat diskuteras. Här tas det som gick bra och dåligt upp samt de möjligheter som finns för att utveckla resultatet genom fortsatta arbeten inom samma område.
1.8 Begreppsdefinition
Native: Användning av native i detta arbete till exempel nativeutveckling eller nativeapp syftar till appar som är gjorda specifikt för en plattform med tillhörande utvecklingsverktyg. Crossplatform: Innebär att flera plattformar behandlas samtidigt. En crossplatformapp är en app som har utvecklats i ett verktyg som gör det möjligt att köra appen på flera plattformar. Kod mellan plattformarna är gemensam och plattformsspecifika delar minskas. User Interface (UI): Användargränssnitt, det användaren ser av applikationen. Användargränssnittet används som brygga mellan logiken och användaren. XAML (Extensible Application Markup Language): Ett XMLbaserat språk som används för att skapa användargränssnitt till applikationer som använder metoden, bland annat Microsoft Expression Blend och Xamarin Forms. Feedback: Återkoppling eller respons av något. Det kan till exempel vara att en användare trycker på en knapp och väntar på att något ska hända, det vill säga användaren väntar på en feedback.2
Metod och genomförande
2.1
Koppling mellan frågeställning och metod
Eftersom studien syftar till att bidra med information om prestanda ansågs en experimentell metod vara det bästa valet. Genom en experimentell metod kan variablerna dokumenteras för att bestämma hur de beter sig. Det gör det även möjligt att utforma experimenten så att användargränssnittets komplexitet kan varieras, vilket hade varit svårare vid utveckling av en prototyp eller liknande. Studien använder därmed en experimentell metod för att besvara frågeställningen där en rad experiment genomförts för att få en uppfattning om prestandan för användargränssnittet mellan användning av Xamarin Forms, Xamarin Forms med XAML, Xamarin iOS, Xamarin Android samt nativeutvecklade delar. I studien syftar prestanda på skillnad i responstid och upplevd fördröjning mellan native och crossplatformsutvecklade gränssnitt. Listor är svåra att mäta via videokamera eftersom skrollhastigheten behöver vara konstant och eventuella hackningar ger inget tillfredsställande mått. Därför genomfördes även experiment där empirin kom från testpersoners uppfattningar relativt till nativeutvecklade delar. Mer om metoden som använts beskrivs ytterligare genom kapitlet.2.2
Arbetsprocessen
2.2.1 Experimentell metod Först observeras och definieras forskningsproblemet och syftet med studien där syftet sedan bryts ned till frågeställningar som skall besvaras. Utifrån detta skapas en hypotes och en förutsägelse som senare skall bevisas eller falsifieras. Inom detta steg krävs ofta litteraturstudier för att få en bättre bild av forskningsområdet och få en uppfattning av den teori som studien behöver. [9] Ett experiment konstrueras baserat på den framtagna hypotesen och förutsägelsen. Det är viktigt att dokumentera hur experimentet genomförs och vilka variabler som skall kontrolleras eller hållas konstanta så att andra forskare kan replikera experimentet och kunna komma fram till samma slutsats. [9]Experimentet genomförs sedan enligt den plan som dokumenterats i föregående steg. De variabler man utsett för experimentet mäts och utgör sedan den data som används i studien. Datan inkluderar även en kontroll som i denna studie innebär nativeutvecklade delar. Denna används som referens när jämförelsen sedan skapas i analysdelen. Experimenten körs flera gånger för att försäkra sig om att resultatet inte är en slump. [9] Slutligen analyseras den insamlade datan så att den kan tolkas och resultera i en slutsats som besvarar hypotesen och därmed studiens syfte. Detta dokumenteras för att forskningen ska bidra till den aktuella kunskapsbasen. [9] 2.2.4 Utvecklingsmiljöer För utveckling av Xamarin (Forms och Android) delarna av experimenten har Visual Studio Community 2015 använts som utvecklingsmiljö. Experimenten utfördes med Xamarin version 4.0.0.1717. Vid utveckling av Xamarin iOS och native iOS användes en macdator med Xcode version 7.1.1. För utvecklingen av native Android användes IntelliJ IDEA Community Edition 14.1.5. För iOS var målplattformen version 8.1 och för Android var lägsta version satt till API level 15 (Android 4.0.34.0.4) men byggs med API level 22 (Android 5.1). 2.2.5 Enheter
Nedan i Tabell 1 listas de enheter som experimenten utförts på. Enheterna har olika hårdvara vilket kommer påverka tiden som mäts i experimenten. Genom att utföra experimenten på flera enheter kommer resultatet ge en bättre bild om de eventuella skillnaderna i prestandan skiljer sig beroende på enheten. Därmed kan beslutsfattare bedöma när och om prestandaskillnaderna blir försumbara. Enheterna valdes inte av någon specifik anledning utan efter vad som fanns tillgängligt. Tabell 1: De enheter som har använts under studien
Enhet Operativsystem Systemversion
Samsung Galaxy Tab 3 Android 4.4.2
Samsung Galaxy S II Android 4.1.2
iPad Air iOS 8.4 iPhone 4s iOS 9.1
2.3 Hypotes och förutsägelse
Eftersom Xamarin är ett verktyg som skapar appar av typen generated apps så finns det någon typ av mappning mellan programmeringsspråken C#, Java och Swift / ObjectiveC som gör att de kan generera koden för varje plattform. Vi tror inte att detta i sig ger någon betydande overhead som skulle kunna påverka prestandan märkbart. Vid användning av Xamarin Forms kan skapande av användargränssnittet göras gemensamt vilket gör att overhead skapas för att beräkna hur användargränsnittet ska byggas upp [10]. Därmed är hypotesen för den första frågeställningen: “Liknande gränssnitt har dubbelt så långa fördröjningar i crossplatformutvecklade appar av typen generated apps jämfört med nativeutvecklade appar” Vår förutsägelse är att ett användargränssnitt skapat med Xamarin Forms presterar sämre än ett liknande gränssnitt i nativeutvecklade appar. Vi tror att gränssnitt gjorda i Xamarin Android och Xamarin iOS kommer prestera lika bra eller försumbart sämre än nativeutvecklade.2.4 Implementering
För att besvara studiens frågeställning skapades tre olika vyer med varierad komplexitet som implementerades för alla olika plattformar. Nedan beskrivs vyerna och anledningen varför de valdes. Figurerna visar hur testvyerna ser ut på plattformen Android. Skillnaderna i hur testvyerna ser ut i iOS och de olika teknikerna är små och i denna studie är det strukturen som är viktigast.
Figur 1: Första testvyn i Android Figur 2: Andra testvyn i Android
Första testvyn som visas i Figur 1 använder sig av flera element som repeterar utan att använda sig av en lista (komponet). En scrollvy gör att sex rader kan skapas av enheten. Vyn visar flera olika komponenter där vissa inte syns på skärmen och beroende på hur effektivt plattformarna hanterar det så kan det gå åt olika mycket minne och därmed vara en faktor som påverkar hur snabbt vyn laddar.
Den andra vyn (Figur 2) består av en lista bestående av 15 custom cells (rad i listan som är byggd efter utvecklarens preferenser). I den här vyn består en cell utav två bilder och text. Dessa har sedan placerats ut i cellen med ovanstående bild som resultat.
Figur 3: Tredje testvyn i Android Figur 3 visar den tredje testvyn som skapades för att efterlikna komponenter som skulle kunna representera ett verkligt scenario. De tre olika vyerna har varierande komplexitet vilket gör att vi får en bra bild över hur plattformarna presterar. Företag kan sedan relatera sina egna produkter till hur komplexa de kommer att vara och sedan kunna jämföra med våra testvyer om hur de kan tänkas prestera. Vid genomförande av experiment så avslutades andra användarkontrollerade appar på enheten och flygplansläge slogs på (enheten stänger av wifi och radioförbindelser). Appen som vi utvecklade för experimentet startades från att den har varit avslutad eftersom appar i bakgrundsläge kan spara viss data sedan innan. Experimenten genomförs genom att tio gånger navigera sig till den aktuella testvyn. Dessa filmades med en iPad Air som filmade i 60fps. När vi filmade experimentet så byggdes appen som en releaseversion (optimerad version av appen) och installerades på enheterna.
Experiment kördes även för att dokumentera CPU och minnesanvändning vid laddning av de olika testvyerna på alla plattformar. Dessa kördes i debugläge och inkopplade till en dator för att kunna komma åt informationen. För att se CPU och minnesanvändring för Android enheterna användes inbyggda verktyg i IntelliJ IDEA där grafer ritades upp i realtid. För iOS användes verktyget Instruments som följer med Xcode. Instruments kan precis som i Android bevaka CPU och minnesanvändning i realtid dock är dessa grafer sämre vilket gjorde de svårare att läsa av. Graferna sparades för att användas som empiri. För iOS var dock graferna väldigt små så vi var tvugna att förstora dessa och skriva ned de viktigaste värdena som minsta och största CPUanvändning och minnesanvändrning före och efter testerna. Vi observerade att debuggning i IntelliJ IDEA gjorde att appen kändes söligare än vad Xamarin apparna gjorde. Detta gör att testdatan kan påverkas och därför anser vi att det blir svårt att jämföra mellan Android native och Xamarin utvecklade delar. I iOS byggdes Xamarin apparna i Xamarin Studio och native delarna byggdes i Xcode. När dessa kördes observerade vi att apparna inte påverkades märkbart av att köra i debuggläge, varken från Xamarin Studio eller Xcode. För användarexperimentet ställde vi upp ett bord i JTH:s (Jönköpings Tekniska Högskola) entré under en eftermiddag. Enheter placerades ut på bordet och en dator stod redo med enkäten. Det var dessvärre endast tio personer som deltog i experimentet. Detta ger en felmarginal på 31,6% [11]. Experimenten genomfördes genom att en deltagare fick information om att de skulle jämföra laddningstider och responsivitet av listor mellan ett antal testvyer på valfri enhet. Vi räknade med att det skulle vara relativt många deltagare vilket gjorde det onödigt att specificera vilken enhet de skulle använda. De fyllde sedan i enkäten på datorn samtidigt som de testade de olika vyerna. Det var endast andra testvyn som användaren testade men på alla olika plattforms och teknikvarianter. Enkäten för användarexperimenten var uppbyggd i två delar där första delen handlar om hur mobilvana användaren anser sig vara. Med en relativt hög mobilvana så kommer resultaten från användares respons vara mer relevant då de lättare kommer kunna jämföra eventuella skillnader mellan experimenten. Den andra delen behandlade experimenten, hur de uppfattade att laddningstiderna var för de olika experimenten samt vad de tyckte om listornas respons. Enkäten med alla frågor visas under bilaga 3.
2.5 Mätmetod
För att mäta hur snabbt en vy presenterades så filmades experimenten med en kamera som filmade i 60fps med undantag för iPad Air som filmades i 50fps. Det ger en god helhetsuppfattning från det att användaren trycker på t.ex. en knapp till det att vyn visas. När experimenten var filmade så gick vi igenom materialet för att bestämma hur många bildrutor som var mellan användarinteraktion till feedback från appen. Dessa bildrutor kan sedan enkelt göras om till millisekunder genom att använda formeln x/y*1000 där x är antalet räknade bildrutor och y är antalet bildrutor per sekund som kameran filmar i. Figur 5 visar hur vi valt att mätastartbildrutan. I Figur 6 ser vi hur vi bedömde slutbildrutan.
Figur 5: Exempel på startbildruta med föregående och nästa frame
Figur 6: Exempel på slutbildruta med föregående och nästa frame Vid bedömning av startframe så var det mindre skillnader på fingret som användes för att avgöra när tryckningen skedde. Dessa var lättare att identifiera vid bläddring av frames. Vi valde att räkna slutbildrutan från det att viss feedback visas för användaren, animationer är avstängda men det finnas ett underliggande beteénde som gör att den aktuella vyn och den nya vyn mixas fram. Det blir alltså en övergång som visas under två till tre bildrutor. Det största och minsta värdet från experimenten exkluderades i beräkningar för att minska risken för eventuella tillfälligheter. De markeras i tabeller som mörkgråa för högsta värdet och ljusgråa för det minsta värdet.
2.6
Datainsamling och dataanalys
Studiens datainsamling bestod dels av litteraturstudier för att bygga upp relevant teori kring forskningsområdet och dels av insamling av empirisk data från experimentens resultat. Data för frågeställningen insamlades genom att utföra experiment som resulterade i kvantitativ data. Experimenten bestod utav testvyer för varje plattform som testades och genererade resultat genom visuell tidsmätning i millisekunder. En videokamera används för att mäta tiden mellanden fysiska tryckningen på telefonen (en knapp i appen) och det att vyn presenteras utan animation. CPU och minnesanvändning för experimenten samlas in genom debugverktyg. Detta för att se hur plattformarna presterar jämfört med varandra. Datan dokumenterades därefter i tabeller. Även experiment med användare gjordes som resulterade i kvantitativ data. Dessa genomfördes tillsammans med en utvald population som bestod utav högskolestudenter på Tekniska Högskolan i Jönköping. Populationen valdes dels för dess tillgänglighet samt dess höga chans till mobilvana med smarta telefoner vilket innebär att de har bättre förståelse för hur listor brukar bete sig. Ur populationen valde vi sedan ut ett slumpmässigt urval genom att välja de som valde att delta när vi befann oss på skolområdet. Experimentet med användare genomfördes genom att användaren fick gå mellan testenheterna och testa de olika delarna. Användarens upplevelser dokumenterades genom en enkät som besvarades under experimentet. Resultaten från experimenten sammanställs i form av grafer och tabeller. Därefter jämförs dessa med varandra för att identifiera skillnaderna mellan crossplatform och nativeutvecklade delar.
2.7
Trovärdighet
För att se till att olika experiment kördes i testenheten med konstanta förutsättningar, stängdes andra användarkontrollerade appar på enheten och flygplansläge slogs på. Experimenten kördes flera gånger så att tillräckligt med data erhölls för att eliminera eventuella fel. Detta gör också att det blir lättare att identifiera mönster. Experimenten dokumenterades väl för att andra ska kunna replikera dessa och komma fram till liknande resultat. För att experimenten skulle ge relevant data så valde vi att mäta tid visuellt istället för att mäta det programmeringsmässigt. Det gör att alla okända beräkningar och metoder som används internt av ramverket för att presentera användargränssnittet kan representeras av en variabel som sedan mäts. Tiden tas från det att användaren trycker visuellt fram till det att användaren faktiskt ser något på skärmen. I och med att mätmetoden ser det användaren kommer att se blir metoden simpel. Utan animationer blir det även tydligt vart mätningen bör starta och stoppa. Hade mätmetoden varit programmeringsmässig så skulle den händelse som används för att mäta tiden kunna ske innan eller efter det att användaren fått visuell feedback av appen.Vissa experiment var svårare att mäta visuellt och därför genomfördes experimenten med hjälp av kvantitativ data från testpersoner så att upplevelsen kan uppskattas och presenteras som resultat.
3
Teoretiskt ramverk
3.1 Olika apptyper
Det finns flera olika typer av appar och det är viktigt att veta skillnaderna mellan dessa för att förstå det resonemang som förs i studien. Nedan beskrivs de olika typerna, deras kännetecken och svagheter. 3.1.1 Native apps Native apps är appar som var och en är utvecklade separat för de olika plattformarna. De är skapade med hjälp av de utvecklingsverktyg och språk som användas av respektive plattform till exempel Java för Android och Swift för iOS. Detta medför att de känns naturliga och välgjorda för användarna då de helt är anpassade till deras specifika system. En nackdel med dessa är utvecklingskostnaderna. De kräver separat utveckling vilket tvingar företagen att utveckla samma applikation till olika system för att täcka hela marknaden. [11] 3.1.2 Web apps Web apps är i grund och botten webbsidor som laddas ner till enheten. De sparas som en ikon och ser ut som en vanlig app men är egentligen bara en genväg till en mobilvänlig websida. De utvecklas med samma språk som vanliga websidor dvs HTML, CSS och JavaScript. Det negativa med dessa appar är behovet av konstant uppkoppling och limiterad tillgång till enhetens hårdvarufunktioner och enhetens sparade data. Det skall dock nämnas att detta håller på att förbättras med HTML5 och till skillnad från native apps behöver web apps inte installeras på enheten. De behöver heller inte uppdateras eftersom det sker automatiskt. [3]3.1.3 Hybrid apps Hybrid apps är en kombinatiuon av native och web apps. De är precis som web apps utvecklade med HTML5 och JavaScript. De stora skillnaderna mellan hybrid och web är att hybrid installeras på enheten [5]. Appen exekveras i en så kallad native container som möjliggör tillgång till funktionalitet som inte är tillgängligt med enbart en web applikation som till exempel sparad data och kamera. Den här typen av app är populär då den gör det möjligt att skapa appar med samma språk som används till webbsidor. De erbjuder även en bra crossplattformlösning då de kan implementeras på flera olika plattformar [12]. 3.1.4 Generated apps Generated apps skapas genom att de utvecklas i ett verktyg som sedan gör om koden till native kod (Java och Swift) och körs som vanliga native apps på enheterna. Det är då möjligt att använda samma lösning på alla de plattfomar verktyget stödjer. Det är även troligt att appar av typen generated apps presterar bättre än web apps och hybrid apps då koden görs om till native kod [3]. Det finns dock problem som till exempel att skapa en gemensam design då plattformar oftast har olika sätt att presentera data för användaren.
3.2 Xamarin
Xamarin Inc är ett Amerikanskt företag som utvecklar verktyg vars syfte är att förenkla utvecklingen av mobila applikationer. Företaget grundades 2011 och har sitt huvudsäte i San Fransisco Califonien men har kontor i andra länder också, bland annat Argentina, England och Danmark [13][14]. Deras nuvarande produkt heter precis som företaget Xamarin och är en samling verktyg vars syfte är att förenkla crossplatformutveckling till de tre största mobila plattformarna (Android, iOS och Windows Phone) [15]. Dessa applikationer skrivs i språket C# och designen skapas antingen med hjälp av XAML eller programmeringsmässigt. Xamarin hör till apptypen generated apps som beskrivs ovan [2]. Dess egna utvecklingsmiljö heter Xamarin Studio. Det finns dock som tillägg till Visual Studio för de som känner sig mer bekväma med det. Med hjälp av verktyget kan utvecklare skapa mobila applikationer, både till en enskild plattform eller flera. Vid crossplatformutveckling skapas en “Solution” som innehåller ett gemensamt projekt tillsammans med ett projekt för vardera plattform. Det är alltså möjligt till skillnader mellan de tre plattformarna. Det finns möjlighet till att dela logik i ett portabelt bibliotek eller dela både logik och användargränssnitt via Xamarin Forms. Det senare alternativet använder en annan metod för att skapaanvändargränssnittet. XAML eller programmeringsmässig användargränssnittskod genererar plattformsspecifik kod av Xamarin. Det går också att använda ett inbyggt designverktyg som gör det möjligt att skapa designen för Android, iOS och Windows Phone enskilt på ett sätt som liknar deras egna designverktyg. Utöver detta så går det att kombinera Xamarin Forms och specifik kod för varje plattform genom så kallade custom renderers för att skapa ett anpassat utseénde för någon specifik del av användargränssnittet. Detta gör att det oftast går att skapa en design för alla plattformar och sedan göra små plattformsspecifika modifieringar om det behövs. Det finns även funktionalitet för så kallade DependencyService som kallar på plattformsspecifika delar för att kunna implementera sådant som svårt att göra i Xamarin Forms. De erbjuder även en molntjänst (Xamarin test clouds) man kan använda för att testa applikationen på en mängd olika virtuella enheter [16].
4
Empiri
För att besvara studiens frågeställning, “Hur stora fördröjningar inom presentation av användargränsnitt finns det mellan nativeutvecklade appar och crossplatformutvecklade appar av typen generated apps?” så genomfördes experiment av laddningstider. Genom att studera vyers CPU och minnesanvändning vid exekvering av de olika teknikerna och plattformarna skapas en bättre förståelse om hur Xamarin skiljer sig från nativeutvecklade delar. Experimenten med användaren kommer även besvara hur responsiva och snabba listor är jämfört med de olika plattformarna.
4.1
Experiment av laddningstider
Filmningen av experimenten vid öppnandet av vyerna för de olika teknikerna resulterade i flera olika videofiler. Dessa gav ett mått på hur lång tid det tog att för enheten att presentera de olika testvyerna. Datan presenteras i Tabell 3. För att lättare avgöra vilket experiment som hör till vilken plattform och vy kan Tabell 2 användas.Tabell 2: Beskrivning av benämningar för experiment Experiment A1 Xamarin Forms i Android. Första testvyn. Experiment A2 Xamarin Forms i Android. Andra testvyn. Experiment A3 Xamarin Forms i Android. Tredje testvyn. Experiment B1 Xamarin Forms med XAML i Android. Första testvyn. Experiment B2 Xamarin Forms med XAML i Android. Andra testvyn. Experiment B3 Xamarin Forms med XAML i Android. Tredje testvyn. Experiment C1 Xamarin Android. Första testvyn. Experiment C2 Xamarin Android. Andra testvyn. Experiment C3 Xamarin Android. Tredje testvyn. Experiment D1 Native Android. Första testvyn.
Experiment D2 Native Android. Andra testvyn. Experiment D3 Native Android. Tredje testvyn. Experiment E1 Xamarin Forms i iOS. Första testvyn. Experiment E2 Xamarin Forms i iOS. Andra testvyn. Experiment E3 Xamarin Forms i iOS. Tredje testvyn. Experiment F1 Xamarin Forms med XAML i iOS. Första testvyn. Experiment F2 Xamarin Forms med XAML i iOS. Andra testvyn. Experiment F3 Xamarin Forms med XAML i iOS. Tredje testvyn. Experiment G1 Xamarin iOS. Första testvyn. Experiment G2 Xamarin iOS. Andra testvyn. Experiment G3 Xamarin iOS. Tredje testvyn. Experiment H1 Native iOS. Första testvyn. Experiment H2 Native iOS. Andra testvyn. Experiment H3 Native iOS. Tredje testvyn. Tabell 3: Mätdata för experiment med Samsung Galaxy S2 Samsung Galaxy S2 Värden i frames filmat med 60fps, 16,7ms i granularitet Försö k 1 2 3 4 5 6 7 8 9 10 Medelvärde Medelvärde i ms Experimen t A1 39 36 37 43 32 30 37 32 43 32 36,0 600,0 A2 35 24 25 26 31 23 24 29 27 25 26,4 439,6 A3 53 26 25 26 26 24 34 24 23 23 26,0 433,3 B1 79 38 43 42 47 38 38 48 40 34 41,8 695,8 B2 30 44 32 28 31 37 31 27 25 34 31,3 520,8 B3 40 25 27 28 27 35 26 26 28 25 27,8 462,5
C1 22 21 23 24 26 26 24 24 24 30 24,1 402,1 C2 21 18 22 22 21 29 28 20 24 21 22,4 372,9 C3 20 19 20 16 18 18 27 19 17 19 19,6 327,1 D1 22 27 21 18 17 20 17 26 17 21 20,3 337,5 D2 16 17 16 16 22 17 16 17 16 16 16,4 272,9 D3 17 21 16 16 24 16 15 15 17 16 16,8 279,2 De mörkgråa markeringarna är de högsta värdena i det aktuella experimentet och de ljusgrå markeringarna är de minsta. Detta gäller även tabellerna 36 som visar data för de andra enheterna som användes. Dessa finns presenterade under bilaga 1. Som syns i bilagan så tvingades vi filma iPad Air med en kamera som klarade av 50fps vilket betyder att datan för iPad Air får en granularitet på 20ms istället för 16,7ms som resterande mätvärden. Nedan visas två stapeldiagram över mätdatan för Samsung Galaxy S2 och iPhone 4s. För de andra enheterna se bilaga 2. Figur 7: Stapeldiagram över mätdata från experiment med Samsung Galaxy S2
Figur 8: Stapeldiagram över mätdata från experiment med iPhone 4s
4.2
CPU och minnesanvändning
Mätningen av CPU och minnesanvändning resulterade i ett diagram för varje experiment som gjordes för alla enheter. I iOS dokumenterades högsta CPU och minnesanvändning tillsammans med diagrammen. Vi noterade även värdena före och efter utfört experiment. Detta gjordes för att diagrammen som iOS presenterade hade en lägre detaljnivå. Diagrammen som Android visade under experimenten var mer detaljerade och uppdaterades i realtid. Därför skrevs inte värden ut utan det kan läsas av i diagrammen. Nedan visas diagrammen för experiment A2, D2, E2 och H2 där de första två är från Samsung Galaxy S2 och de resterande från iPhone 4s. Vi valde att inte inkludera diagram för resterande experiment då det är totalt 96 bilder där dessa inte bidrar mycket för läsaren.Figur 12: CPU användning för experiment A2 med Samsung Galaxy S2 Figur 13: Minnesanvändning för experiment A2 med Samsung Galaxy S2
Figur 14: CPU användning för experiment D2 med Samsung Galaxy S2 Figur 15: Minnesanvändning för experiment D2 med Samsung Galaxy S2 Figur 16: CPU och minnesanvändning för experiment E2 med iPhone 4s
Figur 17: CPU och minnesanvändning för experiment H2 med iPhone 4s
4.3
Experiment med användare
Användarna observerade laddningstiderna för de olika experimenten som behandlade listorna det vill säga andra testvyn och sedan fick de även avgöra responsen hos listorna på en skala från ett till fem. På grund av det låga deltagandet på 10 personer får vi en felmarginal på 31,6% [11]. Deltagarna bestod av 40% kvinnor och 60% män. Utav deltagarna använde alla en smartphone och andelen Android och iOS användare var lika fördelat. Erfarenhet av smartphone varierade från tre år upp till mer än sju år. I medel ansåg deltagarna sig vara vana mobilanvändare med ett medelsvar på 4,2 på en skala från ett till fem där ett är mycket ovan och fem är mycket van. Under experimentet använde 80% enheten Samsung Galaxy S2 medans 20% anväde HTC Incredible S för Android delen av experimentet. För iOS delarna valde alla att använda iPhone 4s. Nedan i Figur 18 viasas ett diagram över medelvärdet om vad användarna ansåg omladdningstiderna. I Figur 19 viasas medelvärdet om vad de ansåg om listornas respons.
Figur 18: Medelbetyg för laddningstid (L) av experimenten med Android till vänster och iOS till höger Figur 19: Medelbetyg för respons (R) av lista i experimenten med Android till vänster och iOS till höger
5
Analys
5.1
Experiment av laddningstider
För att besvara studiens frågeställning genomfördes experiment som undersökte laddningstider av vyer för olika varianter av Xamarin och nativeutvecklade delar. Innan experimenten genomfördes formulerades hypotesen “Liknande gränssnitt har dubbelt så långa fördröjningar i crossplatformutvecklade appar av typen generated apps jämfört med nativeutvecklade appar”. Vår förutsägelse är att ett användargränssnitt skapat med Xamarin Forms presterar sämre än ett liknande gränssnitt i nativeutvecklade appar. Vi trodde också att gränssnitt gjorda i Xamarin Android och Xamarin iOS presterar lika bra eller försumbart sämre än nativeutvecklade. Nedan presenteras två tabeller som visar de beräknade skillnaderna i laddningstid mellan Xamarin och nativeutvecklade experiment. Tabell 8: Procent söligare experimentvariationer mot native (Samsung Galaxy S2) Samsung Galaxy S2 Procent söligare än nativevariant A1 77,8% B1 106,2% C1 19,1% A2 61,1% B2 90,8% C2 36,6% A3 55,2% B3 65,7% C3 17,2%Från Tabell 8 för Samsung Galaxy S2 framgår att det finns både stora och relativt små skillnader beroende på experiment och vy. Experimentvyer gjorda med Xamarin Forms och Xamarin Forms med Xaml presterar som lägst 61% och upp till 106% långsammare i förhållande till native. Xamarin Android pFresterar som högst 37% sämre än native. Tabell 9: Procent söligare experimentvariationer mot native (HTC Incredible S) HTC Incredible S Procent söligare än nativevariant A1 103,6% B1 144,6% C1 41% A2 78,6% B2 151,9% C2 32,1% A3 68,9% B3 106,7% C3 23% Tabell 10: Procent söligare experimentvariationer mot native (Samsung Tab) Samsung Tab Procent söligare än nativevariant A1 28,1% B1 49% C1 31,3% A2 38,4% B2 75,1% C2 35,7%
A3 23,5% B3 31,5% C3 26,5% Tabell 11: Procent söligare experimentvariationer mot native (iPhone 4s) iPhone 4s Procent söligare än nativevariant E1 82,7% F1 139,8% G1 −3% E2 18,4% F2 156,1% G2 −4,4% E3 0,8% F3 33,9% G3 −4,1% Tabell 12: Procent söligare experimentvariationer mot native (iPad Air) iPad Air Procent söligare än nativevariant E1 74,1% F1 113% G1 −1,9%
E2 53,6% F2 155,4% G2 7,1% E3 28,8% F3 30,8% G3 3,8% Genom våra mätningar och resultat har det framgått att vår förutsägelses första del stämmer då den syftar till att Xamarin Forms är söligare. Den andra delen om att det inte finns någon betydande skillnad för Xamarin Android/iOS jämfört mot native stämmer dock inte. I iOS stämmer det att prestandan inte skiljer sig särskilt men i Android finner vi en regelbunden skillnad. Detta syns i tabellerna ovan. Tabell 11 presenterar hur mycket söligare de olika vyerna är i iPhone 4s jämfört med native iOS. Datan visar på både större och mindre skillnader jämfört med Samsung Galaxy S2. Xamarin Forms med XAML är söligare och kan ta upp till 156% längre tid att ladda gentemot relaterad nativedel. Vid mindre komplexa vyer som exempelvis tredje testvyn och en vanlig lista (som andra testvyn) är det relativt liten prestandaförlust vid använding av Xamarin Forms. Första testvyn verkar inte vara lika effektiv jämfört med de andra vyerna vid användning av Xamarin Forms och resulterar i 83% längre laddningstid. Xamarin iOS visar sig enligt datan i tabellen vara lite snabbare och befinner sig förmodligen inom felmarginalen. Det finns ett mönster för de olika operativsystemen. Mönstret tyder på att Xamarin Forms med XAML presterar sämst i förhållande till native. Därefter följer Xamarin Forms. Xamarin Android och Xamarin iOS har oftast ringa skillnader från native men Xamarin Android har vissa undantag där skillnaderna för laddningstiden kan vara upp till 41% sämre än native. Figur 18,
Figur 20 och Figur 21 kan användas för att lättare se mönstret.
Figur 20: Medelvärde i ms mot experiment jämfört med alla Androidenheter
Figur 21: Medelvärde i ms mot experiment jämfört med alla iOSenheter Tabell 13: Laddningsintervall i procent jämfört med nativedelar i Android Android Xamarin variant Intervall Xamarin Forms 24% 104% Xamarin Forms XAML 32% 152% Xamarin Android 17% 41%
Tabell 14: Laddningsintervall i procent jämfört mot nativedelar i iOS iOS Xamarin variant Intervall Xamarin Forms 1% 83% Xamarin Forms XAML 31% 156% Xamarin iOS 4% 7%
Från Tabell 13 och Tabell 14 ser vi att mellan Android och iOS så skiljer dessa sig åt i det att Xamarin Android/iOS inte har någon betydande långsamhet mot native när det kommer till iOS som däremot upptäcks i Android. Xamarin Forms är mer konsekvent inom sitt intervall i Android medans iOS varierar en hel del. Det är främst första testvyn som höjer intervallet. Från dessa resultat kan vi konstatera att experimentets hypotes har motbevisats. I flera scenarion är crossplatformvarianten minst 100% söligare än native. Dock finns det även flera olika situationer då skillnaden inte är lika stor och därmed hamnar under 100%.
5.2
CPU och minnesanvändning
Vid analys av mätresultaten från Android enheterna påträffades ett återkommande mönster.Figur 22 och Figur 23 nedan visar en överblick över den insamlade datan för Android med Samsung Galaxy S2.
Figur 23: Överblick över minnesanvändning för testvy ett med Samsung Galaxy S2. Datan visade på att Xamarin Forms och Xamarin Forms med XAML inte hade någon betydande skillnad mellan sig gällande CPU och minnesanvändning. Det gick dock att se en liten skillnad vilket gjorde att Xamarin Forms med XAML tog lite mer av resurserna. Xamarin Android använde ungefär hälfen av den CPUanvändningen Xamarin Forms använde sig av. Minnesallokeringen skiljde sig enormt där Xamarin Android använder knappt något minne om man jämför mot Xamarin Forms som hade tydliga minnesallokeringar. Mellan Android native och Xamarin Android fanns det inga större skillnader minnesmässigt. Dock använde sig Android native sig av omkring dubbelt så mycket CPUresurser. Figur 24: Överblick över CPU och minnesanvändning för testvy ett med iPhone 4s. Mätresultaten från iOS visar att det inte finns någon betydande skillnad mellan Xamarin Forms och Xamarin Forms med XAML när det kommer till minnesallokering. En knapp skillnad i CPUanvändning finns, vilket visar på att XAML varianten använde ungefär lika mycket CPUkraft men lite längre period vid utförande av experimenten. Mellan Xamarin Forms och Xamarin iOS är det svårt att se skillnad i CPU och minnesanvändning. Första testvyn visar dock att Xamarin Forms använder sig av CPU:n under längre perioder. Xamarin iOS och native iOS hade inga större skillnader mellan sig i varken CPU eller minnesanvändning. Figur 24 visar en överblick över dessa skillnader för testvy ett på iPhone 4s.
Resultaten från resursmätningarna visar på att Xamarin i vissa fall inte är lika effektivt på att använda telefonens resurser, vilket kan vara en anledning till att våra tidigare experimentresultat visat på att Xamarin generellt är långsammare än nativeutvecklade delar.
5.3
Experiment med användare
Oberoende av antalet deltagare på tio personer, visar ändå använderexperimentet ett mönster för hur användarna uppfattade laddningstiderna och responsen av andra testvyn för de olika
teknikerna. I och med den stora felmarginalen på 31,6% väljer vi att inte ta upp hur stora skillnaderna är från användarperspektivet men det går att se i diagrammen (Figur 18 och Figur 19) [11]. Laddningstider och respons visar på liknande mönster men mellan dessa så kan skillnaden vara olika stor. Rangordningen för Android är följande: Xamarin Forms med XAML, Xamarin Forms, Xamarin Android och native Android där Xamarin Forms med XAML fick lägst i medelbetyg. För iOS är rangordningen följande: Xamarin Forms med XAML, Xamarin Forms och till sist Xamarin iOS och iOS native som båda hade samma resultat där Xamarin Forms med XAML fick lägst i medelbetyg. Detta stärker och bekräftar mönstret som resultaten för experimentet med laddningstider gav. Vi valde att utföra experiment med användare för att få en uppfattning om hur de olika plattformarna hanterade listorna. Hur listornas respons var jämfört med vad vi har mätt om de olika teknikerna och plattformarna. Resultatet från användarnas uppfattningar bekräftar att de rangordnade responsen lika som det av laddningstiderna.
6
Diskussion och slutsatser
6.1
Resultat
Studien genomfördes för att undersöka crossplatformutvecklade appars prestanda vid presentation av användargränssnitt jämfört med natvie. För att identifiera skillnader skapades tre olika testvyer med olika komplexitet. Dessa vyer implementerades sedan på de olika platformarna och experimenten utfördes, dokumenterades och analyserades för att besvara nedanstående frågeställning. Hur stora fördröjningar inom presentation av användargränsnitt finns det mellan nativeutvecklade appar och crossplatformutvecklade appar av typen generated apps? Experiment utfördes där laddningstiderna för tre olika testvyer undersöktes. Resultaten från dessa experiment motbevisade den hypotes som skapats. Mätningarna visade att crossplatformsapplikationer i vissa scenarion hade mer än 100% längre laddningstid jämfört med en nativevariant. Men i de flesta fall låg skillnaden på lägre än 100%. För Android och de testenheter som vi använde så varierade Xamarin Forms mellan 24% till 104% långsammare än native. Xamarin Forms med XAML var mellan 32% till 152% långsammare. Xamarin Android låg mellan 17% till 41%. Skillnaderna blir olika stora beroende på hårdvaran. I dessa intervall ingår alla tre testvyer som användes för experimenten. För iOS varierade Xamarin Forms mellan 1% till 83% medans Xamarin Forms med XAML låg mellan 31% till 156%. Xamarin iOS hade ett intervall mellan 4% till 7%. Mätdatan från experimenten visar hur stora fördröjningar inom presentation av olika komplexa användargränssnitt som finns mellan nativeutvecklade appar och Xamarin utvecklade appar. Vi anser därför att studiens frågeställning är besvarad. Ett annat experiment utförde CPU och minnesmätningar medans enheten körde testvyerna. Detta gjordes för att få en bättre bild av hur Xamarin använder enhetens resurser jämfört med native. Experimentet resulterade i mätdata som tyder på att Xamarin Forms inte är lika effektivt på att hantera telefonens resurser. Detta kan vara en faktor till att mätresultaten från experimentet med laddningstider visat på att Xamarin generellt är långsammare än nativeutvecklade delar. Native Android visade ibland lika höga värden som Xamarin Forms vid mätning av CPUanvändning. Vi vet dock inte om detta beror på att native använder mer resurser eller om de olika debuggningsmiljöerna har en påverkan i och med att vi observerade en skillnad i respons som inte var där i release byggd app. Vi anser att den andra förklaringen är den mest troliga.Andra testvyn var svårare att mäta då listors prestanda inte bara handlar om laddningstid utan även hur listorna upplevs av användaren. Därför genomfördes experiment med användare där de fick testa de olika listvyerna samt svara på en enkät om hur de upplevde laddningstid och respons. Trots lågt deltagarantal på tio personer visades ett tydligt mönster som sammanfaller med tidigare experiment om laddningstider. Även upplevd respons faller in i samma mönster. Detta bidrar till att utöka svaret på frågeställningen genom att inkludera information om hur användare upplever listors respons.
6.2
Implikationer
Studien bidrar till att företag har ett mått på hur den resulterande produkten kommer att prestera tidsmässigt beroende på vilken teknik de väljer att använda. Studien visar att ramverket Xamarin presterar sämre vid presentation av användargränssnitt, men att Xamarin Android/iOS inte har lika stor prestationsförlust. Bättre hårdvara innebär dock mindre prestandaförlust. Om en enhet laddar in en nativevy på 140ms och en vy gjord i Xamarin Forms laddas in på 240ms så kanske det är relativt stor procentskillnad men den upplevda skillnaden kan vara försumbar. Företag bör därför fundera över om deras målgrupp använder ny eller gammal hårdvara. Resultat från studien kan användas som beslutsstöd vid val av teknik. Studien bidrar även med data som kan användas vid vidare forskning inom området.6.3
Begränsningar
Om vi hade haft fler enheter att utföra experimenten med så hade hårdvaran kunnat mappats mot prestandadifferans lättare. Detta hade i bästa fall givit bättre inblick i hur hårdvaran påverkar skillnaderna. Det skulle också vara bra att utveckla en app som inte bara består av testvyer för att användare lättare skulle kunna identifiera prestandaskillnader för flera olika vyer med varierade komplexiteter. Vi har också begränsat studien till att inkludera plattformarna iOS och Android men det hade varit trevligt att även inkludera Windows Phone. Dock har iOS och Android en marknadsdel på 96,7% vilket gör att studien inkluderar majoriteten av marknaden [6]. En annan begränsning var att deltagarantalet var lågt i experimentet med användare. Hade antalet deltagare varit högre så hade man med mindre felmarginal kunna komma fram till ett resultat. Eftersom resultatet trots det låga antalet deltagare ändå visade ett tydligt mönster så skulle ett högre deltagande troligtvis behållit samma mönster fast med mindre felmarginal.Vid inspelning av experimenten användes en iPad till filmning som filmade i 60fps samt kamera som filmade i 50fps vid inspelning av iPaden. Det hade varit önskvärt att kunna mäta alla enheter med samma kamera och fps. Vid mätning från inspelning av experiment fanns det en inbyggd övergång både i Android och iOS där feedback till användaren sker under två till tre bildrutor. Den föregående vyn och den vyn användaren navigerar till blandas visuellt under övergången (se Figur 5). Genom att hålla oss till en konsekvent bedömning till vad som skulle räknas som slutbildruta och med en granularitet på 16,7ms för 60fps och 20ms för 50fps så anser vi att övergången inte bidrar med någon betydande felmarginal.
6.4
Slutsatser och rekommendationer
Prestandaskillnaderna mellan de olika teknikerna som studien omfattar varierar och passar därför till olika situationer. Xamarin Forms är betydligt långsammare än vad Xamarin Android/iOS presterar. I iOS finns det ingen skillnad i prestanda jämfört med native och Xamarin iOS, däremot i Android finns en mindre skillnad jämfört mot Xamarin Android. Denna är dock tillräckligt liten för att inte påverka eventuella rekommendationer och beslut. Vi rekommenderar företag att använda Xamarin iOS/Android för att kunna dela appens logik mellan plattformar. Om målgruppen använder sig av nyare hårdvara kan Xamarin Forms vara ett alternativ. Vid jämförelse mellan med eller utan XAML så är utan att föredra. Vi anser att det är lättare att utveckla utan XAML samtidigt som det blir en viss prestandavinst. Dessa rekommendationer är baserade på studiens resultat men det finns andra faktorer som påverkar beslutet om teknikval som exempelvis tid, kostnad och funktionsimplementering.6.5
Vidare forskning
Denna studie tog upp prestandaskillnader av presentation av användergränssnitt för en apptyp där vi använde oss av Xamarin. Framtida arbeten skulle kunna bygga vidare för att undersöka andra apptyper eller ramverk. Utöver prestanda finns flera olika faktorer som medverkar vid beslutsfattande av vilken teknik ett förtag väljer. Tid och kostnad som är en faktor skulle kunna studeras för att avgöra hur mycket tid och pengar som går att sparas för vissa ramverk eller crossplatformutveckling generellt. Det skulle också vara intressant att utveckla en mindre applikation för de olika teknikerna och genomföra ett större experiment där användare får använda sig utav apparna under en längre tid.Detta skulle kunna klargöra om hur användare upplever prestandaskillnader mellan de olika teknikernas användargränsnitt. En standardiserad metod eller process skulle kunna tas fram för att utföra experiment som undersöker prestanda för användargränssnitt. Ett flertal faktorer skulle potentiellt kunna medverka. Vi tog upp CPU och minnesanvändning och laddningstider i vår studie, men ytterliggare faktorer som animationer och användarpreferenser skulle kunna ingå. Det hade varit lättare om det funnits en allmän definition för hur prestanda av användergränssnitt avgörs och definieras.
