spyked bricks in the wall

un argument împotriva închipuitei fragmentări a ecosistemului android

Acest articol poate fi considerat o prelungire a breviarului istoric ARM, în mare pentru că ilustrează cu mai multe amănunte implicațiile pe care le aduce varietatea dispozitivelor și platformelor bazate pe arhitectura ARM. După cum bine știm deja, problemele software-ului se mapează de multe ori unu la unu pe cele ale hardware-ului de dedesubt, motiv pentru care argumentul va fi extins la proiectul care face cel mai bine uz de această varietate, și anume sistemul de operare Android [i].

Zisul argument vine împotriva tuturor gurilor rele care susțin sus și tare că „Android e un mediu fragmentat”, spre deosebire de iOS-ul de la Apple care nu este și nici nu are cum să fie, dat fiind că vine într-o unică varietate pe o unică platformă hardware (plus minus una-două), bazată tot pe ARM. Cititorul se poate lămuri în legătură cu problema printr-o căutare pe Google după „android fragmentation”, care întoarce literalmente sute de rezultate relevante. Sigur, așa-zisa fragmentare s-ar putea să fi fost o problemă pe versiunile 2.x de Android [ii], însă clar nu se mai poate vorbi despre așa ceva la nivelul Android 4.x, pentru că vedeți în continuare.

Un site, pe numele său OpenSignal, expune publicului rezultatele agregate ale unui studiu făcut pe jde mii de dispozitive produse de jde mii de producători. Articolul include câteva diagrame foarte drăguțe care spun un adevăr, deci care merită din plin să fie expuse analizei și interpretării. De asemenea autorii articolului împart problema fragmentării în trei aspecte: „the blessing” (aspecte pozitive), „the curse” (aspecte negative) și „the study” (cifre). Să cităm din „the curse”:

The Curse. The proliferation of devices with their associated screen sizes, internal hardware and custom ROMs creates some difficulties. We spend a lot of time making the app presentable (or at less functional) on exotic devices – this is the most common request we get from app users.

Mai apoi este analizată problema din punctul de vedere al hardware-ului — în „Model” și „Brand” — și apoi din cel al software-ului — în API Level și Resolution. Această privire este atât incompletă cât și fundamental greșită, problema nefiind atât modelul de telefon sau producătorul, cât efectiv hardware-ul de dedesubt. Similar în cazul software-ului, interfața sistemului (API-ul) și rezoluția stau pe locul doi în spatele incompetenței programatorului de rând, care nu știe să facă uz de aceste unelte [iii]. Hardware-ul și software-ul sunt, după cum spuneam, intrinsec legate, comunitatea Android fiind obligată să producă software care funcționează pe o plajă mult mai mare de dispozitive hardware, ceea ce face munca dezvoltatorilor de la orice nivel mult mai dificilă, nu imposibilă însă.

În cele ce urmează vom analiza aceste dificultăți, ce presupun ele și cum sunt combătute atât de producătorii hardware cât și de dezvoltatorii din spatele Android.

platformele hardware bazate pe arm

Spuneam în „breviar istoric arm” că, citez:

Mai departe ARMv7 este implementat de seria Cortex Ax (unde x e un număr), Cortex A9 fiind cel mai nou membru al familiei și prezent pe device-urile de ultimă generație. Deja aici contribuția ARM trece în plan secundar, în prim plan venind producția de System-On-a-Chip. Un SoC e practic un ansamblu de unități logice sau dispozitive – procesor, cache-uri, memorie, unele controllere – integrate pe o singură pastilă de siliciu, care alcătuiesc o așa-zisă „platformă”, analog cu IBM PC.

Diferența între PC și platformele bazate pe ARM e aceea că nu există – și mă îndoiesc că va exista prea curând – un standard în privința „așezării” dispozitivelor I/O, existența lor, maparea accesului la memorie și așa mai departe. Fiecare producător a pus pe placă ce a considerat de cuviință – unele sunt axate pe procesare de semnal, altele sunt foarte configurabile deci au FPGA-uri etc. – și a scos un SoC pentru aplicații de rețelistică, telefonie mobilă sau mai știu eu ce. Dezavantajul acestei abordări este evident munca în plus depusă de programatorii de drivere, care trebuie să adauge suport pentru fiecare SoC în parte. Aspectul ăsta bineînțeles că nu e o problemă foarte mare pentru modelele scalabile de inginerie software, așa cum este nucleul Linux.

Să ne înțelegem deci, Linux este o minunăție de nucleu. Inginerii ARM, Texas Instruments sau mai știu eu care contribuie din timp cu specificații și cod în kernel, astfel că de exemplu până apare primul dispozitiv bazat pe OMAP 5, acesta din urmă va putea rula un sistem bazat pe Linux. Ecosistemul Android rulează deasupra nucleului, ceea ce îl scapă de majoritatea problemelor legate de hardware. O minoritate a problemelor e creată de producătorii de hardware proprietar, care își dau cu tesla în coaie programând drivere în spațiul utilizator Linux [iv], ceea ce duce evident la alte probleme legate de API, care implică aspecte legate de securitate, performanță și așa mai departe.

Argumentul că hardware-ul este „prea variat”, pardon, „fragmentat”, este în concluzie cât se poate de pueril. Microsoft programează de câteva decenii un sistem de operare care suportă o singură arhitectură — sau mai nou două — și tot au probleme uriașe cu mentenanța. Codul de arhitectură ARM, peste care apropo, vă invit să vă uitați, este foarte bine factorizat iar următoarea versiune de Linux va duce totul cu un pas mai departe. Cum e afectat deci programatorul de aplicații de toate acestea? Citiți mai departe și poate vă veți lămuri.

software design, or a lack thereof

Am stat de-a lungul timpului de vorbă cu prieteni care programează peste Android, iar aceștia mi-au confirmat faptul că API-ul e plin de lipsuri. Cum n-am programat niciodată în Android la nivelul aplicațiilor, îmi e greu să mă exprim în sensul ăsta, deci voi lua de bune toate zisele, inclusiv cea că există o fragmentare între diversele versiuni. Știu că Android 4.0 a făcut un efort mare în sensul reducerii fragmentării și știu că majoritatea smartphone-urilor merg la ora actuală cu Android 2.3 instalat.

Am folosit însă aplicații care funcționează cu zero probleme atât pe Android 2.3 cât și pe Android 4.1. Bag seama că anumiți programatori au reușit să se adapteze la cerințele interfeței de programare, în timp ce alții au eșuat, fie din probleme tehnice cum ar fi lipsa suportului hardware, fie din probleme care țin pur de inginerie prost aplicată. Cu alte cuvinte mi se pare că dezvoltatorii software tind să ia tot gunoiul cu RAD și Agile prea în serios și să scoată un mare rahat din el, fără a lua în calcul costurile unei livrări rapide. Dar bine, să zicem că nu mă pricep eu la paradigme de dezvoltare și project management, să presupunem în bunăvoința noastră că orice dezvoltator își propune să ofere software de calitate [v].

În acest scop Google au publicat un set de guideline-uri, care stabilesc cum ar trebui să arate în linii mari o aplicație pe Android. Documentul respectiv e făcut astfel încât să poată fi citit de orice „average joe”, adică inclusiv orice programator profesionist sau amator de aplicații. Programele Google (Gmail, Google Maps, Google Reader, Google Talk etc., etc.) respectă aceste guideline-uri, și în rest cu câteva excepții notabile lista se oprește aici, pentru că nu scrie nicăieri că regulile respective ar fi stricte și executorii. Drept urmare dezvoltatorii nu le respectă, după care se plâng că „mediul e fragmentat” și „programarea pe Android e grea” și alte prostii din astea demne de un elev de clasa a patra. Ăsta e până la urmă dezavantajul de a nu fi săpat gropi, respectiv de a nu fi cărat saci de cartofi niciodată în viața ta: toate par prea grele.

Realizările comunităților Linux și Android sunt în mod incontestabil impresionante: un mediu software având o complexitate crescută în raport cu cea mai mare parte a software-ului existent, care permite portarea aceluiași cod peste țșpe mii de platforme hardware cu un efort minim. Iar dacă „fragmentarea” dată de mici chițibușuri cum ar fi rezoluția ecranului vi se par probleme, vă invit încă o dată să dați o privire peste codul de arhitectură din Linux, să observați cum mii de oameni au scris milioane de linii de cod pentru suportarea a zeci de arhitecturi și platforme hardware. Și iată că Linux merge, și nu oricum, ci chiar foarte bine, în ciuda închipuitei fragmentări.

1. În mod normal câștigătorul ar trebui să fie mediul GNU/Linux, care însă consider că are mari lacune la nivelul portării interfețelor cu utilizatorul și a altor aplicații posibil dependente de arhitectură. [↩]
2. Care într-un mod ironic acoperă cea mai mare parte a dispozitivelor mobile cu Android de pe piață la ora actuală. Chestia o să devină istorie într-un timp foarte scurt, dacă nu luăm în calcul chinezăriile foarte ieftine, ci doar pe cele suficient de fiabile. [↩]
3. Faptul e în egală măsură valabil pe iPhone-uri. Sigur că Apple au construit peste Objective C un API mult superior celui oferit de Android prin bibliotecile sale și prin limbajul de programare — care, cu părere de rău o zic, va rămâne în istorie drept un COBOL al anilor 2000 –, însă se poate programa la fel de prost și peste acela. Diferența e că Apple își rezervă dreptul de a elimina din magazinul virtual orice dejecție găsesc ei de cuviință. [↩]
4. Adică deasupra Linux-ului. Practic driver-ul e un program ca oricare altul, iar nucleul implementează un stub care îi oferă programului acces la resursele hardware. Discuția asupra avantajelor și dezavantajelor se întinde de aici pe hectare de literatură, însă e de ajuns să spunem că producătorii de hardware preferă să facă asta pentru a nu intra în conflict cu clauzele GPL din nucleul Linux. Altfel spus, nu toată lumea e Nvidia. Vedeți și „proprietatea intelectuală, implicații tehnice”. [↩]
5. Presupunere care e în mod evident falsă. Vasta majoritate a aplicațiilor de pe market-ul Android, sau Google Play cum îi zice mai nou, sunt pline de publicitate, ceea ce denotă fix opusul calității. Da dragilor, în caz că nu știți, mizeriile alea consumă resurse, ceea ce dispozitivele mobile nu prea au. Dar bine, toată lumea dorește să facă bani și puțini clienți se încumetă la a plăti doi dolari, sau cât costă o aplicație fără ad-uri. Comportamentul ăsta al cumpărătorilor ar putea face obiectul unui studiu foarte amplu, cred eu. [↩]