Xamarin VS Native Apps del 2/2

 
 iOS versus Native app udvikling del 2
 
 

 

Dette er anden og sidste del af Xamarin VS Native Apps blog miniserien. Den første del handlede om fordele og ulemper ved Xamarin og native udvikling. Denne gang 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.

  • 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 redigering 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

Xamarin annoncerer på deres hjemmeside, at der i gennemsnit er 75% genbrug af kode imellem forskellige platforme i Xamarin app projekter. Efter i praksis at have anvendt Xamarin i store projekter, virker den procentsats betydeligt overdrevet. Vores erfaring viser, at det er svært bare at opnå 50% genbrug, og at man nok maksimalt skal regne med omkring 40%.

Det er primært servicekald, intern datahåndtering, modelklasser og lignende, der kan genbruges, imens alt UI generelt implementeres enkeltstående for hver platform. Til udvikling af UI anvendes:

  • Xcode Interface Builder eller Xamarin iOS designer, med storyboard og .xib filer for iOS.
  • Standard XML layout filer for Android.

 

De bagvedliggende klasser implementeres også separat for hvert platform da, der i forbindelse med programmering af views og viewcontrollers er så mange afhængigheder til de respektive platformes API’er, at det er svært at genbruge specielt meget.

Den reelle delte kodebase er altså maksimalt den del af projektet, der ikke er relateret til UI’en. Men da de fleste smartphone og tablet apps er ret viewtunge, ender det delte med at være mindre end det, der skal implementeres specifikt til hvert platform.

 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 udfordringer, der medfølger, når man introducerer 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 GC’er i Xamarin Android apps, og det skaber, hvad 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 har derfor ikke 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, imens 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.

 

Det 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. Sammenlagt er det en tidskrævende ekstra proces, som man ikke behøver at tænke over i forbindelse med native Android udvikling.

 

iOS

På native iOS anvendes der Automatic Reference Counting (ARC) i stedet 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.

 

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 fordele 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. Det 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 betragtning, 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