Zbyt dokładny przewodnik po niedostatecznie używanych bibliotekach Androida

Każdy doświadczony programista powie Ci, że jego najlepszym kodem nie jest kod, który napisali. To kod, który wzięli z czyjejś pracy.

Tak, my, programiści, innowacyjnie rozwiązujemy problemy, ale wiele z napotykanych przez nas problemów zostało już rozwiązanych — a środki zaradcze umieszczone w bibliotekach dostępnych dla każdego. Po co wymyślać koło na nowo, skoro wolne koła są wszędzie?

Android nie jest wyjątkiem. Ostatecznym źródłem ponownego wykorzystania kodu jest sam Android SDK, który zawiera świetne konstrukcje i usługi, które wykonają za Ciebie dużo pracy.

Ale tam, gdzie brakuje SDK, społeczność Androida stworzyła kilka najlepszych bibliotek, które mogą zaoszczędzić mnóstwo pracy nad kodowaniem, zastępując je wysoce dostrojonymi, sprawdzonymi i przetestowanymi implementacjami. Nie mówię o oczywistych bibliotekach — Bibliotece obsługi Androida, Bibliotece obsługi Android Design, Gson. Mam na myśli narzędzia, o których możesz nie wiedzieć. A nawet jeśli to zrobisz, prawdopodobnie jeszcze ich nie używasz.

Od lat rozwijam, mentoruję i kieruję zespołami Androida, studiowałem i korzystałem z dziesiątek zewnętrznych narzędzi i bibliotek. (Zdarzyło mi się nawet czytać ich kod implementacji i omawiać ich elementy wewnętrzne z programistą). Wielu z nich bardzo skutecznie pomagało mi w wykonaniu zadania, ale prawda jest taka, że ​​większość nie.

Dlatego przygotowałem ten przewodnik. Oprzyj się na moim doświadczeniu, a także doświadczeniach innych programistów mobilnych, aby upewnić się, że korzystasz z najlepszych bibliotek. Wybrałem siedem. Podejrzewam, że wkrótce staną się jednymi z twoich ulubionych.

Wybór odpowiedniej biblioteki Android

Wybierając bibliotekę, zwracam uwagę na cztery kluczowe cechy:

• Zapewnia spójne i wysokiej jakości rozwiązanie rzeczywistego i nietrywialnego problemu.
• Używa tak prostego interfejsu API, jak to tylko możliwe.
• Nie wymusza żadnych zmian w mojej ogólnej architekturze.
• Ma dużą bazę użytkowników i, najlepiej, aktywną społeczność programistów.

Pierwsze trzy funkcje to łamacze umów. Jeśli ich nie ma, idę dalej lub zaczynam ręcznie kodować.

Biblioteki, które omawiam poniżej, przechodzą wszystkie cztery testy. Rozwiązują również niektóre z najtrudniejszych aspektów programowania mobilnego.

• Dwie biblioteki do wstrzykiwania zależności, wiązania layout-to-Java, makiety obiektów.
• Model przesyłania wiadomości typu pub/sub w aplikacji.
• Bezpieczna, wydajna, samonaprawiająca się warstwa komunikacji HTTP.
• Manipulacja obrazem: pobieranie, buforowanie, zmiana rozmiaru i ładowanie do pamięci RAM.
• Strumieniowe przesyłanie wideo w czasie rzeczywistym.
• Wykrywanie wycieku pamięci.

ButterKnife: najlepsze narzędzie do wstrzykiwania zależności

Jest to ostateczna biblioteka do wstrzykiwania zależności dla systemu Android. Prosty, solidny, superszybki (bez refleksji!) i zdolny do pozbycia się wielu standardowych kodów Twojej aplikacji.

Zniknęła potrzeba bezpośredniego wiązania każdego z widoków za pomocą wywołania findViewById() ; zamiast tego dostępny jest widok z adnotacjami, który zapewnia bezpośredni dostęp do kodu. ButterKnife eliminuje również potrzebę tworzenia szablonowych zdarzeń interfejsu użytkownika, takich jak onClick , onTouch itd., i zastępuje je kodem wstrzykiwanym automatycznie.

Ale dość pogawędki, zobaczmy kod.

Zobacz powiązanie pola:

 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”); } }

Powiązanie zasobów:

 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() }

Wiązanie zdarzeń interfejsu użytkownika:

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

AndroidAnnotations: wstrzykiwanie zależności na wyższy poziom

Podobnie jak ButterKnife, jeśli chodzi o wstrzykiwanie zależności, AndroidAnnotations stosuje nieco inne podejście: automatycznie generowane klasy, które, gdy już je opanujesz, są niezwykle proste. Jeszcze bardziej przydatne jest to, że umożliwia wstrzykiwanie zależności oparte na nazwie. Na przykład @ViewById ListView myUserList; instruuje bibliotekę, aby przypisać to pole z layoutListView o tej samej nazwie.

AndroidAnnotations również działa błyskawicznie, ale osiąga to w nieco inny sposób niż ButterKnife. Zamiast wstrzykiwania zależności powiązania środowiska uruchomieniowego, AndroidAnnotations tworzy duplikację czasu kompilacji wszystkich działań, których to dotyczy, i wypycha do nich swoją logikę połączenia, dzięki czemu można uzyskać taką samą wydajność, jak w przypadku logiki kodowanej ręcznie.

Ale możliwości wstrzykiwania AndroidAnnotations idą jeszcze dalej. Do działania można wprowadzić zarówno stan, jak i układ.

Implementacja AndroidAnnotations:

 @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 } }

Ostatnia adnotacja wymaga nieco więcej wyjaśnień: Typowym zadaniem dla wielowątkowej aplikacji na Androida jest przełączanie z wątków działających w tle (lub roboczych) do wątku przekazującego (lub głównego lub UI), który jako jedyny umożliwia dostęp do komponentów interfejsu użytkownika . To zadanie, choć nie jest skomplikowane, jest często wymagane i wiąże się z niechlujnym kodowaniem:

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

W AndroidAnnotations wszystko, co musisz zrobić, to dodać adnotację do swojej funkcji za pomocą @UiThread, a teraz gwarantujemy, że będzie ona zawsze wykonywana:

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

Pamiętaj, że ta adnotacja dotyczy standardowych klas składników systemu Android (działań, usług itd.). Ale co się stanie, gdy chcę dodać adnotacje do własnych klas?

Tutaj AndroidAnnotations przedstawia nową koncepcję, czyli EBean . Wszystko, co musisz zrobić, to oznaczyć swoją klasę jako taką za pomocą @EBean , i gotowe:

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

EventBus: łatwa komunikacja między komponentami

Biblioteka EventBus zamienia problem, który od lat nawiedza programistów Androida, w spacer po parku. Komunikacja między komponentami nigdy nie była prostsza — użyj prostego modelu pub/sub do komunikacji między dowolnymi dwoma częściami systemu.

Twoja usługa sondowania w tle nie musi już być świadoma twoich fragmentów, aby zasilać je zdarzeniami zmian.

Użycie EventBus jest proste.

a. Twórz klasy wydarzeń. Najlepiej pracować z POJO:

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

b. Utwórz metody obsługi zdarzeń w klasie — w dowolnej klasie, którą chcesz subskrybować dla tych zdarzeń:

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

Ale hej, każdy niedoświadczony programista Androida zatrzymałby się i zapytał w tym momencie: Jaki jest model wątków tych programów obsługi? I czy mogę zmusić program obsługi do uruchomienia głównego wątku, jeśli, powiedzmy, wiąże się to z dostępem do komponentów interfejsu użytkownika? Dobre pytanie…

Domyślnie wszystkie metody obsługi są uruchamiane w wątku roboczym pobranym z puli wątków, która jest przydzielona i utrzymywana przez samą EventBus. Jeśli potrzebujesz metody obsługi do uruchomienia w głównym wątku, rozwiń adnotacje subskrypcji w następujący sposób:

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

Ostrzeżenie: nie nadużywaj tej funkcji! Długotrwałe operacje nigdy nie powinny być wykonywane na głównym wątku , a nawet przy szybkich operacjach należy zachować ostrożność. Przytłaczanie głównego wątku to najpewniejszy sposób, aby Twoja aplikacja była powolna, niestabilna i zasadniczo mniej przyjemna dla użytkowników.

C. Zarządzaj cyklem życia rejestracji EventBus swojej klasy subskrybenta — to znaczy, kiedy łączy się, a kiedy rozłącza się z autobusem? Rozsądny przepływ rejestracji dla działania to:

 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(); } }

Powyższe jest oczywiście tylko przykładem. Możesz dokonać (wyrejestrowania) rejestracji w dowolnym miejscu.

D. I na koniec faktycznie odpal wydarzenie:

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

Jest o wiele więcej, aby wiedzieć o używaniu EventBus: zdarzenia multiemisji (zachowanie domyślne), używanie lepkich zdarzeń, wątków dostarczania, priorytetów i innych. Ale powyższe wystarczy, aby zacząć korzystać z tej prostej, ale potężnej technologii.

OkHttp: HttpClient Androida na sterydach

W ten sposób powinien zostać napisany HttpClient systemu Android. Bardzo prosty, bardzo inteligentny. Biblioteka OkHttp wewnętrznie zajmuje się pętlą ponawiania prób, automatyczną kompresją ładunku, obsługą protokołu HTTP/2, buforowaniem połączeń i buforowaniem odpowiedzi, dzięki czemu można uniknąć niepotrzebnego dostępu do sieci.

Użycie OkHttp jest oczywiste.

POST HTTP:

 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 POBIERZ:

 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 obsługuje również takie przydatne funkcje, jak sieć asynchroniczna, zapytanie o przekierowanie żądania trasy, zapytanie o lokalną pamięć podręczną i inne. Zapraszam do korzystania z nich tam, gdzie jest to potrzebne. Większość programistów używa OkHttp jako inteligentniejszego zamiennika domyślnego klienta HTTP Androida, HttpURLConnection. W rzeczywistości cały ten projekt rozpoczął się jako prywatny fork dla HttpURLConnection.

Uwielbiam jego niezawodność — natychmiast dodaje się do warstwy sieciowej.

Picasso: jest dobry powód, dla którego Google też go używa!

Picasso to najprostszy i najbardziej niezawodny sposób zarządzania pobieraniem obrazów, buforowaniem, zmianą rozmiaru i przycinaniem.

To oświadczenie:

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

Zrobi to za Ciebie:

• Połącz się ze zdalnym adresem URL.
• Pobierz obraz.
• Przechowuj go w lokalnej pamięci podręcznej LRU, którą będzie również dla Ciebie zarządzać.
• Zmień rozmiar oryginalnego obrazu przed załadowaniem go do pamięci.
• Uruchom wszystkie powyższe w puli wątków zarządzanej przez Picassa.
• Użyj zmienionego obrazu, aby wypełnić swój imageView.
• Przed jakimikolwiek przyszłymi uruchomieniami sprawdź lokalną pamięć podręczną, aby upewnić się, że podróż w obie strony jest naprawdę konieczna.

Zbudowanie powyższego zestawu zadań wymagałoby wielu godzin pracy, nawet dla głównego programisty. A to zakłada, że ​​wszystko zapamiętałeś. A jeśli zapomnisz, powiedzmy, części do zmiany rozmiaru?

Cóż, na przeciętnym urządzeniu z Androidem aplikacja pobiera nie więcej niż 50 do 60 megabajtów pamięci RAM, a współczynnik liczby pikseli do bajtów dla większości urządzeń z Androidem wynosi 4. Oznacza to próbę załadowania 13-megapikselowego obrazu z karty SD wymagałoby 52 megabajtów pamięci RAM. Innymi słowy, Twoja aplikacja natychmiast uległaby awarii.

To tylko jeden przykład siły Picassa. Jedną z pierwszych rzeczy, które robię podczas optymalizacji/debugowania starszego projektu wymagającego dużej ilości mediów, jest przełączenie całego ładowania obrazów na Picassa. Zdziwiłbyś się, jak ten jeden prosty krok ma wpływ na jakość aplikacji.

Jeden z najsilniejszych świadectw potęgi tej biblioteki: wiele własnych próbek kodu Androida Google z ostatnich dwóch lat wykorzystuje Picassa do ładowania obrazów.

ActiveAndroid: Narzut na wydajność ORM Sans

ORM, skrót od mapowania relacyjnego obiektowego, stał się popularny w czasach J2EE. Umożliwia przechowywanie POJO w bazie danych i pobieranie ich z niej bez konieczności przekształcania ich w osobne pola.

Czy to jest pomocne? W dużym stopniu, ponieważ pozwala na napisanie dużej części aplikacji bez kodowania jakichkolwiek instrukcji SQL.

Jest również bardzo wydajny. W dawnych czasach platformy ORM w dużej mierze opierały się na refleksji i były znane z powolności. Nowoczesne platformy, w tym ActiveAndroid, są znacznie szybsze i w przypadku większości praktycznych wymagań nie ucierpią z powodu narzutów wydajnościowych w porównaniu z surowym kodowaniem SQL.

Stosowanie:

a. Zainicjuj w obiekcie aplikacji, rozszerzając niestandardową klasę Application:

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

b. Utwórz POJO, wyprowadzone dla klasy modelu, z klasami dla każdego rekordu, który planujesz przechowywać w bazie danych. Każde takie POJO może znajdować się we własnym stole. Adnotacje powinny być używane do określenia nazwy pól bazy danych dla każdego przechowywanego elementu:

 @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; }

Jeśli chcesz ustawić indeks dla członka, użyj następującej adnotacji:

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

C. Aby zapobiec iteracji biblioteki przez cały najdłuższy czas uruchamiania, co jest zachowaniem domyślnym, zdecydowanie zaleca się określenie wszystkich klas modeli w następującej sekcji manifestu:

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

Uwaga: Klasy modeli, których nie ma na tej liście, nie będą rozpoznawane przez ActiveAndroid.

D. Napisz do bazy danych:

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

Jeśli potrzeba wielu zapisów, bardziej wydajnym sposobem byłoby zgrupowanie ich w jednej transakcji:

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

mi. Wczytaj POJO z bazy danych:

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

ORM był niezbędnym narzędziem w moich czasach jako programista po stronie serwera. Miał nieco późne wejście do domeny Androida. Ale w końcu to jest: programowanie baz danych tak proste, jak to tylko możliwe. Ciesz się tym.

LibStreaming: bezbolesne przesyłanie strumieniowe wideo

Strumieniowe przesyłanie wideo w czasie rzeczywistym było kiedyś dużym problemem z powodu nieudokumentowanych interfejsów API, różnic między wersjami zestawu SDK, użycia odbić i nie tylko.

Na szczęście libStreaming zmienił to wszystko, obejmując większość złożoności przesyłania strumieniowego i udostępniając prosty i przyjazny interfejs API, który pozwala napisać podstawową aplikację do przesyłania strumieniowego w ciągu kilku godzin.

Aby użyć go dla H.264 i AAC, musisz wykonać następujące czynności:

a. Zainicjuj obiekt sesji w metodzie onCreate głównej aktywności. Obiekty sesji reprezentują strumieniowe przesyłanie multimediów do peera:

 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. Właściwie rozpocznij sesję:

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

C. Po zakończeniu zatrzymaj sesję:

 mSession.stop();

Proszę, nie zrozum źle. Przesyłanie strumieniowe w czasie rzeczywistym jest z natury kłopotliwe, a libStreaming nie eliminuje tej złożoności. Jednak przez większość czasu ukrywa to przed tobą naprawdę dobrą robotę. W niektórych przypadkach będziesz musiał poradzić sobie ze złożonością, na przykład przy wyborze polityki sygnalizacji równorzędnej, wyborze kodowania kamery (zazwyczaj chcesz użyć MediaCodec/surface-to-buffer) lub radzenia sobie z pakietowaniem.

Mimo to przekonasz się, że dobrzy ludzie stojący za libStreaming poszli o krok dalej, płynnie łącząc te zawiłości w prosty w użyciu interfejs API.

LibStreaming obsługuje większość koderów używanych przez aplikacje na Androida, w tym H.264, H.263, AAC i AMR.

Osiągnąłem wspaniałe wyniki dzięki tej bibliotece. Kilka najpopularniejszych aplikacji do przesyłania strumieniowego używa go jako części swojej infrastruktury. Jeśli kiedykolwiek napotkasz taką potrzebę, jestem pewien, że dzięki temu strumieniowanie multimediów będzie znacznie płynniejsze.

LeakCanary: wykrywaj wycieki pamięci w wierszu kodu

Zacznijmy od motywacji tej biblioteki: wycieki pamięci . Aplikacje na Androida są na nie podatne, zwłaszcza jeśli nie dbasz o kodowanie. W rzeczywistości tworzenie wycieków pamięci jest bardzo proste. Wszystko, co musisz zrobić, to przechowywać odwołanie do działania poza jego kontekstem. W rzeczywistości nawet przechowywanie odwołania do pojedynczego obiektu widoku poza kontekstem jego aktywności spowoduje wyciek.

Czemu? Ponieważ widok — w rzeczywistości wszystkie widoki — przechowują wewnętrznie odniesienie kontekstu do jego aktywności. Dopóki zachowane jest odwołanie do widoku, jego aktywność zawierająca — wraz z tym, co znajduje się w jego wnętrzu, w tym elementy do rysowania, hierarchia widoków i zasoby — nie może zostać odzyskana przez moduł odśmiecania pamięci.

Zachowanie odniesienia do wycieku działalności nie zawsze jest oczywiste jako parametr statyczny. Za każdym razem, gdy tworzysz klasę wewnętrzną lub tworzysz wątek wewnątrz działania, zostanie utworzone odwołanie do tej aktywności, a aktywność nie może zostać odzyskana, dopóki ta klasa wewnętrzna lub wątek nie zostaną zakończone.

Wyciek odniesienia do pojedynczej czynności wymagającej dużej ilości zasobów może czasami spowodować awarię aplikacji z powodu wyjątku „ Brak pamięci ”.

Jak możesz się przed nimi chronić? Oczywiście zacznij od rygorystycznych praktyk kodowania . Ale nie wszyscy z nas są doświadczonymi programistami Androida, a nawet doświadczeni programiści czasami zapominają o zasadach.

Okresowe przeglądy kodu z naciskiem na wycieki pamięci mogą być pomocne, ale wymagają czasu. Ponadto niektóre przecieki są naprawdę podstępne i trudne do wykrycia przez samo sprawdzenie kodu.

Korzystanie z narzędzia pamięci DDMS to świetny sposób, aby z czasem dowiedzieć się, czy aplikacja przecieka. Zdecydowanie powinieneś go używać. Jednak nie powie Ci, co powoduje wyciek.

Na ratunek przychodzi przeciekCanary. Jest to najlepszy na rynku wykrywacz wycieków pamięci, który zapewnia automatyczne wykrywanie wycieków dla wszystkich Twoich działań — tak jak w przypadku jednej lub dwóch linii kodu.

Aby go użyć, po prostu zainicjuj leakCanary za pomocą obiektu onCreate() Twojej aplikacji:

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

I jesteś skończony. LeakCanary będzie monitorować wycieki pamięci i wyśle ​​powiadomienie, jeśli je wykryje.

LeakCanary osiąga tę magię, automatycznie wstrzykując obiekt o nazwie ActivityRefWatcher do wszystkich twoich działań i monitorując ich liczbę ref po onDestroy() . Liczba ref > 0 na zniszczonej aktywności może oznaczać tylko wyciek.

Ważne: Wykrywanie nieszczelności działa tylko w przypadku aplikacji w trybie debugowania. Nigdy nie testuj pod kątem wycieków (no cóż, nie z LeakCanary) w pakiecie APK w trybie wydania.

Ale co, jeśli chcę przetestować inne części mojego systemu pod kątem wycieków? Tutaj LeakCanary oferuje obiekt o nazwie refWatcher, który w rzeczywistości jest wartością zwracaną przez wywołanie inicjujące:

 refWatcher = LeakCanary.install(this);

Może służyć do obserwowania wartości, które wkrótce zostaną odzyskane. Dokładniej, wartości, o których myślę, że wkrótce zostaną odzyskane. W tym celu zadzwoń:

 refWatcher.watch(my_soon_to_be_reclaimed_obj);

Biblioteka poinformuje Cię, czy ten obiekt nie został zwolniony wkrótce po wywołaniu watch.

Nigdzie nie mogłem znaleźć wartości tego „krótkiego czasu”, ale to chyba nie jest aż tak ważne. Z leakCanary wszystko po prostu działa. Bezcenny.

Streszczenie

Doświadczeni programiści skracają dni i tygodnie na fazy kodowania i debugowania, korzystając z tych bibliotek, więc nie ma powodu, dla którego nie możesz zrobić tego samego.

Podsumowując, oto co mój wybór bibliotek Androida może dla Ciebie zrobić:

• ButterKnife — kod wstrzykiwany automatycznie pomoże Ci pozbyć się większości standardowych kodów Twojej aplikacji. To ostateczny wstrzyknięcie kodu dla Androida. Czy muszę powiedzieć więcej?

• AndroidAnnotations — używaj niesamowicie szybkich, automatycznie generowanych klas i wstrzykiwania kodu opartego na nazwach, aby zaoszczędzić czas bez spadku wydajności w porównaniu z ręcznie kodowaną logiką.

• EventBus — Odłącz komponenty dla bardziej niezawodnego kodu, komunikacja między komponentami nigdy nie była prostsza.

• OkHttp — sprytny zamiennik HttpURLConnection, z obsługą sieci asynchronicznych, zapytań o przekierowanie żądań, zapytań o lokalną pamięć podręczną i nie tylko.

• Picasso – Usprawniona manipulacja obrazami, która jest tak dobra, że ​​jest teraz używana przez Google. Jest to duża oszczędność czasu w przypadku ciężkich projektów medialnych i niektórych starszych projektów.

• ActiveAndroid — łatwe ORM bez narzutów na wydajność.

• LibStreaming — przesyłanie strumieniowe wideo w czasie rzeczywistym, używane przez główne aplikacje do przesyłania strumieniowego.

Czy to jedyne biblioteki Androida warte twojego czasu? Zdecydowanie nie. Ale obiecuję ci to: użycie któregokolwiek z nich w następnym projekcie sprawi, że będziesz znacznie lepszym programistą. Jeśli chcesz zobaczyć je w akcji, zajrzyj na mój GitHub.

Jeśli korzystasz już z niektórych lub wszystkich z nich lub korzystasz z alternatywnych bibliotek, zachęcam do podzielenia się swoimi doświadczeniami w komentarzach poniżej.