Un ghid prea amănunțit pentru bibliotecile Android subutilizate

Orice dezvoltator cu experiență vă va spune că cel mai bun cod al lor nu este codul pe care l-a scris. Este un cod pe care l-au luat din munca altcuiva.

Da, noi, dezvoltatorii, suntem inovatori care rezolvă probleme, dar multe dintre problemele pe care le întâlnim au fost deja rezolvate – iar remediile sunt ambalate în biblioteci disponibile pentru oricine. De ce să reinventeze roata când roțile libere sunt peste tot?

Android nu face excepție. Sursa supremă pentru reutilizarea codului este SDK-ul Android în sine, care vine cu construcții și servicii excelente care vă vor face o mare parte din munca dumneavoastră.

Dar acolo unde SDK-ul este scurt, comunitatea Android a creat câteva biblioteci de top care vă pot economisi o mulțime de muncă de codare, înlocuindu-l cu implementări foarte bine reglate, verificate și testate. Nu vorbesc despre bibliotecile evidente - Android Support Library, Android Design Support Library, Gson. Mă refer la instrumente despre care poate nu le cunoști. Și chiar dacă o faci, probabil că nu le folosești încă.

Am dezvoltat, îndrumat și condus echipe Android de ani de zile și am studiat și folosit zeci de instrumente și biblioteci externe. (Chiar am fost cunoscut că citesc codul lor de implementare și discută despre aspectele interne cu dezvoltatorul.) Mulți au fost extrem de eficienți în a mă ajuta să-mi fac treaba, dar adevărul este că majoritatea nu au fost.

De aceea am pus acest ghid împreună. Bazați-vă pe experiența mea, precum și pe cea a altor dezvoltatori de telefonie mobilă, pentru a vă asigura că utilizați cele mai bune biblioteci. Am ales șapte. Bănuiesc că vor fi și unele dintre preferatele tale foarte curând.

Selectarea bibliotecii Android potrivite

Când aleg o bibliotecă, caut patru caracteristici cheie:

• Oferă o soluție consistentă și de înaltă calitate pentru o problemă reală și nebanală.
• Utilizează un API cât mai simplu posibil.
• Nu forțează nicio modificare în arhitectura mea generală.
• Are o bază mare de utilizatori și, de preferință, o comunitate activă de dezvoltatori.

Primele trei caracteristici sunt deal-breakers. Dacă nu sunt prezenți, merg mai departe sau încep să codific manual.

Bibliotecile pe care le acopăr mai jos trec toate cele patru teste. Ele rezolvă, de asemenea, unele dintre cele mai provocatoare aspecte ale dezvoltării mobile.

• Două biblioteci pentru injectarea dependenței, legarea layout-la-Java, obiecte simulate.
• Model de mesagerie pub/sub în aplicație.
• Strat de comunicare HTTP securizat, eficient, cu auto-recuperare.
• Manipularea imaginilor: descărcare, stocare în cache, redimensionare și încărcare în RAM.
• Streaming video în timp real.
• Detectarea scurgerilor de memorie.

ButterKnife: Instrumentul suprem de injectare a dependenței

Aceasta este biblioteca de injecție de dependență supremă pentru Android. Simplu, robust, super rapid (fără reflectare!) și capabil să elimine o mulțime din codul standard al aplicației tale.

A dispărut nevoia de a lega direct fiecare dintre vizualizările dvs. printr-un apel la findViewById() ; în schimb, există o vizualizare adnotată care vă oferă acces direct la cod. ButterKnife elimină, de asemenea, nevoia de evenimente UI standard, cum ar fi onClick , onTouch și așa mai departe, și le înlocuiește cu cod auto-injectat.

Dar destulă discuție, să vedem codul.

Vedeți legarea câmpului:

 class MyButterKnifeActivity extends Activity { @BindView(R.id.name) TextView name; @BindView(R.id.address) TextView address; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.simple_activity); ButterKnife.bind(this); // MUST BE CALLED BEFORE ACCESSING UI FIELDS name.setText(“etc etc”); } }

Legarea resurselor:

 class ExampleActivity extends Activity { @BindString(R.string.username) String username; @BindDrawable(R.drawable.graphic) Drawable graphic; @BindColor(R.color.bg_color) int bgColor; @BindDimen(R.dimen.lower_padding) Float lowerPadding; // and no need for getResources().getString()/getDrawable/getColor() }

Legarea evenimentelor UI:

 @OnClick(R.id.my_button) public void clickHandler(View view) { // onClick logic goes here }

AndroidAdnotations: Ducerea injecției de dependență la următorul nivel

Aproape de ButterKnife când vine vorba de injectarea dependenței, AndroidAnnotations folosește o abordare puțin diferită: clasele autogenerate, care, odată ce le înțelegi, sunt extrem de simple. Și mai util este că vă permite injectarea dependenței „pe bază de nume”. De exemplu, @ViewById ListView myUserList; instruiește bibliotecii să atribuie acestui câmp un layoutListView cu același nume.

AndroidAnnotations este, de asemenea, fulgerător, dar realizează asta într-un mod oarecum diferit de ButterKnife. În loc de injectarea dependenței de legare la timpul de execuție, AndroidAnnotations creează o duplicare a tuturor activităților afectate și împinge logica de conectare în ele, permițându-vă astfel să obțineți aceeași performanță pe care ați avea-o cu logica codificată manual.

Dar capacitățile de injectare ale AndroidAnnotations merg chiar mai departe de atât. Puteți injecta atât starea, cât și aspectul într-o activitate.

Implementarea AndroidAdnotations:

 @NoTitle @Fullscreen @EActivity(R.layout.my_layout) public class MyActivity extends Activity { @ViewById ListView customerList; // auto-binded to R.id.customerList @App MyApplication app; // auto-binded to app object @AminationRes Animation fadeoutAnimation; @UiThread void updateUI() { // main thread action } }

Ultima adnotare necesită puțin mai multe explicații: o sarcină obișnuită pentru o aplicație Android cu mai multe fire este trecerea de la firele de execuție (sau worker) la firul direct (sau principal sau UI), care este singurul care permite accesul la componentele UI . Această sarcină, deși nu este complexă, este adesea necesară și implică o codificare dezordonată:

 new Handler(Looper.getMainLooper()).post(new Runnable() { logic goes here } ); // NO ANNOTATIONS

În AndroidAnnotations, tot ce trebuie să faceți este să vă adnotați funcția cu @UiThread, iar acum este garantat să se execute întotdeauna:

 @UiThread void updateUI() {..} // WITH ANNOTATIONS

Rețineți că această adnotare se aplică claselor standard de componente Android (activități, servicii și așa mai departe). Dar ce se întâmplă când vreau să-mi adnot și propriile clase?

Aici, AndroidAnnotations vine cu un nou concept, cel al EBean . Tot ce trebuie să faci este să-ți marchezi clasa ca atare folosind @EBean și ești gata:

 @EBean public class MyNonComponentClass { @SystemService NotificationManager notifManager; @Bean MyOtherClass dependency; @UiThread void updateUI() { // main thread work goes here } }

EventBus: Comunicarea între componente este ușoară

Biblioteca EventBus transformă o problemă care îi bântuie pe dezvoltatorii Android de ani de zile într-o plimbare în parc. Comunicarea între componente nu a fost niciodată mai simplă – utilizați un model simplu pub/sub pentru a comunica între oricare două părți ale sistemului dumneavoastră.

Serviciul dvs. de sondare în fundal nu mai trebuie să fie conștient de fragmentele dvs. pentru a le alimenta cu evenimente de modificare.

Utilizarea EventBus este simplă.

A. Creați cursuri de evenimente. Lucrul cu POJO aici este cel mai bine:

 class NewUserEvent { String fullname; String address; String role; // add getters and setters }

b. Creați metode de gestionare a evenimentelor în clasă - orice clasă la care doriți să vă abonați pentru aceste evenimente:

 class MySubscriber { @Subscribe public void newUserHandler(NewUserEvent event) { // handle NewUserEvent } @Subscribe public void newUserHandler(AnotherEvent event) { // handle AnotherEvent } }

Dar hei, orice dezvoltator Android pe jumătate cu experiență s-ar opri și s-ar întreba în acest moment: Care este modelul de threading al acestor handlere? Și pot forța un handler să ruleze firul principal dacă, să zicem, implică acces la componenta UI? Buna intrebare…

În mod implicit, toate metodele de gestionare rulează pe un fir de lucru preluat dintr-un pool de fire care este alocat și întreținut de EventBus însuși. Dacă aveți nevoie de o metodă de gestionare care să ruleze pe firul principal, extindeți adnotările pentru abonament după cum urmează:

 @Subscribe(threadMode = ThreadMode.MAIN) public void runOnMainThreadHandler(AnotherEvent event) { … }

Avertisment: Nu folosiți excesiv această funcție! Operațiunile de lungă durată nu ar trebui să fie executate niciodată pe firul principal și, chiar și cu operațiuni rapide, aveți grijă. Copleșirea firului principal este cea mai sigură modalitate de a face aplicația dvs. lentă, sărită și, practic, mai puțin distractivă pentru utilizatorii dvs.

c. Gestionați ciclul de viață de înregistrare EventBus al clasei dvs. de abonat, adică când se conectează și când se deconectează de la autobuz? Un flux rezonabil de înregistrare pentru o activitate ar fi:

 class MySubscriberActivity extends Activity { @Override public void onStart() { super.onStart(); EventBus.getDefault().register(this); // START RECEIVING EVENTS HERE } @Override public void onStop() { EventBus.getDefault().unregister(this); // NO MORE EVENTS super.onStop(); } }

Cele de mai sus sunt, desigur, doar un exemplu. Puteți efectua (dez)înregistrarea oriunde doriți.

d. Și, în sfârșit, declanșează un eveniment:

 EventBus.getDefault().post(new MyEvent(“I'm here”));

Există multe mai multe de știut despre utilizarea EventBus: evenimente de difuzare multiplă (comportamentul implicit), utilizarea evenimentelor persistente, fire de execuție, priorități și multe altele. Dar cele de mai sus sunt suficiente pentru ca tu să începi cu această tehnologie simplă, dar puternică.

OkHttp: HttpClient Android pe steroizi

Acesta este modul în care ar fi trebuit scris HttpClient pentru Android. Foarte simplu, foarte inteligent. Biblioteca OkHttp se ocupă în mod intern de bucla de reîncercare, compresia automată a încărcăturii utile, suportul Http/2, gruparea conexiunilor și stocarea în cache a răspunsurilor, astfel încât să puteți evita accesul inutil la rețea.

Utilizarea OkHttp este o problemă.

Http POST:

 OkHttpClient client = new OkHttpClient(); MediaType JSON = MediaType.parse("application/json; charset=utf-8"); RequestBody body = RequestBody.create(JSON, json_str); Request request = new Request.Builder() .url(url) .post(body) .build(); Response response = client.newCall(request).execute(); return response.body().string();

Http GET:

 OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url(urls[0]) .build(); Response responses = client.newCall(request).execute(); String jsonData = responses.body().string();

OkHttp acceptă, de asemenea, funcții utile, cum ar fi rețelele asincrone, cererea de interogare a rutei de redirecționare, interogarea cache locală și multe altele. Simțiți-vă liber să le folosiți acolo unde este necesar. Majoritatea dezvoltatorilor folosesc OkHttp ca un înlocuitor mai inteligent pentru clientul HTTP implicit al Android, HttpURLConnection. De fapt, întregul proiect a început ca un furk privat pentru HttpURLConnection.

Îmi place robustețea sa - se adaugă imediat stratului de rețea.

Picasso: Există un motiv bun pentru care Google îl folosește și el!

Picasso este cel mai simplu și mai robust mod de a gestiona descărcarea imaginilor, stocarea în cache, redimensionarea și decuparea.

Aceasta afirmatie:

 Picasso.with(context).load(url).resize(50,50).centerCrop().into(imageView)

Voi face asta pentru tine:

• Conectați-vă la o adresă URL la distanță.
• Descărcați o imagine.
• Stocați-l într-un cache LRU local pe care îl va gestiona și pentru dvs.
• Redimensionați imaginea originală înainte de a o încărca în memorie.
• Rulați toate cele de mai sus pe un pool de fire gestionat de Picasso.
• Utilizați imaginea redimensionată pentru a vă popula imageView.
• Înainte de orice rulări viitoare, verificați memoria cache locală pentru a vă asigura că este cu adevărat necesară o călătorie dus-întors în rețea.

Construirea setului de sarcini de mai sus ar necesita multe ore de muncă, chiar și pentru un dezvoltator principal. Și asta presupune că ți-ai amintit totul. Ce se întâmplă dacă ai uitat, să zicem, partea de redimensionare?

Ei bine, pe un dispozitiv Android obișnuit, o aplicație primește nu mai mult de 50 până la 60 de megapixeli de memorie RAM, iar factorul pixeli la octeți pentru majoritatea dispozitivelor Android este de 4. Aceasta înseamnă încercarea de a încărca o imagine de 13 megapixeli de pe cardul SD ar necesita 52 Megaocteți de RAM. Cu alte cuvinte, aplicația dvs. s-ar bloca imediat.

Acesta este doar un exemplu al puterii lui Picasso. Unul dintre primele lucruri pe care le fac atunci când optimizez/depanez un proiect moștenit care consumă multă media este comutarea tuturor încărcărilor de imagini la Picasso. Ai fi surprins de impactul pe care acest pas simplu îl are asupra calității aplicației.

Una dintre cele mai puternice mărturii ale puterii acestei biblioteci: multe dintre eșantioanele de cod Android ale Google din ultimii doi ani folosesc Picasso pentru încărcarea imaginilor.

ActiveAndroid: ORM Sans Performance Overhead

ORM, prescurtare pentru cartografierea relațională a obiectelor, a devenit populară în zilele J2EE. Vă permite să stocați POJO-urile într-o bază de date și să le preluați dintr-o bază de date fără a fi nevoie să le convertiți în câmpuri separate.

Este de ajutor? Foarte mult, deoarece vă permite să scrieți o mare parte a aplicației dvs. fără a codifica nicio instrucțiune SQL.

De asemenea, este foarte eficient. Pe vremuri, platformele ORM se bazau masiv pe reflecție și erau renumite pentru că erau lente. Platformele moderne, inclusiv ActiveAndroid, sunt mult mai rapide și, pentru majoritatea cerințelor practice, nu vor suferi costuri generale de performanță față de codarea SQL brută.

Utilizare:

A. Inițializați în obiectul aplicației extinzând o clasă de aplicație personalizată:

 public class MyApplication extends extends com.activeandroid.app.Application { … }

b. Creați POJO, derivat pentru o clasă model, cu clase pentru fiecare dintre înregistrările pe care intenționați să le stocați în baza de date. Fiecare astfel de POJO poate locui în propriul său tabel. Adnotările trebuie folosite pentru a specifica numele câmpurilor DB pentru fiecare membru stocat:

 @Table(name = "Categories") public class UserDetails extends Model { @Column(name = "Name") public String name; @Column(name = "Address") public String address; @Column(name = "Age") public int age; }

Dacă doriți să setați un index pentru un membru, utilizați următoarea adnotare:

 @Column(name = "ID", index = true) public String userID;

c. Pentru a preveni iterarea bibliotecii pe toată durata de pornire cea mai elegantă, care este comportamentul implicit, este foarte recomandat să specificați toate clasele de model în următoarea secțiune de manifest:

 <meta-data android:name="AA_MODELS" android:value=“com.myapp.MyModelA, com.myapp.MyModelB" />

Notă: Clasele de model care nu apar în această listă nu vor fi recunoscute de ActiveAndroid.

d. Scrieți în baza de date:

 UserDetails usr = new UserDetails(); usr.save(); // RUNS ON A BACKGROUND THREAD

Dacă sunt necesare mai multe scrieri, o modalitate mai eficientă ar fi să le grupați într-o singură tranzacție:

 ActiveAndroid.beginTransaction(); try { for (UserDetails u: userList) item.save(); ActiveAndroid.setTransactionSuccessful(); } finally { ActiveAndroid.endTransaction(); }

e. Citiți POJO din baza de date:

 new Select() .from(UserDetails.class) .where("name = ?", usr.getName()) .orderBy("Age") .executeSingle();

ORM a fost un instrument obligatoriu în timpul zilelor mele ca dezvoltator pe partea de server. A avut o intrare oarecum târziu în domeniul Android. Dar, în sfârșit, iată-l: programarea bazelor de date la fel de simplă. Bucură de ea.

LibStreaming: Streaming video fără durere

Streamingul video în timp real era o problemă majoră din cauza API-urilor nedocumentate, a diferențelor între versiunile SDK, a utilizării reflectării și multe altele.

Din fericire, libStreaming a schimbat toate acestea prin încapsularea majorității complexităților de streaming și expunerea unui API simplu și prietenos care vă permite să scrieți o aplicație de streaming de bază în câteva ore.

Pentru a-l folosi pentru H.264 și AAC, trebuie să faceți următoarele:

A. Inițializați un obiect de sesiune la metoda onCreate a activității principale. Obiectele de sesiune reprezintă streaming media către un peer:

 protected void onCreate(Bundle savedInstanceState) { mSession = SessionBuilder.getInstance() .setCallback(this) .setSurfaceView(mSurfaceView) .setPreviewOrientation(90) .setContext(getApplicationContext()) .setAudioEncoder(SessionBuilder.AUDIO_NONE) .setAudioQuality(new AudioQuality(16000, 32000)) .setVideoEncoder(SessionBuilder.VIDEO_H264) .setVideoQuality(new VideoQuality(320,240,20,500000)) .build(); mSurfaceView.getHolder().addCallback(this); }

b. De fapt, începeți sesiunea:

 mSession.setDestination(destination_server_url); mSession.start();

c. Opriți sesiunea când ați terminat:

 mSession.stop();

Acum, vă rog să nu înțelegeți greșit. Streamingul în timp real este dezordonat prin natura lor, iar libStreaming nu elimină această complexitate. Cu toate acestea, face o treabă foarte bună ascunzându-l de tine de cele mai multe ori. În unele cazuri, va trebui să faceți față complexității, cum ar fi atunci când selectați politica de semnalizare de la egal la egal, alegeți codificarea camerei (de obicei, doriți să utilizați MediaCodec/surface-to-buffer) sau vă ocupați de pachete.

Totuși, veți descoperi că băieții buni din spatele libStreaming au făcut eforturi suplimentare în îmbinarea fără probleme a acestor complexități într-un API simplu de utilizat.

LibStreaming acceptă majoritatea codificatoarelor utilizate de aplicațiile Android, inclusiv H.264, H.263, AAC și AMR.

Am obținut rezultate grozave cu această bibliotecă. Mai multe dintre cele mai populare aplicații de streaming îl folosesc ca parte a infrastructurii sale. Dacă întâmpinați vreodată nevoia, sunt sigur că vă va face experiența de streaming media mult mai fluidă.

LeakCanary: Detectează scurgerile de memorie într-o linie de cod

Să începem cu motivația din spatele acestei biblioteci: scurgeri de memorie . Aplicațiile Android sunt predispuse la acestea, mai ales dacă nu ești atent la codificare. De fapt, crearea scurgerilor de memorie este foarte simplă. Tot ce trebuie să faceți este să stocați o referință de activitate în afara contextului său. De fapt, chiar și stocarea unei referințe la un singur obiect de vizualizare în afara contextului activității sale va crea o scurgere.

De ce? Pentru că o vizualizare - toate vizualizările, de fapt - stochează intern o referință de context la activitatea care o conține. Atâta timp cât se păstrează o referință la vizualizare, activitatea care o conține, împreună cu ceea ce se află în ea, inclusiv desenabile, ierarhia vizualizării și resurse, nu poate fi revendicată de colectorul de gunoi.

Păstrarea unei referințe la o activitate cu scurgeri nu este întotdeauna evidentă ca parametru static. Ori de câte ori creați o clasă interioară sau creați un fir în interiorul unei activități, va fi creată o referință la acea activitate și este posibil ca activitatea să nu fie revendicată până când acea clasă interioară sau firul respectiv nu sunt finalizate.

Scurgerea unei referințe la o singură activitate consumatoare de resurse este uneori suficientă pentru a vă bloca aplicația cu o excepție „ Memorie lipsită ”.

Cum te poți proteja împotriva lor? Începeți cu practici riguroase de codare , desigur. Dar nu toți suntem dezvoltatori Android experimentați și chiar și dezvoltatorii experimentați uită uneori regulile.

Evaluările periodice ale codului, cu accent pe scurgerile de memorie, pot fi utile, dar necesită timp. De asemenea, unele scurgeri sunt cu adevărat ascunse și greu de detectat prin simpla revizuire a codului.

Utilizarea instrumentului de memorie al DDMS este o modalitate excelentă de a ști, în timp, dacă aplicația dvs. are scurgeri. Cu siguranță ar trebui să-l folosești. Cu toate acestea, nu vă va spune ce cauzează scurgerea.

Aici vine leakCanary la salvare. Este cel mai bun detector de scurgeri de memorie care există și asigură detectarea automată a scurgerilor pentru toate activitățile dvs., ca în una sau două linii de cod.

Pentru a-l folosi, pur și simplu inițializați leakCanary cu obiectul aplicației dvs. onCreate() :

 public class MyApp extends Application { @Override public void onCreate() { super.onCreate(); LeakCanary.install(this); // more initialisations } }

Și ai terminat. LeakCanary va monitoriza scurgerile de memorie și va trimite o notificare dacă detectează una.

LeakCanary realizează această magie prin injectarea automată a unui obiect numit ActivityRefWatcher în toate activitățile tale și monitorizarea numărului lor de referințe după ce a fost apelat onDestroy() . Un număr de ref > 0 pentru o activitate distrusă poate însemna doar o scurgere.

Important: Detectarea scurgerilor funcționează numai pentru aplicațiile în modul de depanare. Nu testați niciodată pentru scurgeri (ei bine, nu cu LeakCanary) într-un mod de lansare APK.

Dar dacă vreau să testez alte părți ale sistemului meu pentru scurgeri? Aici, LeakCanary oferă un obiect numit refWatcher, care este de fapt valoarea returnată a apelului de inițializare:

 refWatcher = LeakCanary.install(this);

Poate fi folosit pentru a urmări valorile care urmează să fie recuperate în curând. Mai exact, valori care cred că urmează să fie recuperate în curând. Pentru a face asta, sunați la:

 refWatcher.watch(my_soon_to_be_reclaimed_obj);

Biblioteca vă va anunța dacă acest obiect nu a fost eliberat la scurt timp după apelul de urmărire.

Nu am putut găsi nicăieri valoarea acestui „timp scurt”, dar probabil că nu este atât de important. Cu leakCanary, lucrurile merg pur și simplu. Neprețuit.

rezumat

Dezvoltatorii cu experiență reduc zile și săptămâni din fazele de codare și depanare folosind aceste biblioteci, așa că nu există niciun motiv pentru care să nu faci același lucru.

Pentru a rezuma, iată ce poate face selecția mea de biblioteci Android pentru tine:

• ButterKnife – Codul auto-injectat vă va ajuta să eliminați o mare parte din codul standard al aplicației dvs. Este cea mai bună injecție de cod pentru Android. Trebuie să spun mai multe?

• AndroidAnnotations – Folosiți clase super-rapide generate automat și injecția de cod pe bază de nume pentru a economisi timp fără penalizări de performanță față de logica codificată manual.

• EventBus – Decuplați componentele pentru un cod mai robust, comunicarea între componente nu a fost niciodată mai simplă.

• OkHttp – Un înlocuitor inteligent pentru HttpURLConnection, cu suport pentru rețele asincrone, cerere de interogare de rută de redirecționare, interogare cache locală și multe altele.

• Picasso – Manipulare simplificată a imaginii, atât de bună încât este folosită acum de Google. Este o economie majoră de timp în proiectele media grele și în anumite proiecte vechi.

• ActiveAndroid – ORM simplificat, fără suprasolicitare a performanței.

• LibStreaming – Streaming video în timp real, utilizat de aplicațiile de streaming majore.

Sunt acestea singurele biblioteci Android care merită timpul tău? Cu siguranta nu. Dar îți promit asta: folosirea oricăruia dintre ele în următorul tău proiect te va face un dezvoltator mult mai bun. Dacă doriți să le vedeți în acțiune, aruncați o privire pe GitHub-ul meu.

Dacă le utilizați deja pe unele sau pe toate, sau dacă utilizați biblioteci alternative, vă îndemn să împărtășiți experiențele voastre în comentariile de mai jos.