Ein allzu gründlicher Leitfaden für zu wenig genutzte Android-Bibliotheken

Jeder erfahrene Entwickler wird Ihnen sagen, dass sein bester Code nicht der ist, den er selbst geschrieben hat. Es ist Code, den sie aus der Arbeit von jemand anderem genommen haben.

Ja, wir Entwickler sind innovative Problemlöser, aber viele der Probleme, auf die wir stoßen, wurden bereits gelöst – und die Abhilfemaßnahmen in Bibliotheken verpackt, die für jedermann verfügbar sind. Warum das Rad neu erfinden, wenn Freiläufe überall sind?

Android ist keine Ausnahme. Die ultimative Quelle für die Wiederverwendung von Code ist das Android SDK selbst, das mit großartigen Konstrukten und Diensten geliefert wird, die einen Großteil Ihrer Arbeit für Sie erledigen.

Aber wo das SDK knapp wird, hat die Android-Community einige erstklassige Bibliotheken erstellt, die Ihnen Tonnen von Programmierarbeit ersparen können, indem sie sie durch hochgradig abgestimmte, geprüfte und getestete Implementierungen ersetzen. Ich spreche nicht von den offensichtlichen Bibliotheken – Android Support Library, Android Design Support Library, Gson. Ich beziehe mich auf Tools, die Sie vielleicht nicht kennen. Und selbst wenn Sie dies tun, verwenden Sie sie wahrscheinlich noch nicht.

Ich entwickle, betreue und leite seit Jahren Android-Teams und habe Dutzende von externen Tools und Bibliotheken studiert und verwendet. (Ich bin sogar dafür bekannt, ihren Implementierungscode zu lesen und ihre Interna mit dem Entwickler zu besprechen.) Viele haben mir sehr effektiv dabei geholfen, die Arbeit zu erledigen, aber die Wahrheit ist, dass die meisten es nicht waren.

Deshalb habe ich diesen Ratgeber zusammengestellt. Verlassen Sie sich auf meine Erfahrung und die anderer mobiler Entwickler, um sicherzustellen, dass Sie die besten Bibliotheken verwenden. Ich habe sieben ausgewählt. Ich vermute, dass sie auch sehr bald zu Ihren Favoriten gehören werden.

Auswahl der richtigen Android-Bibliothek

Bei der Auswahl einer Bibliothek achte ich auf vier Hauptmerkmale:

• Es bietet eine konsistente und qualitativ hochwertige Lösung für ein echtes und nicht triviales Problem.
• Es verwendet eine möglichst einfache API.
• Es erzwingt keine Änderungen in meiner Gesamtarchitektur.
• Es hat eine große Benutzerbasis und vorzugsweise eine aktive Entwicklergemeinschaft.

Die ersten drei Funktionen sind Deal-Breaker. Wenn sie nicht anwesend sind, gehe ich weiter oder beginne mit der Handcodierung.

Die Bibliotheken, die ich unten behandle, bestehen alle vier Tests. Sie lösen auch einige der schwierigsten Aspekte der mobilen Entwicklung.

• Zwei Bibliotheken für Abhängigkeitsinjektion, Layout-zu-Java-Bindung, Scheinobjekte.
• In-App-Pub/Sub-Messaging-Modell.
• Sichere, effiziente, sich selbst wiederherstellende HTTP-Kommunikationsschicht.
• Bildbearbeitung: Herunterladen, Caching, Größenänderung und Laden in den Arbeitsspeicher.
• Video-Streaming in Echtzeit.
• Erkennung von Speicherlecks.

ButterKnife: Das ultimative Tool zur Abhängigkeitsinjektion

Dies ist die ultimative Dependency-Injection-Bibliothek für Android. Einfach, robust, superschnell (keine Reflexion!) und in der Lage, einen Großteil des Boilerplate-Codes Ihrer App zu beseitigen.

Vorbei ist die Notwendigkeit, jede Ihrer Ansichten direkt über einen Aufruf von findViewById() zu binden; Stattdessen gibt es eine kommentierte Ansicht, die Ihnen direkten Zugriff auf den Code ermöglicht. ButterKnife macht auch Boilerplate-UI-Ereignisse wie onClick , onTouch usw. überflüssig und ersetzt sie durch automatisch eingefügten Code.

Aber genug geplaudert, sehen wir uns den Code an.

Feldbindung anzeigen:

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

Ressourcenbindung:

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

UI-Ereignisbindung:

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

AndroidAnnotations: Dependency Injection auf die nächste Stufe bringen

AndroidAnnotations ist dicht hinter ButterKnife, wenn es um Abhängigkeitsinjektion geht, und verwendet einen etwas anderen Ansatz: automatisch generierte Klassen, die, sobald Sie den Dreh raus haben, extrem einfach sind. Noch nützlicher ist, dass es Ihnen eine „namensbasierte“ Abhängigkeitsinjektion ermöglicht. Beispiel: @ViewById ListView myUserList; weist die Bibliothek an, diesem Feld eine layoutListView zuzuweisen.

AndroidAnnotations ist ebenfalls blitzschnell, erreicht dies jedoch auf etwas andere Weise als ButterKnife. Anstelle der Laufzeitbindungs-Abhängigkeitsinjektion erstellt AndroidAnnotations eine Build-Time-Duplizierung aller betroffenen Aktivitäten und schiebt seine Verbindungslogik in sie hinein, sodass Sie die gleiche Leistung erzielen wie mit handcodierter Logik.

Die Injektionsfunktionen von AndroidAnnotations gehen jedoch noch weiter. Sie können sowohl Status als auch Layout in eine Aktivität einfügen.

AndroidAnnotations-Implementierung:

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

Die letzte Anmerkung erfordert etwas mehr Erklärung: Eine häufige Aufgabe für eine Android-App mit mehreren Threads ist das Wechseln von Hintergrund- (oder Worker-) Threads zum Vorwärts- (oder Haupt- oder UI-) Thread, der der einzige ist, der Zugriff auf UI-Komponenten ermöglicht . Diese Aufgabe ist zwar nicht komplex, aber oft erforderlich und beinhaltet einige unordentliche Codierung:

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

In AndroidAnnotations müssen Sie Ihre Funktion lediglich mit @UiThread kommentieren, und sie wird jetzt garantiert immer ausgeführt:

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

Beachten Sie, dass diese Anmerkung für standardmäßige Android-Komponentenklassen (Aktivitäten, Dienste usw.) gilt. Aber was passiert, wenn ich auch meine eigenen Klassen annotieren möchte?

Hier wartet AndroidAnnotations mit einem neuen Konzept auf, dem der EBean . Alles, was Sie tun müssen, ist, Ihre Klasse mit @EBean als solche zu markieren, und Sie können loslegen:

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

EventBus: Komponentenübergreifende Kommunikation leicht gemacht

Die EventBus-Bibliothek verwandelt ein Problem, das Android-Entwickler seit Jahren verfolgt, in einen Spaziergang im Park. Die komponentenübergreifende Kommunikation war noch nie einfacher – verwenden Sie ein einfaches Pub/Sub-Modell, um zwischen zwei beliebigen Teilen Ihres Systems zu kommunizieren.

Ihr Hintergrundabfragedienst muss Ihre Fragmente nicht mehr kennen, um sie mit Änderungsereignissen zu füttern.

Die Verwendung von EventBus ist unkompliziert.

A. Ereignisklassen erstellen. Arbeiten mit POJOs hier ist am besten:

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

B. Erstellen Sie Ereignisbehandlungsmethoden in der Klasse – jeder Klasse, die Sie für diese Ereignisse abonnieren möchten:

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

Aber hey, jeder halbwegs erfahrene Android-Entwickler würde an dieser Stelle aufhören und fragen: Was ist das Threading-Modell dieser Handler? Und kann ich einen Handler zwingen, den Haupt-Thread zu verlassen, wenn es beispielsweise um den Zugriff auf UI-Komponenten geht? Gute Frage…

Standardmäßig werden alle Handler-Methoden auf einem Worker-Thread ausgeführt, der aus einem Thread-Pool stammt, der von EventBus selbst zugewiesen und verwaltet wird. Wenn Sie eine Handler-Methode benötigen, die im Hauptthread ausgeführt werden soll, erweitern Sie Ihre Abonnementanmerkungen wie folgt:

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

Warnung: Überbeanspruchen Sie diese Funktion nicht! Lang andauernde Operationen sollten niemals im Haupt-Thread ausgeführt werden , und seien Sie auch bei schnellen Operationen vorsichtig. Die Überlastung des Hauptthreads ist der sicherste Weg, Ihre App langsam, sprunghaft und im Grunde weniger unterhaltsam für Ihre Benutzer zu machen.

C. Verwalten Sie den EventBus-Registrierungslebenszyklus Ihrer Abonnentenklasse – d. h. wann wird eine Verbindung zum Bus hergestellt und wann wird sie getrennt? Ein angemessener Registrierungsablauf für eine Aktivität wäre:

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

Das oben Gesagte ist natürlich nur ein Beispiel. Sie können die (Ab-)Registrierung an einem beliebigen Ort durchführen.

D. Und schließlich ein Ereignis auslösen:

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

Es gibt noch viel mehr über die Verwendung von EventBus zu wissen: Multicasting-Ereignisse (das Standardverhalten), Sticky-Ereignisse, Übermittlungsthreads, Prioritäten und mehr. Aber das Obige reicht aus, um mit dieser einfachen, aber leistungsstarken Technologie zu beginnen.

OkHttp: HttpClient von Android auf Steroiden

So hätte HttpClient von Android geschrieben werden sollen. Sehr einfach, sehr clever. Die OkHttp-Bibliothek kümmert sich intern um die Wiederholungsschleife, die automatische Komprimierung der Nutzdaten, die HTTP/2-Unterstützung, das Verbindungspooling und das Zwischenspeichern von Antworten, sodass Sie unnötigen Netzwerkzugriff vermeiden können.

Die Verwendung von OkHttp ist ein Kinderspiel.

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

 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 unterstützt auch solche nützlichen Funktionen wie asynchrones Netzwerken, Anfrageumleitungsroutenabfrage, lokale Cacheabfrage und mehr. Fühlen Sie sich frei, sie bei Bedarf zu verwenden. Die meisten Entwickler verwenden OkHttp als intelligenten Ersatz für den Standard-HTTP-Client von Android, HttpURLConnection. Tatsächlich begann dieses gesamte Projekt als privater Fork für HttpURLConnection.

Ich liebe seine Robustheit – es trägt sofort zu Ihrer Netzwerkschicht bei.

Picasso: Es gibt einen guten Grund, warum Google es auch verwendet!

Picasso ist die einfachste und robusteste Art, Bilder herunterzuladen, zwischenzuspeichern, die Größe zu ändern und zuzuschneiden.

Diese Aussage:

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

Wird dies für Sie tun:

• Verbinden Sie sich mit einer Remote-URL.
• Laden Sie ein Bild herunter.
• Speichern Sie es in einem lokalen LRU-Cache, den es auch für Sie verwaltet.
• Ändern Sie die Größe des Originalbilds, bevor Sie es in den Speicher laden.
• Führen Sie alle oben genannten Schritte in einem von Picasso verwalteten Thread-Pool aus.
• Verwenden Sie das in der Größe geänderte Bild, um Ihre imageView zu füllen.
• Überprüfen Sie vor zukünftigen Läufen den lokalen Cache, um sicherzustellen, dass ein Netzwerk-Roundtrip wirklich erforderlich ist.

Das Erstellen der oben genannten Aufgaben würde selbst für einen Master-Entwickler viele Arbeitsstunden erfordern. Und das setzt voraus, dass Sie sich an alles erinnern. Was ist, wenn Sie beispielsweise den Teil zur Größenänderung vergessen haben?

Nun, auf einem durchschnittlichen Android-Gerät erhält eine App nicht mehr als 50 bis 60 Megabyte RAM, und der Pixel-zu-Byte-Faktor für die meisten Android-Geräte beträgt 4. Dies bedeutet, dass versucht wird, ein 13-Megapixel-Bild von der SD-Karte zu laden würde 52 Megabyte RAM erfordern. Mit anderen Worten, Ihre App würde sofort abstürzen.

Dies ist nur ein Beispiel für die Stärke von Picasso. Eines der ersten Dinge, die ich beim Optimieren/Debuggen eines medienintensiven Legacy-Projekts tue, ist das Laden aller Bilder auf Picasso umzustellen. Sie werden überrascht sein, welche Auswirkungen dieser einfache Schritt auf die App-Qualität hat.

Einer der stärksten Beweise für die Leistungsfähigkeit dieser Bibliothek: Viele von Googles eigenen Android-Codebeispielen aus den letzten zwei Jahren verwenden Picasso zum Laden von Bildern.

ActiveAndroid: ORM ohne Leistungsaufwand

ORM, kurz für Object Relational Mapping, wurde in den Tagen von J2EE populär. Es ermöglicht Ihnen, Ihre POJOs in einer Datenbank zu speichern und daraus abzurufen, ohne sie in separate Felder umwandeln zu müssen.

Ist es hilfreich? Sehr sogar, da Sie damit einen großen Teil Ihrer App schreiben können, ohne eine SQL-Anweisung zu codieren.

Es ist auch sehr effizient. Früher waren ORM-Plattformen massiv auf Reflektion angewiesen und waren dafür berüchtigt, langsam zu sein. Moderne Plattformen, einschließlich ActiveAndroid, sind viel schneller und werden für die meisten praktischen Anforderungen nicht unter Leistungseinbußen gegenüber der reinen SQL-Codierung leiden.

Verwendungszweck:

A. Initialisieren Sie im Anwendungsobjekt, indem Sie eine benutzerdefinierte Anwendungsklasse erweitern:

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

B. Erstellen Sie POJO, abgeleitet für eine Modellklasse, mit Klassen für jeden der Datensätze, die Sie in der Datenbank speichern möchten. Jedes solche POJO kann sich in seiner eigenen Tabelle befinden. Anmerkungen sollten verwendet werden, um den Namen der DB-Felder für jedes gespeicherte Mitglied anzugeben:

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

Wenn Sie einen Index für ein Mitglied festlegen möchten, verwenden Sie die folgende Anmerkung:

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

C. Um zu verhindern, dass die Bibliothek über die gesamte nobelste Startzeit iteriert, was das Standardverhalten ist, wird dringend empfohlen, alle Ihre Modellklassen im folgenden Manifestabschnitt anzugeben:

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

Hinweis: Modellklassen, die nicht in dieser Liste erscheinen, werden von ActiveAndroid nicht erkannt.

D. In Datenbank schreiben:

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

Wenn mehrere Schreibvorgänge erforderlich sind, wäre es effizienter, sie in einer einzigen Transaktion zu bündeln:

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

e. POJOs aus Datenbank lesen:

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

ORM war während meiner Zeit als serverseitiger Entwickler ein unverzichtbares Tool. Es hatte einen etwas späten Eintritt in die Android-Domäne. Aber hier ist es endlich: Datenbankprogrammierung so einfach wie es nur geht. Geniesse es.

LibStreaming: Schmerzloses Video-Streaming

Früher war Echtzeit-Video-Streaming aufgrund nicht dokumentierter APIs, SDK-Versionsunterschiede, Reflection-Nutzung und mehr ein großes Problem.

Glücklicherweise hat libStreaming all dies geändert, indem es die meisten Streaming-Komplexitäten gekapselt und eine einfache und benutzerfreundliche API bereitgestellt hat, mit der Sie in wenigen Stunden eine grundlegende Streaming-App schreiben können.

Um es für H.264 und AAC zu verwenden, müssen Sie Folgendes tun:

A. Initialisieren Sie ein Sitzungsobjekt in der onCreate-Methode Ihrer Hauptaktivität. Sitzungsobjekte stellen Medienstreaming zu einem Peer dar:

 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. Starten Sie die Sitzung tatsächlich:

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

C. Halten Sie die Sitzung an, wenn Sie fertig sind:

 mSession.stop();

Jetzt bitte nicht falsch verstehen. Echtzeit-Streaming ist von Natur aus chaotisch und libStreaming nimmt diese Komplexität nicht weg. Es macht jedoch einen wirklich guten Job, es die meiste Zeit vor Ihnen zu verbergen. In einigen Fällen müssen Sie sich mit der Komplexität auseinandersetzen, z. B. bei der Auswahl der Peer-Signalisierungsrichtlinie, der Auswahl der Kameracodierung (normalerweise möchten Sie MediaCodec/Surface-to-Buffer verwenden) oder der Handhabung der Paketierung.

Dennoch werden Sie feststellen, dass die guten Jungs hinter libStreaming die Extrameile gegangen sind, um diese Komplexitäten reibungslos in einer einfach zu bedienenden API zusammenzuführen.

LibStreaming unterstützt die meisten von Android-Apps verwendeten Encoder, einschließlich H.264, H.263, AAC und AMR.

Ich habe großartige Ergebnisse mit dieser Bibliothek erzielt. Einige der beliebtesten Streaming-Apps verwenden es als Teil ihrer Infrastruktur. Wenn Sie jemals auf die Notwendigkeit stoßen, bin ich sicher, dass es Ihr Medien-Streaming-Erlebnis viel reibungsloser machen wird.

LeakCanary: Erkennen Sie Speicherlecks in einer Codezeile

Beginnen wir mit der Motivation hinter dieser Bibliothek: Speicherlecks . Android-Apps sind anfällig dafür, besonders wenn Sie mit Ihrer Codierung nicht vorsichtig sind. Tatsächlich ist das Erstellen von Speicherlecks sehr einfach. Alles, was Sie tun müssen, ist, eine Aktivitätsreferenz außerhalb ihres Kontexts zu speichern. Tatsächlich führt sogar das Speichern eines Verweises auf ein einzelnes Ansichtsobjekt außerhalb des Kontexts seiner Aktivität zu einem Leck.

Warum? Weil eine Ansicht – eigentlich alle Ansichten – intern eine Kontextreferenz zu ihrer enthaltenden Aktivität speichert. Solange ein Verweis auf die Ansicht beibehalten wird, kann die enthaltende Aktivität – zusammen mit dem, was darin enthalten ist, einschließlich Drawables, Ansichtshierarchie und Ressourcen – nicht vom Garbage Collector zurückgefordert werden.

Das Beibehalten eines Verweises auf eine Leaking-Aktivität ist als statischer Parameter nicht immer offensichtlich. Immer wenn Sie eine innere Klasse erstellen oder einen Thread innerhalb einer Aktivität erstellen, wird ein Verweis auf diese Aktivität erstellt und die Aktivität kann nicht zurückgefordert werden, bis diese innere Klasse oder dieser Thread abgeschlossen ist.

Das Durchsickern eines Verweises auf eine einzelne ressourcenintensive Aktivität reicht manchmal aus, um Ihre App mit der Ausnahme „ Nicht genügend Arbeitsspeicher “ zum Absturz zu bringen.

Wie kann man sich davor schützen? Beginnen Sie natürlich mit strengen Programmierpraktiken . Aber nicht alle von uns sind erfahrene Android-Entwickler, und selbst die erfahrenen Entwickler vergessen manchmal die Regeln.

Regelmäßige Codeüberprüfungen mit Schwerpunkt auf Speicherlecks können hilfreich sein, aber sie brauchen Zeit. Außerdem sind einige Lecks wirklich hinterhältig und durch bloße Codeüberprüfung schwer zu erkennen.

Die Verwendung des Speichertools von DDMS ist eine großartige Möglichkeit, im Laufe der Zeit festzustellen, ob Ihre App undicht ist. Du solltest es unbedingt nutzen. Es wird Ihnen jedoch nicht sagen, was das Leck verursacht.

Hier kommt LeakCanary zur Rettung. Es ist der beste Speicherleck-Detektor auf dem Markt und bietet eine automatische – wie in ein oder zwei Codezeilen – Leckerkennung für alle Ihre Aktivitäten.

Um es zu verwenden, initialisieren Sie einfach LeakCanary mit dem Objekt onCreate() Ihrer App:

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

Und du bist fertig. LeakCanary überwacht Speicherlecks und sendet eine Benachrichtigung, wenn es eines erkennt.

LeakCanary erreicht diese Magie, indem es automatisch ein Objekt namens ActivityRefWatcher in alle Ihre Aktivitäten einfügt und deren Ref-Zählung überwacht, nachdem onDestroy() aufgerufen wurde. Ein Ref-Count > 0 bei einer zerstörten Aktivität kann nur ein Leck bedeuten.

Wichtig: Die Leckerkennung funktioniert nur für Anwendungen im Debug-Modus. Testen Sie niemals auf Leaks (na ja, nicht mit LeakCanary) in einem Release-Modus-APK.

Aber was ist, wenn ich andere Teile meines Systems auf Lecks testen möchte? Hier bietet LeakCanary ein Objekt namens refWatcher an, das eigentlich der Rückgabewert des Initialisierungsaufrufs ist:

 refWatcher = LeakCanary.install(this);

Es kann verwendet werden, um Werte zu beobachten, die bald zurückgefordert werden. Genauer gesagt, Werte, von denen ich denke, dass sie bald zurückerobert werden. Rufen Sie dazu an:

 refWatcher.watch(my_soon_to_be_reclaimed_obj);

Die Bibliothek teilt Ihnen kurz nach dem Überwachungsaufruf mit, wenn dieses Objekt nicht freigegeben wurde.

Den Wert dieser „kurzen Zeit“ konnte ich nirgendwo finden, aber das ist wohl nicht so wichtig. Mit LeakCanary funktionieren die Dinge einfach. Unbezahlbar.

Zusammenfassung

Erfahrene Entwickler verkürzen Tage und Wochen ihrer Codierungs- und Debugging-Phasen mit diesen Bibliotheken, also gibt es keinen Grund, warum Sie nicht dasselbe tun können.

Zusammenfassend lässt sich sagen, was meine Auswahl an Android-Bibliotheken für Sie tun kann:

• ButterKnife – Automatisch eingefügter Code hilft Ihnen dabei, einen Großteil des Boilerplate-Codes Ihrer App zu beseitigen. Es ist die ultimative Code-Injektion für Android. Muss ich mehr sagen?

• AndroidAnnotations – Verwenden Sie blitzschnelle automatisch generierte Klassen und namensbasierte Code-Injection, um Zeit zu sparen, ohne dass die Leistung durch manuell codierte Logik beeinträchtigt wird.

• EventBus – Komponenten für robusteren Code entkoppeln, komponentenübergreifende Kommunikation war noch nie so einfach.

• OkHttp – Ein cleverer Ersatz für HttpURLConnection, mit Unterstützung für asynchrones Networking, Request Redirect Route Query, Local Cache Query und mehr.

• Picasso – Optimierte Bildbearbeitung, die so gut ist, dass sie jetzt von Google verwendet wird. Es ist eine große Zeitersparnis bei medienintensiven Projekten und bestimmten Altprojekten.

• ActiveAndroid – ORM leicht gemacht ohne Leistungseinbußen.

• LibStreaming – Echtzeit-Videostreaming, das von großen Streaming-Apps verwendet wird.

Sind dies die einzigen Android-Bibliotheken, die Ihre Zeit wert sind? Sicherlich nicht. Aber ich verspreche Ihnen Folgendes: Wenn Sie eines davon bei Ihrem nächsten Projekt verwenden, werden Sie ein viel besserer Entwickler. Wenn Sie sie in Aktion sehen möchten, werfen Sie einen Blick auf mein GitHub.

Wenn Sie bereits einige oder alle von ihnen verwenden oder wenn Sie alternative Bibliotheken verwenden, bitte ich Sie dringend, Ihre Erfahrungen in den Kommentaren unten zu teilen.