yelp

  • Coltin Caverhill, inginer software
  • 12 mai 2016

Fie că este vorba de utilizarea bateriei, de rețea sau de timp, ne pasă mult de resursele utilizatorilor noștri. O aplicație mare creează o barieră de intrare pentru utilizatorii din rețele de măsurare sau de viteză redusă. Ultima Ziua Recunoștinței, alertele noastre automate ne-au anunțat că dimensiunea aplicației noastre era din ce în ce mai mare decât ne-ar plăcea și făcând mai dificilă descărcarea aplicației de către utilizatorii cu resurse reduse.

Aici am văzut o tendință ascendentă în dimensiunea aplicației pe măsură ce am adăugat mai multe funcții și am construit o aplicație mai convingătoare. Pentru a aborda dimensiunea aplicației, mai întâi a trebuit să înțelegem de unde provine acea dimensiune.

Defalcarea unei versiuni de versiune în jurul lunii septembrie 2015.

Privind aceste două grafice, am putut vedea că imaginile au ocupat un procent mare din dimensiunea globală a APK-ului. Dar de ce au ocupat un procent mai mare de spațiu odată ce a fost comprimat?

Motivul a fost că imaginile nu sunt comprimate în timpul procesului de arhivare a APK-urilor. Aceasta este pentru a permite imaginilor să fie cartate de memorie de pe disc, mai degrabă decât să le încărcați în RAM. Aceasta este o optimizare excelentă a sistemelor de operare moderne precum Android, dar înseamnă că nu ne putem baza pe procesul APK pentru a optimiza imaginile pentru noi. Fiecare octet dintr-o imagine se traduce într-un octet din APK-ul final.

A început să pară că am putea face o mare diferență prin reducerea dimensiunii fișierului imaginilor noastre. În căutarea potențialelor îmbunătățiri, am aflat că Android 4.2.1 a introdus un nou format de imagine numit WebP care pretindea o compresie mai bună decât JPEG sau PNG. Din fericire, aplicația Yelp acceptă Android 4.4+ și imaginile sale sunt în majoritate PNG-uri cu câteva JPEG-uri. Pentru a testa revendicările WebP, am convertit peste 2000 de PNG-uri cu această comandă:

Doar 8 din cele peste 2000 de PNG pe care le-am comprimat nu au beneficiat de conversia în WebP, iar diferența pentru acestea a fost extrem de mică (doar în jur de 400 de octeți). În general, dimensiunea APK-ului comprimat a scăzut de la 27,1 MB la 23,1 MB, fără pierderi în calitatea imaginilor. Defalcarea noastră a favorizat încă imagini destul de puțin, dar nu la fel de semnificativ.

Această reducere a dimensiunii a fost grozavă, dar am avut îngrijorări cu privire la performanța în timpul rulării. WebP ar necesita mult mai mult timp de procesare pentru a decoda/reda? Am ajunge să folosim mai multă memorie? Folosind instrumentele de performanță Android, nu am găsit nicio creștere a memoriei sau a încărcării procesorului la încărcarea imaginilor WebP comparativ cu variantele lor PNG pe o varietate de dispozitive. Rezultate similare au fost raportate de această lucrare pe WebP, care este Android agnostic.

Neavând alte preocupări, am trecut la producție. Am configurat un cârlig pre-commit care convertește PNG-urile automat în WebP fără pierderi. Acest lucru ne-a permis să ne bucurăm de o aplicație mult mai mică, fără a fi nevoie să facem nicio muncă de dezvoltare suplimentară - câștig!

Cu toate acestea, povestea nu se termină aici

Dar despre conținutul cu pierderi, cum ar fi JPEG-urile pentru fotografii?

Ca parte a unui experiment de integrare, am adăugat trei fotografii noi pentru a uimi și a uimi noii utilizatori. Cu toate acestea, când acest experiment a fost împins să stăpânească, alertarea noastră ne-a informat că a fost foarte nefericit.

De ce a fost atât de nebun după această nouă imagine!?

S-a dovedit că unele dintre aceste imagini erau JPEG-uri destul de mari, cele mai mari fiind de 1,4 MB. Rețineți că acestea nu vor fi comprimate în APK-ul final, astfel încât fiecare octet al fiecărei imagini va fi trimis utilizatorilor. Toate activele noi combinate pentru a ne oferi o creștere cu 34% a dimensiunii APK-ului față de versiunea noastră anterioară, de la 21,88 MB la 29,39 MB!

Pentru a comprima aceste imagini, am încercat să convertim la WebP fără pierderi, așa cum am făcut înainte. Cu toate acestea, aceste noi imagini erau fotografii bogate, cu multă culoare, așa că nu am văzut câștiguri similare dintr-o compresie fără pierderi. Cu o compresie fără pierderi într-o fundătură, am încercat să folosim în schimb compresia cu pierderi:

cwebp -pass 10 -m 6 -mt -jpeg_like -q 60 [2]

92KB 60 pierdere de calitate

62KB 40 pierdere de calitate

Reducerile au fost uriașe! După conversia tuturor imaginilor noi, dimensiunea finală a APK-ului nostru a fost de 22,76 MB, ceea ce a reprezentat o îmbunătățire excelentă față de 29,39 MB.

Deoarece acest proces a fost extrem de subiectiv, nu am adăugat acest lucru la cârligele noastre de pre-comitere. Unele imagini, cum ar fi pictogramele, ar trebui să fie întotdeauna de foarte înaltă calitate și să fie comprimate numai fără pierderi; în timp ce altele, precum fotografiile mari, vor beneficia de diferite grade de compresie cu pierderi. Luarea acestei decizii este greu de automatizat.

Pentru cei blocați cu PNG-uri (care acceptă o versiune minSdkVersion mai mică de 17) sau pentru cei care nu sunt destul de gata să treacă pe WebP, Colt McAnlis a scris un articol foarte detaliat despre compresia PNG. Include multe metode pentru a elimina octeți inutili din imagini care nu intră în sfera acestui articol.

Conversia WebP a fost o modalitate rapidă și ușoară pentru noi de a reduce dramatic dimensiunea APK-ului nostru. Dacă aplicația dvs. folosește o mulțime de imagini, această strategie ar trebui să vă ajute și pe voi! Deși efectele reducerii dimensiunii APK-ului nu sunt bine cunoscute, este totuși destul de ușor: atunci când ne putem reduce cu ușurință impactul asupra stocării și utilizării datelor utilizatorilor noștri, vom face!

Note de subsol

Cwebp este un program furnizat de Google pentru a converti imagini în WebP. Aici, îl lăsăm să facă cantitatea maximă de analize trecute (-pass 10). Am setat metoda de compresie la cea mai lentă (-m 6) pentru a obține cea mai bună compresie. Am activat multithreading (-mt) pentru unele îmbunătățiri ale vitezei. Și, în cele din urmă, am specificat că dorim ca imaginea să fie fără pierderi (-fără pierderi), astfel încât să nu avem nicio calitate pierdută în imaginea noastră WebP produsă. Există mai multe opțiuni disponibile pentru cititorul inteligent

Aici am eliminat opțiunea fără pierderi (-fără pierderi), astfel încât cwebp să elimine de fapt calitatea imaginii. I-am spus cwebp să folosească o metodă de compresie similară cu JPEG (-jpeg_like) deoarece știm că toate acestea sunt fotografii. Și în cele din urmă avem setarea de calitate (-q 60), care este similară, dar diferită de setările de calitate JPEG. Valoarea 60 a fost selectată după experimentarea cu valori diferite pentru aceste fotografii specifice și părea să ne ofere cea mai mare reducere a dimensiunii fișierului înainte ca pierderea multă calitate să se observe. Imaginile dvs. specifice și pragurile de calitate vor varia .В ↩