Ich habe nach einer perfekten Android-Anwendungsarchitektur gesucht und ein paar großartige Blogposts zu diesem Thema gelesen.
1) Ссылка
2) Ссылка
Beide Beiträge beschreiben, wie man den Event-Bus für die Kommunikation zwischen Android-Komponenten (Aktivität, Fragmente, Dienst) verwendet.
Ein, aber sehr wichtiges Thema wurde nicht behandelt. Wie behandeln Sie Ereignisse, die bei Pausierungen an UI-Komponenten gesendet wurden.
Beispiel: Der Service sendet ein Ereignis nach Abschluss des Herunterladens von Daten in die Aktivität. Und in diesem Moment ist die Aktivität pausiert. Da der Ereignis-Bus in onPause () nicht registriert wird, verlieren wir dieses Ereignis vollständig.
EvenBus von greendao bietet Stickevents. Sie können jedoch Speicherlecks verursachen, wenn sie nicht entfernt werden.
Otto from square führt das "Producer" -Muster ein, das anstelle von klebrigen Ereignissen verwendet werden kann.
Die erste Lösung kann zu Speicherverlusten führen, wenn das Problem nicht manuell behoben wird.
Im zweiten Fall müssen die Daten irgendwo gespeichert werden, bis die Producer-Methode sie an die Abonnenten zurückgibt. Diese Lösung scheint korrekter zu sein, erfordert aber mehr Code zu schreiben.
Könnte jemand bitte mit Ideen teilen, wie man diesen Randfall anpackt? Irgendwelche sauberen Lösungen?
Ich habe auch eine sehr elegante Architektur mit dem EventBus verwendet. Es ist ein hervorragendes Tool, um Ihre Benutzeroberfläche von der Geschäfts- und Kommunikationsebene zu trennen und zu verhindern, dass lang laufende Netzwerk- oder Datenbankjobs versuchen, eine Benutzeroberfläche zu aktualisieren, die bereits zerstört wurde. Ich könnte den ganzen Tag darüber reden, aber ich werde mich auf dein Problem konzentrieren.
Klebrige Ereignisse sind in den meisten Fällen und IMHO völlig in Ordnung. Ja, technisch gesehen ist es ein Speicherleck, weil das Ereignis im Speicher gespeichert ist und nichts außer dem Eventbus es referenziert ... noch. Aber klebrige Ereignisse per Definition sind alle technisch Speicherlecks, bis Sie sie tatsächlich richtig nutzen? Also, wenn Sie Ihr Fragment starten und das klebrige Ereignis dann plötzlich verwenden, ist es kein Speicherleck mehr.
Wie auch immer, ohne zu religiös zu werden, sind klebrige Ereignisse völlig in Ordnung, solange das Ereignis keine Millionen Datensätze oder große Datenstrukturen wie Bilder enthält. Dann beginnt Ihre Memory-Leak-Theorie mehr Sinn.
Sie versuchen jedoch wirklich, die Ergebnisse des Netzwerkaufrufs zwischenzuspeichern, oder? Also ...
Ich würde vorschlagen, einige intelligente und dauerhafte HTTP-Caching zu implementieren. Robospice macht vieles für Sie out-of-the-box. Sie können Cache-Schlüssel, Cache-Speicherorte und Cache-Timeouts definieren - wirklich coole Dinge. Dies entfernt den Cache aus dem Speicher (dh dem sticky-Ereignis) und in eine Datei, weiter unten in der Kommunikationsschicht, die wahrscheinlich viel sauberer ist.
Tags und Links android greenrobot-eventbus