Allgemeine Frage zur Nützlichkeit und Verwendbarkeit von Threads

1. ein leerer finally - Block ist nutzlos.
2. Ein try-Block ohne catch oder finally ist nutzlos.
3. Wenn du einen Thread startest, dann wird dessen run()-Methode parallel zur anderen Anweisungen ausgeführt.
   Thread#start() kehrt sofort zurück.

Ob es nun sinnvoll ist alle Sachen in andere Threads auszulagern ist etwas anderes:
1. Jeder Thread kann nur einmal verwendet werden.
2. Jeder Thread bedeutet mehr Aufwand für Java.
3. Aus einem Thread darf man nicht auf Views/Layouts/UI zugreifen.

Bei Operationen die "lange" dauern ist ein Thread (oder AsyncTask) zu empfehlen - z.B. beim Download einer Website. (da gehts sogar ohne nicht)

— geändert am 15.05.2014, 21:15:55

Lars F.

1. Also mein SachenSpeichern(); wird parallel zu anderen Anweisungen ausgeführt, das verstehe ich. Aber wohin kehrt Thread.start() zurück?

Damit meine ich, dass die Anweisung(en) die hinter t.start(); stehen ohne Verzögerung ausgeführt werden. Darum ist deine Methode schneller! Die eigentliche Arbeit dauert immer noch 2 bis 3 Sekunden, nur ist davon der UI-Thread (der die Benutzeroberfläche "malt" nicht betroffen.

[[cite Lars]]
1. Inwiefern kann ein Thread nur einmal verwendet werden? So wie ich das implementiert habe wird der Thread jetzt nach jedem Klick auf einem Button gestartet. Bzw. wird neu erstellt und dann gestartet.

Wenn du kannst nicht zweimal t.start() auf die selbe Refernz aufrufen. Vorher muss also t ein neuer Thread zugewiesen werden: t = new Thread(...);

— geändert am 15.05.2014, 21:48:20

Wenn du Thread.start() machst, bedeutet das für die App in dem Haupt Thread so gut wie keine Verzögerung. Also: der Thread wird dadurch gestartet und läuft parallel zum Haupt Thread, dieser kann aber nur auf ui Elemente zugreifen.
Trotzdem kannst du mit runOnUiThread() aus einem anderen Thread herraus etwas im Haupt Thread ausführen(TextView.setText() zum Beispiel).

@Lars

Wenn du Thread.start() machst, bedeutet das für die App in dem Haupt
Thread so gut wie keine Verzögerung.

Definitiv FALSCH! / NEIN!

Stell Dir bite vor, Du bist ein Prozessor (sogar ein Dual- Core - hihihi)
Du bekommst auf einmal (machen wir nur um die 140 Aufgaben - [Android App Starten, Dienste / Services, ... Layout, ... Bilder, ... Lauscher ... ] .. ODER? bist Du mit mehr als 140 Aufgaben einverstanden?)
Sogar wenn es NUR 40 Aufgaben sein sollen - ...
Bildlich:
DU als Prozessor sollst alle Farben Deiner T-Shirts auf einem Zettel (Gleichzeitig!) schreiben.
Wie machst Du es Parallel (also gleichzeitig) alle die? (NEIN!) NUR! die eine Aufgabe (Farben Deiner T-Shirts auf einem Zettel zu schreiben) zu realisieren?
ES GEHT NICHT! Und wenn Du noch um die XXX Aufgaben machen sollst (welcher etwas um die YYY Sub- Aufgaben in sich integrieren, die mit ..... )
Die "Dinge" heißen auch Tasks ...

LG
Georg

Natürlich wird das nicht richtig parallel gemacht, es wird bei einem singel core immer nur ein Befehl ausgeführt. Er simuliert das durch ständiges abwechselndes Ausführen der Befehle aus den ganzen Threads.

Georg C.

Definitiv FALSCH! / NEIN!

Unsinn....
Ob die Gesamtperformance in den Keller geht, wenn man 'zig Threads startet, darum geht es doch gar nicht. Wenn man einen Thread startet, geht es im Hauptprogramm so gut wie verzögerungsfrei weiter. Die Aussage ist vollkommen richtig.

Ohh my god,

es gibt zig bücher dazu. Threads sind tricky gerade bei android, ein thread irgendwo mitten im code ist nutzlos, da er sich nicht an den lifecycle hält. Threads sind relative teure Objete die man da erstellt, jeder Thread hat einen eigenden Heap und verbraucht somit speicherplatz und es werden kopien der Objecte angelegt die der Thread potentiel benutzen wird.

Wer new Thread() in seinem Code will irgwndwo stehen hat sollte zumindest überlegen einen ThreadPool zu benutzen, Java und Android bieten entsprechende möglichkeiten. Durch benutzen von den ThreadPools braucht man auch nur noch Runnable/Callable schreiben und diese dem ThreadPool übergeben. Z.b gibt es ThreadPoolExcecutor um aufgaben im hintergrund erledigen zu lassen, auf dem DualCore hat der Pool dann z.b wenn man es möchte nur 4 Thread die parallel laufen, auf einem Octacore entsprechend mehr. Dafür kann man ja auslesen wie viele Kerne auf dem Gerät vorhanden sind.

Ich empfehle mal das hier zu lesen: http://www.amazon.de/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

Auf android hat man aber auch die möglichkeit Functional Programming einzusetzen wie es z.b Retrofit teilweise benutzt, RXJava kann deutlich dazu verhelfen eine bessere Architektur und besseres Thread Management zu haben als diese wilden sachen.

Weiterhin wäre es auch einfach gut einen IntentService den Android von haus aus anbietet zu benutzen und ihn dinge erledigen zu lassen.

hth,
Mac

PS: Asynctask ist im Kern ein ThreadPool

— geändert am 16.05.2014, 10:54:20

Threads sind relative teure Objete die man da erstellt, jeder Thread
hat einen eigenden Heap und verbraucht somit speicherplatz und es
werden kopien der Objecte angelegt die der Thread potentiel benutzen
wird.

Und gerade das, abstrahierend davon, - welche Architektur das System mit sich repräsentiert,
benötigt Zeit (Verarbeitung der Prozessen / Befählen im Programmrumpf)
- und genau das, und NUR! das habe ich angesprochen.
Parallel ist in der Programmierung Hardware -> meiner Meinung nach mit Vorsicht zu genießen.

LG
Georg

Ps.
RXJava war(?ist) schon eine entnorme Performance Steigerung.
Wie fern es im Android engesetzt wird habe ich keine Ahnung.
Fakt ist, .... sogar bei den Präemptive Multitasking Systemen wird immer noch (es war Definitiv damals!) dem Scheduler "die Schuld gegeben" (auch mit recht) dass [Scheduler] der CPU-Zeit "Fresser" ist.
Weil die Technik - klar - nach vorne geht - BIN RAUS!

Ohh my god, Ende