Xamarin VS Native Apps del 2/2

Xamarin VS Android og iOS (iPhone og iPad) native app udvikling. Anden del omhandler udviklingsmiljøer, memory management & garbage collection.

Dette er anden og sidste del af Xamarin VS Native Apps blog miniserien. Hvis du ikke har læst den første del kan den findes her. I denne blog post sammenlignes de tilgængelige udviklingsmiljøer og sprog, og vi berører problemer i forbindelse med memory management og garbage collection.

Udviklingsmiljøer / IDE’er

Jeg tager udgangspunkt i de tre tilgængelige standard IDE’er til OS X. De har hver deres fordele og ulemper, men er overordnet set gode og ret avancerede allesammen.

  • Xamarin Studio er lidt langsommere til build og deployment end de to andre. Især på Android kan der kan være meget lange byggetider, efter man har redigeret i ressourcefiler. På iOS hvor man er vant til få sekunders deployment, må man også vænne sig til at det tager lidt længere tid. Xamarin Studio er ret tungt og bruger mange ressourcer når det kører, som tydeligt kan mærkes på en bærbar computer. Der er desuden noget overhead i forbindelse med editering af Storyboards, da Xamarin åbner en Xcode instans for at redigere i dem.
  • Xcode har de dårligste muligheder for refaktorering og kodegenerering. Men har til gengæld nogle rigtigt gode tools til memory og CPU debugging, gode simulatorer og andre indbyggede hjælpetools. Xcode har desuden den hurtigste byggetid af de tre udviklingsmiljøer. 
  • Android Studio er ret nyt i Android verdenen, og er baseret Jetbrains IntelliJ platform. Det inkluderer nogle af markedets bedste værktøjer til refaktorering og kodegenerering. Android emulatoren har samtidig fået et gevaldigt performance løft, så man ikke længere er afhængig af tredjeparts løsninger, som f.eks. Genymotion.

Sprog

En af de helt store fordele ved Xamarin er at udviklingen foregår i C# med mange tilgængelige .NET libraries. C# er et af de mest avancerede moderne sprog, der både er meget modent og indeholder mange af de features man efterspørger som programmør. Det er desuden en stor fordel, at man kan anvende det samme programmeringssprog, til både Android og iOS udvikling.

I native iOS-udvikling har vi heldigvis for nyligt fået Swift, da tiden for længst er løbet fra Objective C. Swift er et super stærkt moderne sprog, som man dog kan mærke stadig er forholdsvis nyt, sammenlignet med et etableret sprog som C#. Men med et par år på bagen er jeg dog ikke i tvivl om, at Swift bliver et af de bedste programmeringssprog på markedet.

Java er det primære sprog til Android udviklingen. Men efter Sun blev opkøbt af Oracle i 2010, har udviklingen af Java i en længere periode været stagneret, og man er først nu ved at indhente det forspring, som C# har skabt sig i den mellemliggende periode.

Illustration over memory forbrug og garbage collection i Xamarin sammenlignet med native Android og iOS apps.

Memory forbrug & garbage collection

Xamarin anvender Mono's Simple Generational garbage collector. I sig selv er det ikke et problem, da det er en fin garbage collector. Problemet ligger nærmere i alle de problemer der medfølger ved at introducere den. Der er forskellige problemer for hhv. Android og iOS.

Android

Android har en Garbage Collector (GC) i forvejen; Android Runtime (ART) GC for nyere Android og Dalvik GC for tidligere versioner af Android. I begge tilfælde betyder det at der er to GCs i Xamarin Android apps, og skaber det vi kalder 'dobbelt garbage collector problemet'

GC i Android kan kun indsamle objekter, der ikke længere har aktive referencer. Problemet er at de to GC’er opererer i hver deres verden og derfor ikke har samme opfattelse af det samlede memory forbrug. F.eks. kan et bitmap fylde adskillige megabytes i Android, mens Mono kun ser en reference på nogle få bytes.

Der kan dermed opstå situationer, hvor Android GC har behov for at frigive memory mens alt ser rosenrødt ud på Mono siden. Android GC er ikke i stand til at fjerne de tunge bitmaps, da Mono ikke har følt et pres for at frigive referencerne til dem. Det kan i sidste ende medføre at Android delen løber tør for hukommelse og appen crasher.

Dette medfører at man som udvikler skal være mere påpasselig med apps med et stort memory behov. Her er man ofte nødt til frigive memory med manuelle eksplicitte kald til objekters .Dispose() metode.
Derudover skal man vænne sig til at C# adskiller sig på visse punkter fra det man er vant til i Java. F.eks. er eventhandlers meget anvendt i C# og disse er uhyre vigtige at man eksplicit får afregistreret igen, da de ellers holder en reference til objektet i live og dermed fører til memory leaks. Altsammen er det en tidskrævende ekstra proces, som man ikke behøver tænke over i forbindelse med native Android udvikling.

iOS

På native iOS anvendes der Automatic Reference Counting (ARC) istedet for garbage collection. ARC har den primære fordel at være meget performance-effektiv. Xamarin introducerer ovennævnte Mono GC ovenpå ARC, som betyder en forringelse af performance, sammen med alle de normale problemer en GC introducerer (som jeg ikke vil komme nærmere ind på her). 

På samme måde som i forbindelse med Android, er man i mange tilfælde nødt til at kalde .Dispose() manuelt, da ARC ikke kan frigive ressourcer før Mono GC har sagt god for det. Alt i alt et stort skridt tilbage i forhold til native iOS, da en af ARC's store fordelen, netop er at man ikke behøver at frigive ressourcer manuelt.

Opsummering

Fordele ved Xamarin

  • C# med mange gode .NET libraries. Samme sprog til både iOS og Android.
  • Kodegenbrug på op til 40%.
  • Kodning i et enkelt udviklingsmiljø (Xamarin Studio).

Ulemper ved Xamarin

  • Sværere at finde third party libraries og komponenter, samt hjælp på nettet.
  • Tager længere tid at deploye til devices.
  • Flere linjers kode og mere kompliceret kode.
  • Større binaries grundet behovet for Mono biblioteker.
  • Lidt mere besværligt at implementere views (specielt på iOS).
  • Memory forbrug & garbage collection kan medføre betydelige problemer og crashes. Og tilfører som minimum et ekstra niveau af kompleksitet i koden.

 

Konklusionen er at Xamarin kun kan anbefales til nogle specifikke typer apps. Den delte mængde kode imellem Android og iOS skal være stor, og appen skal være forholdsvis statisk rent UI og UX mæssigt. Hvis der forventes at være mange løbende ændringer til UI og UX, indhenter ulemperne hurtigt besparelsen ved den delte kode.

Det betyder efter min mening og alt taget i betragning, at det ikke kan svare sig at anvende Xamarin i de fleste app projekter. Hvis der er nogen besparelse at hente er den minimal, og det er derfor en unødvendig risiko at anvende et tredjepart-system, som man ikke selv har nogen kontrol over.

 

Af Andreas Juul Hirszhorn
Lead iOS udvikler hos Touchlogic