Cross-platform development : A performance comparison between React Native and Cordova

(1)

Linköpings universitetet | Institutionen för datavetenskap Kandidatuppsats, 16 hp | Innovativ Programmering VT 2020 | LIU-IDA/LITH-EX-G--20/048--SE

Cross-platform development: A

performance comparison

between React Native and

Cordova

Gustav Leffler

Handledare: Peter Dalenius Examinator: Jody Foo

Linköpings universitetet SE-581 83 Linköping 013-28 10 00, www.liu.se

(2)

Cross-platform development: A performance comparison

between React Native and Cordova

Gustav Leffler

Linköping University

gusle136@student.liu.se

SAMMANFATTNING

Denna rapport jämför prestandan hos applikationer utvecklade med två olika verktyg som används för att utveckla mobilapplikationer till flera plattformar samtidigt. Verktygen som jämförs är React Native och Apache Cordova. Verktygen fungerar på olika sätt, React Native renderar applikationen genom att använda plattformsspecifika- komponenter medans Cordova renderar med hjälp av HTML5 och CSS3. Jämförelsen går till genom att utveckla tre applikationer med de båda verktygen (totalt sex applikationer) och sedan jämföra prestandan hos dessa. Testapplikationerna är framtagna för att testa funktionalitet som förekommer ofta hos applikationer idag. Testapplikation 3 testar exempelvis ett oändligt scrollande flöde, som förekommer hos både Facebook och Instagram. Resultaten visar att Cordova i dessa tester har en CPU-användning på 76% lägre än React Native och även har en minnesanvändning som är 18% lägre.

INLEDNING

Användandet av smartphones och applikationer har under de senaste fem åren ökat avsevärt. År 2021

förväntas det vara 3,8 miljarder

smartphone-användare i världen [15]. Det finns två ledande plattformar, iOS och Android, som står för 29% respektive 70% av alla mobiler som används [14]. För att utveckla applikationer till Android används ofta Java och till iOS används Swift eller Objective-C. Detta är hur plattformsspecifika applikationer utvecklas, vilka även kallas native-applikationer. Vanligtvis vill applikationsutvecklare släppa sina applikationer till båda plattformarna vilket då kräver utveckling av två separata applikationer.

För att inte behöva utveckla två separata applikationer till de olika plattformarna finns det flera verktyg som tillåter att _{en applikation utvecklas som} sedan kan användas på flera plattformar. Ett populärt verktyg som används är React Native . React Native 1 1_{https://reactnative.dev}

är baserat på JavaScript-biblioteket React som2

används för att bygga användargränssnitt och är framtaget och underhålls av Facebook. React Native renderar applikationen genom att använda native-komponenter. Dessa komponenter är specifika för de olika plattformarna och ska ge ökad prestanda. Istället för att använda native-komponenter är det även möjligt att använda en webbaserad lösning och rendera komponenter med HTML och CSS. Ett populärt verktyg för detta är Cordova . Cordova3

bäddar in en webbapplikation i applikationen och ger den åtkomst till enhetens funktionalitet via ett API (Application Programming Interface).

Syfte

Den stora fördelen med Cordova är att om man ska utveckla en webbapplikation och en mobilapplikation kan dessa dela kodbas, vilket kan spara både tid och pengar. För att göra det enklare för utvecklare att ta ett beslut mellan React Native och Cordova ska denna artikel göra det tydligt hur mycket som skiljer verktygen åt prestandamässigt.

Frågeställning

Rapporten ska fastställa om det finns någon prestandaskillnad mellan React Native och Cordova i olika scenarion. Prestanda mäts med avseende på CPU- och minnesanvändning.

● Om det finns någon skillnad i prestanda hos verktygen, hur stor är skillnaden?

● Presterar något verktyg bättre i specifika scenarion?

Avgränsningar

Denna artikel utvärderar cross-platform-verktygen på Android-telefoner, iOS har utelämnats.

2_{https://reactjs.org}

(3)

TEORI

Detta kapitel förklarar de begrepp och tekniker som kommer att användas.

Cross-platform development

Cross-platform development tillåter utvecklare att skapa applikationer till flera plattformar samtidigt. Istället för att utveckla en applikation till en specifik plattform kan man istället utveckla en applikation som går att köra på flera plattformar, vilket sparar både tid och pengar. Enligt Shah et al. [12] är den största fördelen med cross-platform applikationer WORA-principen (_{Write Once, Run Anywhere}). Det finns fyra olika kategorier av cross-platform applikationer, de kan förklaras som följande [2, 12, 17]:

● Web - Detta är vanliga webbapplikationer som byggs med HTML, CSS och JavaScript. Användare kommer åt applikationen via deras webbläsare i telefonen. Fördelen är att alla enheter med en webbläsare kan komma åt webbapplikationen och att någon installation inte behövs. Nackdelen är kravet på att enheten är uppkopplad, eventuella nedladdningstider, och den begränsade tillgången till enhetens funktionalitet.

● Hybrid - Detta är en native-applikation som endast består av en WebView där en webbapplikation visas. Den inbäddade webbapplikationen utvecklas som vanligt med HTML, CSS och JavaScript men får via ett API tillgång till enhetsfunktioner. En fördel med hybrid-applikationer är att ett företags webbapplikation och mobilapplikation till stor del kan dela kodbas. Däremot brukar hybrid-applikationer generellt sett prestera sämre än native-applikationer.

● Interpreted - Denna typ renderar gränssnittet med native-komponenter men applikationskoden är inte skriven i native-språket. JavaScript kan exempelvis användas som då interpreteras under körning. Fördelen är att gränssnittet känns och presterar som en native-applikation, nackdelen är att utvecklaren blir helt beroende av att verktyget erbjuder den funktionaliteten man behöver och uppdateras regelbundet.

● Cross-Compiled - Denna typ är lik

interpreted med att man kan skriva

applikationen i ett annat språk än native-språket, exempelvis C#. Skillnaden är att när applikationen byggs översätts koden till native-kod. Fördelen är att applikationen blir en riktigt native-applikation och presterar som en sådan. Nackdelen är att komplexa applikationer kan prestera sämre än vanliga native-applikationer på grund av hur de blir kompilerade till native-kod. React Native passar in under kategorin _interpreted och är det populäraste verktyget inom sin kategori [12, 13]. Inom samma kategori hittar man även verktyget Appcelerator . Cordova ligger under4

kategorin _{hybrid och är inom sin kategori det} populäraste verktyget som används till mobilapplikationer [13]. Ionic är ett annat verktyg5 under samma kategori som är baserat på Cordova men vidareutvecklat.

WebView

En WebView tillåter en mobilapplikation att visa webbinnehåll. De använder samma motor som en webbläsare men har inte lika mycket funktionalitet, den saknar bland annat adressfält och navigeringsknappar.

Cordova

Apache Cordova (även känt som PhoneGap) är ett ramverk som används för att utveckla mobilapplikationer till flera plattformar, som bland annat Android och iOS, fast med en delad kodbas. Ramverket blev 2011 uppköpt av Adobe och senare släppt som Cordova vilket även är open-source. Cordova renderar applikationer med hjälp av en WebView [16]. Applikationen kan egentligen ses som en webbläsare som visar en vanlig webbsida byggd med HTML5, CSS3 och JavaScript. Skillnaden är att den även tillåter att denna hemsida kommunicerar med enheten via ett API för att komma åt enhetsfunktioner som bland annat filsystemet och kamera. En överblick på detta finns i figur 1. Cordova använder som standard en tråd för applikationen (plugins exekveras dock på en separat tråd). Detta gör att renderingen kan blockeras om tunga beräkningar utförs, vilket resulterar i att det inte går att integrera med gränssnittet.

4_{https://www.appcelerator.com/} 5_{https://ionicframework.com/}

(4)

Figur 1. Cordovas arkitektur. Återskapad enligt licens (Apache-2.0).

React Native

React Native är ett ramverk som tillåter utvecklare att bygga mobilapplikationer med hjälp av JavaScript till både Android och iOS. React Native bygger på React som används för att skapa användargränssnitt. React Native renderar användargränssnitt med

native-komponenter, vilket gör att applikationer ska prestera och kännas som native-applikationer. Ramverket används idag av många stora företag som bland annat Instagram, Skype och Pinterest [3]. Till skillnad från Cordova använder React Native som standard två trådar, en JavaScript-tråd där

applikationen bor och en separat tråd för rendering.

RELATERAT ARBETE

Det finns flera artiklar som utforskar olika verktyg för cross platform development [1, 5, 6, 7, 8]. Flertalet av dem jämför React Native mot andra ramverk. Det som däremot inte verkar finnas är någon artikel som jämför React Native mot Cordova, vilket denna artikel ska göra.

Hansson et al. [5] jämför en React Native-applikation med en native-applikation. De gör detta genom att utveckla samma applikation fast med de båda verktygen, vilket tillåter dem att upptäcka skillnader. Antalet FPS (frames per second) skiljde sig väldigt lite mellan de olika applikationerna och enligt Hansson et al. [5] skulle skillnaden inte vara märkbar för användare. De kommer fram till att React Native inte skiljer sig så mycket från native-applikationer när det kommer till CPU-användning, minnesanvändning eller FPS.

Bosnic et al. [1] jämför en native-applikation med en Cordova-applikation. De visar en tydlig skillnad mellan de olika applikationerna, CPU-användningen hos Cordova-applikationen är betydligt högre, i genomsnitt ligger den på 30% medans native-applikationen ligger på 11%. De visar även att Cordova-applikationen i genomsnitt använder mer minne. Den använder i genomsnitt 250 MB medans native-applikationen ligger på 110 MB. De nämner även att detta är förväntat eftersom Cordova-applikationen använder sig utav en WebView som på egen hand använder mycket minne. Malavolta et al. [9] genomför en stor granskning av populära applikationer på Google Play Store. Av de 11917 applikationer granskade var 445 (3,75%) hybrid-applikationer, de var vanligast inom kategorier som finans, transport och livsstil. De menar att detta är för dessa applikationer hanterar data och inte är beroende av enhetens funktioner. Några kategorier som var mindre vanliga var fotografi, musik och verktyg. Malavolta et al. [9] menar att detta beror på att denna typ av applikation kräver en närmare kontakt med enheten och dess funktioner, de kräver inga extra plugins som ofta är fallet för att uppnå denna funktionalitet på hybrid-applikationer.

METOD

Tre testapplikationer konstrueras som är designade för att anstränga telefonen på olika sätt. Varje testapplikation byggs med både React Native och Cordova, syftet är att de ska se identiska ut och ha samma funktionalitet. Alla applikationer körs sedan under en bestämd tid samtidigt som ett verktyg mäter

CPU- och minnesanvändning. React

Native-versionen och Cordova-versionen av testapplikationen kommer sedan jämföras utifrån de mätvärden som samlats in.

För att utveckla React Native-applikationerna används React Native version 0.62.2 som släpptes 18:e april 2020. För utvecklingen av Cordova-applikationerna används Cordova version 9.0.0 som släpptes 22 mars 2019.

TypeScript används för att utveckla alla applikationer för att snabbare identifiera fel [10] och snabba upp utvecklingen .

Utrustning

Telefonen som används för att utföra testerna på är en Samsung Galaxy S9 från 2018 som kör Android 9.0.

(5)

Den har 4 GB RAM-minne och en åttakärnig processor (4x2.7 GHz och 4x1.8 GHz). Telefonen är kopplad till en Apple Macbook Air 2018 som används för att läsa mätvärden men även för att utveckla och bygga testapplikationerna.

Prestandamätning

För att mäta prestanda används verktyget Android Profiler, vilket är ett verktyg som följer med Android Studio. När en mätning startas kan den övervaka och spela in CPU-användning och minnesanvändning.

Cordova med React

Cordova-applikationerna utvecklas med verktyget React som är vanligt förekommande hos webbapplikationer idag. Detta gör att strukturen hos applikationerna blir väldigt lika varandra, då React givetvis är likt React Native. Detta för att uppnå en så stor generell likhet hos applikationerna som möjligt, vilket ska göra så att resultaten endast påverkas av de olika verktygen och så lite som möjligt av utvecklarens skicklighet. React-versionen som används är 16.13.1 som släpptes 19:e mars 2020.

Shubham Patil [11] visar hur man skapar ett Cordova projekt som använder sig utav React.

För att ändra utseende på HTML-komponenter i Cordova-applikationerna används React-tillägget styled-components6 som tillåter en att bygga återanvändningsbara och stylade komponenter som förenklar utvecklingen. Styled-components förenklar även användningen av animationer.

Testapplikation 1

Testapplikation 1 består utav flertalet individuella räknare som räknar uppåt så snabbt de kan. Varje gång en räknare räknar uppåt byter den även till en slumpmässig färg för att varje räknare ska bli lite mer krävande. Alla räknare kommer få applikationen att behöva rendera om (måla gränssnittet) väldigt ofta. Syftet med detta är att testa hur verktygen hanterar applikationer som frekvent uppdaterar gränssnittet. Testapplikation 1 är inspirerad av Jagiello [6] som menar att användningen av flera likadana komponenter (räknare) ska ge verktygen en chans att optimera dessa vilket skulle kunna förbättra prestandan.

I figur 2 ser man källkod för en räknare. Källkod till 7

alla applikationer finns att hämta på GitHub.

6_{https://styled-components.com}

7_{https://github.com/gustavleffler/bachelor_thesis}

Figur 2. Källkod för en räknare i testapplikation 1 (Cordova).

Figur 3. Skärmdump på testapplikation 1 (Cordova) med 50 räknare. Testapplikation 2

Den andra testapplikationen ska testa skillnader på animationer mellan de olika verktygen. Eftersom animationer ofta används i applikationer idag är

(6)

syftet med denna testapplikation att se hur krävande animationer hanteras av de olika verktygen. Cordova använder webbteknologi för animationer medans React Native använder native-kod, det är därför möjligt att något verktyg presterar bättre.

Testapplikationen består av flera fyrkanter som ser ut att studsa fram och tillbaka på skärmen, se figur 5. För Cordova används CSS3-transitions och till React Native används det medföljande biblioteket Animated . När applikationen startas får varje fyrkant8

en slumpad position längs en kant. Efter en slumpmässig tid (0–1 sekund) anropas move-funktionen och fyrkanten börjar röra på sig. Väntetiden lades till för att undvika att alla fyrkanter träffar kanter och behöver räkna ut en ny position samtidigt.

I figur 4 ser man hur koden som får fyrkanterna att se ut att studsa fungerar i React Native. I själva verket studsar de inte alls utan flyttas bara till en ny slumpad position på motsatt sida som räknas ut av funktionen

getNewPos(). När fyrkanten har kommit fram körs

koden igen och den flyttas återigen till en slumpad plats. Funktionen är väldigt lik hos Cordova, skillnaden är att fyrkantens position uppdateras och animationen sker sedan automatiskt med hjälp av CSS-transitions.

Figur 4. Källkod för en fyrkants move-funktion i testapplikation 2 (React Native).

8_{https://reactnative.dev/docs/animated}

Figur 5. Skärmdump på testapplikation 2 (React Native) med 64 fyrkanter som rör sig och studsar

på kanterna. Testapplikation 3

Den sista testapplikationen ska testa hur de olika verktygen hanterar ett dataflöde. Applikationen består av en klientapplikation som hämtar och visar data från en server. Applikationen lägger till all hämtad data i en lista. Även fast listan kan växa och bli väldigt lång så visas bara ett fåtal element samtidigt på skärmen, se figur 6. Eftersom rendering hanteras på olika sätt av verktygen är det intressant att se hur de väljer att optimera denna situation.

Server

Servern är en Node.js server som är byggd med 9 Express . Vid en förfrågan genererar servern 1010

slumpade inlägg som skickas tillbaka till klienten i JSON-format. Inläggen genereras slumpvis från en Lorem ipsum-text. Varje inlägg består utav en titel som är 8 ord lång, en beskrivning som är 20 ord lång och en URL till en slumpmässig bild från Pixabay . 11

Pixabay erbjuder gratis bilder utan att attribution krävs.

9_{https://nodejs.org/} 10_{https://expressjs.com/} 11_{https://pixabay.com/}

(7)

Klient

Klientapplikationen är uppbyggd för att likna ett dataflöde hos vanliga applikationer, exempelvis en nyhetsapplikation. Vid uppstart hämtas 10 inlägg från servern och presenteras i ett flöde som går att scrolla. När användaren börjar närma sig botten av flödet hämtas 10 nya inlägg från servern, detta kallas för

infinite scroll och används i populära applikationer som Facebook och Instagram.

React Native-applikationen använder den medföljande komponenten _{FlatList för att rendera} dataflödet. Cordova applikationen använder det populära paketet _{react-infinite-scroll-component för} att rendera sitt dataflöde.

För att testa hur denna applikation fungerar samtidig som en användare scrollar igenom dataflödet används tredje parts applikationen Automatic Scroll som är inhämtad från Google Play Store och utvecklad av SM Infotech. Automatic Scroll scrollar igenom applikationen med en jämn hastighet.

Figur 6. Skärmdump på testapplikation 3 (React Native).

Mätning

För att börja mätningen avslutas alla applikationer som körs på telefonen. En ny version av applikationen som ska mätas byggs och installeras på telefonen. Applikationen öppnas upp och på datorn

startas mätningen i Android Profiler. Efter 60 sekunder avslutas mätningen och resultatet går att läsa i de grafer som visas. För att få bättre grafer och exempelvis räkna ut medelvärde exporteras mätningen till Excel.

RESULTAT

Resultaten som presenteras här är framtagna genom att köra testapplikationerna i 60 sekunder medan Android Profiler samlat in data.

Resultatet för testapplikation 1 som består av flertalet räknare presenteras i figur 7 och 8. Här visas skillnader i CPU-användning och minnesanvändning.

Figur 7. CPU-användning för testapplikation 1 under 60 sekunder.

Figur 8. Minnesanvändning för testapplikation 1 under 60 sekunder.

.

Resultatet för testapplikation 2 som animerar flera studsande fyrkanter presenteras i figur 9 och 10.

(8)

Resultatet för testapplikation 3 som består av ett oändligt scrollande dataflöde presenteras i figur 11 och 12.

Övergripande CPU-användning

I tabell 1 visas medelvärdet för CPU användning för React Native och Cordova för alla testapplikationer. Denna data är uträknad från resultaten som presenteras innan och visar att Cordova i genomsnitt använder 76% mindre CPU än React Native.

Tabell 1. Genomsnittlig CPU-användning i procent för alla testapplikationer.

React Native Cordova

Testapplikation 1 24,6 7,9

Testapplikation 3 30,2 6,9

Övergripande minnesanvändning

I tabell 2 visas medelvärdet för minnesanvändning för React Native och Cordova för alla testapplikationer. Denna data är uträknad från tidigare resultat och visar att Cordova i genomsnitt använder 18% mindre minne än React Native.

Tabell 2. Genomsnittlig minnesanvändning i MBb för alla testapplikationer.

React Native Cordova

Testapplikation 3 184,2 152,4

DISKUSSION

(9)

Resultat

Resultaten visar att Cordova generellt sett kräver

både mindre CPU-användning och

minnesanvändning än React Native. Detta var inte helt förväntat, eftersom React Native renderar med hjälp av native-komponenter istället för att använda en WebView som i teorin bör kräva mer resurser. Enligt _{Hansson et al. [4] skiljer sig inte CPU- och} minnesanvändningen hos en React Native-applikation speciellt mycket från en native-applikation. Bosnic et al. [1] kommer fram till att en Cordova-applikation kräver både mer CPU- och minnesanvändning än en native-applikation. Detta skulle få en att tro att en Cordova-applikation skulle kräva mer resurser än en React Native-applikation. Detta resultat visar dock raka motsatsen, vilket kan få en att ifrågasätta resultatet.

En teori som skulle förklara de oväntade resultaten är att den underliggande webbmotorn som Cordova använder sig av skulle ha förbättrats under de senaste åren för att kräva både mindre processorkraft och minne, medan React Native inte har förbättrats lika mycket. En annan teori är att debug-verktygen hos de olika verktygen drar olika mängd resurser. Om debug-verktygen i React Native är betydligt kraftfullare skulle det kunna förklara varför det ser ut som React Native-applikationer drar betydligt mer processorkraft och minne än Cordova.

I figur 9 och 10 som visar testapplikation 2 ser man att både processor- och minnesanvändningen är som högst i början av mätningen för att sedan sjunka. Den höga CPU-/minnesanvändningen beror troligtvis på att applikationen precis har startat och då kräver mer resurser vilket inte är några konstigheter. Detta visar sig även i testapplikation 1 och 3 men för testapplikation 1 stiger inte Cordova-applikationen i början, även fast alla andra Cordova-applikationerna stigit i början. Detta beror på ett problem med mätningen av Cordova-versionen av testapplikation 1, där Android Profiler frös i de första fem sekunderna av mätningen, vilket då antagligen resulterat i felaktiga siffror. Mätningen upprepades flera gånger och samma problem uppstod varje gång, vad problemet beror på och varför det endast gällde Cordova-versionen av testapplikation 1 är oklart. Siffrorna efter de fem första sekunderna anses däremot vara korrekta och pålitliga.

Både CPU-användningen och minnesanvändningen är generellt sett ganska lika för alla React

Native-applikationerna och även för alla Cordova-applikationerna. Detta skulle kunna betyda att det finns en grundläggande CPU- och minnesanvändning som alltid förekommer hos applikationerna. För att utveckla en väldigt enkel applikation skulle Cordova därför troligen vara att

föredra med avseende på CPU- och

minnesanvändningen.

Det var först tänkt att även mäta frames per second (FPS) för applikationerna. Detta visade sig vara betydligt svårare än förväntat. Eftersom detta saknas finns det en risk för att resultaten kan vara vilseledande. I dessa testapplikationer visar det sig att Cordova kräver mindre resurser än React Native, det som dock saknas är hur applikationerna beter sig. Om Cordova använder mindre resurser på grund av att ha ryckigare animationer är det troligtvis inget positivt. För att motverka detta har applikationerna som mätts granskats noga manuellt för att se att inga märkbara skillnader förekommer. Små skillnader som inte är synliga för det mänskliga ögat kan dock fortfarande förekomma men förutom det presterade applikationerna lika visuellt sett.

Metod

Applikationerna som utvecklades var enkla testapplikationer med begränsad funktionalitet. Eftersom applikationerna inte är speciellt krävande blir _{overhead från verktygen mycket mer betydlig.} Men genom att utveckla olika små testapplikationer med varierande funktionalitet blev det möjligt att identifiera om ett verktyg presterar bättre för applikationer med en viss typ av funktionalitet. Vi såg bland annat att React Native och Cordova använde ungefär lika mycket minne vid animationer men att Cordova använde mindre minne vid ett oändligt scrollande flöde. Detta hade varit betydligt svårare att identifiera vid större applikationer. För att se hur verktygen hanterar tyngre applikationer skulle mer avancerade testapplikationer behöva utvecklas. Det skulle då vara möjligt att testa hur effektiva verktygen är på att hantera komplexa applikationer vilket skulle kunna ha större värde för företag som vill utveckla stora och krävande applikationer. För att ligga inom arbetets tidsram valdes det istället att fokusera på specifika delar som förekommer i applikationer och testade dessa separat och se om något verktyg presterade bättre i vissa specifika fall.

För att kunna mäta CPU-användning och minnesanvändning för applikationer med Android

(10)

Profiler krävs det att applikationerna byggs i development mode. Detta gör dock att det följer med flera utvecklingsverktyg som kan kräva extra resurser. Hur mycket mer resurser som krävs kan skilja sig mellan verktygen vilket kan göra att siffrorna som är framtagna här kan skilja sig ifrån hur applikationerna presterar när de har släppts för produktion. Det finns alltså ett utrymme för fel. Som tidigare nämnts skulle detta arbete även mäta applikationernas FPS. I början av arbetet var det tänkt att använda verktyget GameBench12 för att mäta CPU-/minnesanvändning och FPS. Men detta verktyg visade sig var betydligt svårare att införskaffa än förväntat. Istället för GameBench utforskades det populära verktyget systrace [4] som ska mäta bland annat CPU-/minnesanvändning och renderingstid för bildrutor. Med systrace-verktyget skulle även mätdata kunna samlas in för applikationer byggda för produktion, vilket gör att inga debug-verktyg följer med och försämrar resultaten. Systrace skapade en trace-fil som var svår att utvinna mätvärden ur, speciellt för CPU-användning. Efter många problem användes till sist Android Profiler som fungerar bra för att mäta både CPU- och minnesanvändning, nackdelen är dock att endast debug-versioner av applikationerna kan mätas, vilket kan försämra resultaten och därmed försämra rapportens validitet. Som nämnt ovan gjordes ett försök att använda systrace. Hansson et al. [4] använde systrace för att mäta FPS i en React Native-applikation, det gjordes ett försök att på samma sätt mäta FPS för de utvecklade testapplikationerna. Det problem som uppstod var att FPS som togs fram från systrace omöjligen kunnat vara korrekt, man kunde tydligt se att en applikation hackade men systrace rapporterade ändå att applikationen kördes i 60 FPS. Inga andra metoder för att mäta FPS fungerade och därför togs beslutet att det skulle uteslutas ur rapporten.

Utvecklaren av testappliklationerna hade mycket tidigare erfarenhet av både React Native och Cordova. Detta försäkrar om att de utvecklade applikationerna håller hög kvalité. Hade tidigare erfarenhet av det ena verktyget saknats hade det andra verktyget kunnat få ett orättvist övertag. Applikationerna är även enklaför att programmeringskunskaper ska påverka resultatet så lite som möjligt.

12_{https://www.gamebench.net/}

I testapplikation 2 testas animationer vilket är av intresse att testa då det förekommer ofta i applikationer idag. Däremot sker väldigt många animationer samtidigt, att animera så många objekt samtidigt förekommer inte i så många applikationer. En ensam animation kräver ganska lite resurser och en mätning på detta hade varit svår att jämföra eftersom siffrorna är så små. För att få ett jämförbart resultat sker därför betydlig fler animationer samtidigt som då mycket tydligare visar skillnaderna mellan verktygen.

Metoden är utformad med replikerbarhet och reliabilitet i åtanke. Källkoden till alla testapplikationer släpps för att underlätta en replikation av studien. För att försäkra att resultaten är konsekventa har flera mätningar utförts för varje applikation vilket har kontrollerat att de resultat som presenteras är representativa för de applikationer som har utvecklats med verktygen.

Källkritik

Det finns flera olika källor i detta arbete. Några av dessa kommer från organisationer som IEEE vilket visar på trovärdiga artiklar. Det används även många webbreferenser vilket inte alltid är lika pålitliga. De flesta sådana referenser i denna rapport kommer från stora företag som Google och Microsoft vilket ger en ökad trovärdighet. Källor som tidigare master-/kandidatarbeten och webbkällor publicerade av privatpersoner har blivit noga kritiskt granskade innan de tagits med.

SLUTSATSER

Syftet med detta arbete var att jämföra prestandan hos applikationer utvecklade med React Native och Cordova. För att komma fram till ett svar utvecklades tre enkla applikationer med de båda verktygen. Mätningar genomfördes på de olika applikationerna som visade att applikationerna utvecklade med Cordova generellt presterade bättre än de utvecklade med React Native. Skillnaden på CPU-användning var stor, Cordova hade en genomsnittlig CPU-användning som var 76% lägre än React Native. Minnesanvändningen skiljde sig inte lika mycket men i genomsnitt var den 18% lägre än React Native. Skillnaden i minnesanvändning var som minst i applikationer som hade mycket animationer.

Denna artikel visar att om ett företag redan har en enkel webbapplikation och vill släppa en mobilapplikation kan Cordova vara ett bra val jämfört med att utveckla en ny applikation i React

(11)

Native. Den visar även att om man utvecklar enkla applikationer till enheter som kommer ha begränsad processorkraft kan Cordova vara att föredra på grund av dess låga processoranvändning jämfört med React Native.

Framtida arbeten

I framtiden skulle det vara intressant att mäta fler faktorer än CPU-användning och minnesanvändning. För att få en bättre bild på hur applikationer utvecklade med dessa verktyg presterar skulle man även kunna mäta uppstartstid, energianvändning, applikationsstorlek, tid för att byta mellan skärmar i applikationen, responstid för användarinteraktion och självfallet FPS.

Det hade även varit av intresse att jämföra större applikationer för att se hur verktygen hanterar att skalas upp. Resultaten kanske hade förändrats vid applikationer som kräver ännu mer resurser. Detta är något som dock kräver betydligt mer tid och planering.

För att få korrekta och mer rättvisa resultat hade ett bra verktyg behövts som kan mäta applikationer som är byggda för produktion, så inga debug-verktyg sänker prestandan för applikationerna. Hade ett sådant verktyg släppts hade det varit av intresse att göra om de tester som utfördes och se om resultatet förändrades.

REFERENSER

[1] Bosnic, Stefan, Ištvan Papp, and Sebastian Novak. "The development of hybrid mobile applications with Apache Cordova." In 2016 24th Telecommunications Forum (TELFOR), pp. 1-4. IEEE, 2016.

[2] Ciman, Matteo, and Ombretta Gaggi. "An empirical analysis of energy consumption of cross-platform frameworks for mobile development." Pervasive and Mobile Computing 39 (2017): 214-230.

[3] Facebook Inc. “React Native · A framework for building native apps using React” https://reactnative.dev/showcase.html

(2020-05-03)

[4] Google LLC. “Understanding Systrace | Android Open Source Project” https://source.android.com/devices/tech/debug/sy strace (2020-05-04)

[5] Hansson, Niclas, and Tomas Vidhall. "Effects on performance and usability for cross-platform

application development using React Native." Linköping University. (2016).

[6] Hui, Ng Moon, Liu Ban Chieng, Wen Yin Ting, Hasimah Hj Mohamed, and Muhammad Rafie Hj Mohd Arshad. "Cross-platform mobile applications for android and iOS." In 6th Joint IFIP Wireless and Mobile Networking Conference (WMNC), pp. 1-4. IEEE, 2013. [7] Jagiello, Jakub “Performance Comparison

Between React Native and Flutter”. Umeå University. (2019)

[8] Korf, Mario and Eugene Oksman. “Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options” https://developer.salesforce.com/index.php?oldid =51601_(2020-05-06)

[9] Malavolta, Ivano, Stefano Ruberto, Tommaso Soru, and Valerio Terragni. "End users' perception of hybrid mobile apps in the google play store." In 2015 IEEE International Conference on Mobile Services, pp. 25-32. IEEE, 2015.

[10] Microsoft. “TypeScript: Typed JavaScript at Any Scale.” https://www.typescriptlang.org/ (2020-05-27)

[11] Patil, Shubham. “Using React with Cordova”. https://medium.com/@pshubham/using-react-wit h-cordova-f235de698cc3 (2020-05-26)

[12] Shah, Kewal, Harsh Sinha, and Payal Mishra. "Analysis of Cross-Platform Mobile App Development Tools." In 2019 IEEE 5th International Conference for Convergence in Technology (I2CT), pp. 1-7. IEEE, 2019. [13] Stack Overflow. “Stack Overflow Developer

Survey 2019”

https://insights.stackoverflow.com/survey/2019 (2020-06-10)

[14] StatCounter. “Mobile Operating System Market Share Worldwide | StatCounter Global Stats” https://gs.statcounter.com/os-market-share/mobil e/worldwide_(2020-05-05)

[15] Statista. “Number of smartphone users worldwide from 2016 to 2021”. https://www.statista.com/statistics/330695/numb er-of-smartphone-users-worldwide/ (2020-05-26) [16] Wargo, John M. Apache Cordova API

Cookbook. Pearson Education, 2015.

[17] Xanthopoulos, Spyros, and Stelios Xinogalos. "A comparative analysis of cross-platform development approaches for mobile applications." In Proceedings of the 6th Balkan Conference in Informatics, pp. 213-220. 2013.