Android-fragmentering er den største vanskelighed, som udviklere har til at starte en applikation på markedet. Android er langt fra at være en samlet platform med et par enheder ligesom iOS.
Nogle tal om fragmentering
For at få en idé om, hvor opdelt Android er, kan vi se en reel use case. Der er flere virksomheder, der udgiver meget brugte applikationer, og senere indsamler brugsdata. En af dem er OpenSignal, som for nylig har offentliggjort sin seneste undersøgelse.
Tallene er ødelæggende:
- 18.796 forskellige Android-enheder set i år, en stigning fra 11.868 sidste år (en stigning på 58%).
- Samsung er den fremragende førende producent med 43% af enhederne. Resten distribueres af mere end 80 forskellige producenter.
- Der er 6 forskellige versioner af operativsystemet aktive med et stort nok antal brugere til at blive ignoreret.
- Der er også et meget stort antal forskellige opløsninger og skærmstørrelser. Og selvfølgelig med forskellige forhold mellem højde og bredde.
Til disse data skal vi tilføje forskellige hardwareelementer, såsom et sæt sensorer, der kan variere fra en enhed til en anden, eller en anden grafikprocessor, der får OpenGL-spiludviklere til at dække dem alle.
Kort sagt et mareridt, at hvis vi ikke kontrollerer ordentligt, kan det koste os mere end en utilfredshed. Det er ikke ualmindeligt at finde projekter på Android, hvor det efter afslutning af den første version ender med at bruge mere tid på at porte til de forskellige modeller end i selve den første version. Det kan være meget frustrerende.
Står over for fragmentering
Selv om det er en kompliceret opgave, kan vi opnå et godt resultat, hvis vi følger en bestemt disciplin i udviklingen inden for en rimelig tid. For det begynder vi med et par indledende overvejelser.
Arbejd med fragmentering fra starten
Oprettelse af en bestemt version til en bestemt mobil først og derefter portering er en hyppig fejl. Det er almindeligt at falde ind i komforten ved kun at se på den enhed, vi har ved hånden, men hvis vi vil frigive vores ansøgning om et bredt marked, vil efterladning af fragmentering til sidst tvinge os til at foretage dyre ændringer i vores projekt. Vi tager længere tid og laver flere fejl. For eksempel, hvis vi ikke designer vores synspunkter til at være fleksible til at imødekomme forskellige skærmstørrelser, bliver vi nødt til at gøre dem senere. Noget svarende til hvad der skete med ressource placering.
I denne forstand er der en række spørgsmål, som vi kan stille os selv, inden vi starter, og som vil hjælpe os med at få et køreplan.
- Hvilken version af operativsystemet vil jeg understøtte? Kun nylige mobiltelefoner, eller ønsker jeg, at min applikation skal fungere for ældre modeller?
- Ønsker jeg kun at understøtte mobiltelefoner, kun tablets eller begge dele?
- I hvilke lande vil jeg offentliggøre min ansøgning? Hvilke sprog vil jeg støtte?
Med det første spørgsmål kan vi spørge os selv, hvilken funktionalitet vi vil medtage i vores applikation. Hvis vi understøtter gamle versioner, bliver vi nødt til at vælge mellem at ofre funktionaliteten i de nye versioner af Android eller frigive forskellige versioner af vores applikation. Min personlige anbefaling er den første mulighed, medmindre du har nok ressourcer og udviklere til at arbejde med to forskellige versioner af det samme produkt.
Med det andet vil vi være klare over, hvordan vi bliver nødt til at udvikle vores synspunkter uden at miste synet af det de forskellige versioner af vores grafiske ressourcer. Endelig skal det bortset fra placeringen af teksterne tages i betragtning, at der afhængigt af det land, hvor vi offentliggør vores ansøgning, vil være ældre eller mere moderne mobiltelefoner.
Antag, at ikke alle mobiltelefoner kan dækkes
Med så meget fragmentering vil der altid være "sjældne" tilfælde, som vi ikke er værd at dække. Der vil altid være en model, der har problemer med at optage eller gengive lyd eller udføre et bestemt videoformat ... eller enhver anden mulighed. Det faktum, at Android er et gratis system, giver hver producent mulighed for i nogen grad at implementere operativsystemet efter deres smag, hvilket uundgåeligt får os til at have modeller, der er svære at dække.
Her er en god pragmatisme afgørende. Det er ikke muligt at dække et par enheder, der bruges af et meget lille antal brugere, det vil tage os mere tid end at dække almindelige enheder. Den bedste strategi er at sikre enhederne med den mest tilstedeværelse på markedet på det tidspunkt, hvilket igen vil hjælpe os med at få meget af resten til at fungere også. Derefter vil vi fortsætte med at forbedre vores ansøgning, indtil vi får en rimelig god dækning - en veludviklet applikation overstiger let 80% dækning.
Med alt dette kan vi begynde at arbejde. Selvom vi allerede har citeret nogle nyttige teknikker, vil vi nu gennemgå dem detaljeret.
- Vores synspunkter vil altid være fleksible. Vi bruger aldrig absolutte værdier til pixelstørrelser, meget mindre en AbsoluteLayout. Alle vores målinger vil være i afhængige pixels eller dp, og vi vil bruge relative proportioner og målinger, når det er muligt.
- Vi tester vores synspunkter i forskellige skærmstørrelser. For ikke at skulle prøve dem alle, er en god tilgang at prøve en af de største enheder, en anden af de mindste og en imellem.
- Vi sørger for at have alle de grafiske ressourcer til rådighed for alle skærmtætheder, hvilket gør det lettere for os at have 100% fleksible visninger.
- Vi sørger for at have separate kodetekster til støtte for internationalisering.
- Vi vælger den laveste version af operativsystemet, som vi vil arbejde med, og udvikler kun med det, hvis det er muligt. Hvis ikke, opretter vi forskellige versioner til forskellige operativsystemer, selvom jo færre jo bedre. Nogle gange finder vi tredjepartsbiblioteker, der implementerer funktionaliteter i nyere versioner uden at skulle bruge dem direkte, det er et interessant alternativ at overveje.
- Vi vil uundgåeligt teste. På markedet er der virksomheder, der udelukkende er dedikeret til testning, og med ganske rimelige priser kan vi få en automatisk test til en bred vifte af enheder.
- Og til sidst vil vi ikke udelukke brugerfejlrapporter, som uundgåeligt vil nå os. Med dem vil vi helt sikkert opdage detaljer, som vi savnede.
