Android AsyncTask vs Thread + Handler vs rxjava

9

Ich weiß, dass dies die Frage ist, die viele Male gestellt wurde. Allerdings gibt es etwas, auf das ich nie eine Antwort gefunden habe. Hoffentlich kann mir jemand etwas Licht geben.

Wir alle wissen, dass AsyncTask und Thread Optionen zum Ausführen von Hintergrundaufgaben sind, um ANR-Probleme zu vermeiden. Es wird empfohlen, dass asynctask nur für kurz laufende Aufgaben verwendet wird, während thread für lang andauernde Aufgaben verwendet werden kann. Die Gründe, warum asynctask nicht für lange Aufgaben verwendet werden sollte, sind wohlbekannt, was auf das mögliche Leck hinweist, das von asynctask verursacht wird, da es möglicherweise weiterläuft, nachdem eine Aktivität zerstört wurde. Das ist überzeugend. Es führt jedoch auch zu einigen anderen Fragen:

  1. Ist der Thread auch unabhängig vom Aktivitätszyklus? Somit kann das Risiko mit asynctask auch auf den Thread angewendet werden. Warum ist Thread also für lang andauernde Aufgaben geeignet?
  2. Sieht so aus, als ob das Risiko von asynctask nur anwendbar ist, wenn es mit Aktivität verwendet wird. Wenn wir es im Dienst verwenden (nicht IntentService, da IntentService nach Abschluss seiner Arbeit stoppt), und solange wir garantieren können, dass die asyntask abgebrochen wird, wenn der Dienst gestoppt wurde, können wir es für lang andauernde Aufgaben verwenden? Und bedeutet das nicht, dass es risikofrei ist, asynctask in Diensten zu verwenden?
  3. Ich habe eine Weile mit rxjava gespielt und mag es wirklich. Sie müssen sich keine Sorgen mehr um das Threading machen (außer, dass Sie sich entscheiden müssen, in welchem ​​Thread Sie die gesendeten Daten abonnieren und beobachten). Von dem, was ich sehen kann, scheint rxjava (in Verbindung mit einigen anderen Bibliotheken wie Retrofit) ein perfekter Ersatz für Asynctask und Thread zu sein. Ich frage mich, ob wir sie komplett vergessen können oder ob es einen speziellen Fall gibt, in dem rxjava nicht erreichen kann, was asynctask und thread können, was ich beachten sollte?

Danke

    
H.Nguyen 05.10.2016, 00:37
quelle

2 Antworten

1

Da niemand antwortet. Ich beantworte dann meine eigenen Fragen.

  1. Der Grund, warum AsyncTask nur für kurze Aufgaben (etwa 5 Sekunden) empfohlen wird, ist, dass es keine Methode zum Abbrechen einer laufenden AsyncTask gibt. Es gibt eine Methode namens AsyncTask.cancel(true) , die onCancelled(Result result) aufruft. Laut der Dokumentation wird diese Methode jedoch "auf dem UI-Thread ausgeführt, nachdem cancel (boolean) aufgerufen wurde und doInBackground (Object []) beendet wurde." ( Ссылка ). Auf der anderen Seite kann Thread mit Thread.interrupt() gestoppt werden.
  2. Es sollte kein Problem geben, ein AsyncTask in einem Service auszuführen, vorausgesetzt, Sie kennen die Abbruchbegrenzung von AsyncTask und die Möglichkeit eines Speicherlecks kann durch AsyncTask erzeugt werden. Beachten Sie, dass es natürlich nicht notwendig ist, ein AsyncTask in einem IntentService zu verwenden, das bereits in einem Worker-Thread ausgeführt wird.
  3. Dies ist eine sehr erfahrungsbasierte Frage. Ich denke, es würde keine vollständige Antwort geben. Was wir tun können, ist, Rx zu verstehen und sich dessen Grenzen bewusst zu sein, um festzustellen, wo es geeignet ist, es zu benutzen. In meiner Entwicklungsarbeit verwende ich RxJava die ganze Zeit, ohne ein Problem zu haben. Beachten Sie, dass dasselbe Speicherleckproblem auch auf RxJava angewendet wird. Sie können vielleicht eine der spezifischen Fragen hier finden. Es gibt auch eine ganze Reihe von Diskussionen über die Handhabung von Leaking / Screen Rotation mit RxJava , die von Google einfach gefunden werden können.
H.Nguyen 14.10.2016, 03:12
quelle
0

AsyncTask und Thread + Handler sind nicht sorgfältig entworfen und implementiert. RxJava, Akka und andere Frameworks für asynchrone Ausführung scheinen sorgfältiger entwickelt zu sein.

Jede Technologie hat ihre Grenzen. AsyncTask ist für eine einzelne parallele Aufgabe mit der Möglichkeit, den Fortschritt auf der Benutzeroberfläche anzuzeigen. Wenn die Aktivität jedoch neu generiert wird (z. B. weil sich der Bildschirm dreht), geht die Verbindung zur Benutzeroberfläche verloren (eine mögliche Lösung für dieses Problem ist Ссылка ).

Thread+Handler behält Speicher für den Thread-Stack, auch wenn keine zu verarbeitenden Nachrichten vorhanden sind. Dies begrenzt die mögliche Anzahl von Threads. Sie können viel mehr Akka actors oder RxJava Subscribers als Handler-Threads mit ähnlicher Funktionalität haben.

    
Alexei Kaigorodov 06.10.2016 19:41
quelle