Allgemeine Frage zur Nützlichkeit und Verwendbarkeit von Threads

  • Antworten:10
  • OffenNicht stickyNicht beantwortet
  • Forum-Beiträge: 2.492

15.05.2014, 20:17:20 via Website

Hallo,

ich habe gerade in meiner App in einer Methode folgendes:

private void listeSpeichern(final boolean links) {
        // TODO Auto-generated method stub
...
SachenSpeichern();
...
    }

zu

 private void listeSpeichern(final boolean links) {
// TODO Auto-generated method stub
        final Thread t = new Thread() {
            @Override
            public void run() {
                try {
...
SachenSpeichern();
...
                } finally {
                }
            }
        };
        t.start();
    }

geändert und auf einmal geht die Methode viel schneller durch. Kann ich jetzt einfach "jede" Methode so ändern, dass die in einen neuen Thread ausgelagert wird und dadurch die Methode schneller abgearbeitet wird?
Das wäre bei langsamen Handys ja ein deutlicher Geschwindigkeitsgewinn.

— geändert am 15.05.2014, 20:25:27

Antworten
  • Forum-Beiträge: 1.793

15.05.2014, 21:15:40 via App

  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

Liebe Grüße impjor.

Für ein gutes Miteinander: Unsere Regeln
Apps für jeden Einsatzzweck
Stellt eure App vor!

Antworten
  • Forum-Beiträge: 2.492

15.05.2014, 21:23:53 via Website

Ach stimmt das try und finally brauch ich ja gar nicht.

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

  2. 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.

Ich speichere mehrere Bilder im InternalStorage und so wie ich es vorher hatte hat es schon 2-3 Sekunden gedauert bis es fertig war, jetzt merke ich überhaupt keiner Verzögerung mehr.

Antworten
  • Forum-Beiträge: 1.793

15.05.2014, 21:46:01 via App

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

Liebe Grüße impjor.

Für ein gutes Miteinander: Unsere Regeln
Apps für jeden Einsatzzweck
Stellt eure App vor!

Antworten
  • Forum-Beiträge: 1.904

15.05.2014, 21:53:45 via App

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).

Wenn dir mein Beitrag gefällt, kannst dich einfach mit dem 👍 "Danke"-Button auf der Website dieses Forums bedanken. 😀

Why Java? - Because I can't C#

Antworten
  • Forum-Beiträge: 222

15.05.2014, 23:52:33 via Website

@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

Sorry für Gramatik & Stilistik Fehler.

Antworten
  • Forum-Beiträge: 1.904

16.05.2014, 08:06:26 via App

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.

Wenn dir mein Beitrag gefällt, kannst dich einfach mit dem 👍 "Danke"-Button auf der Website dieses Forums bedanken. 😀

Why Java? - Because I can't C#

Antworten
  • Forum-Beiträge: 8.173

16.05.2014, 08:06:47 via Website

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.

if all else fails, read the instructions.

Antworten
  • Forum-Beiträge: 1.727

16.05.2014, 10:53:08 via Website

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

Windmate HD, See you @ IO 14 , Worked on Wundercar, Glass V3, LG G Watch, Moto 360, Android TV

Antworten
  • Forum-Beiträge: 222

17.05.2014, 01:56:25 via Website

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

Sorry für Gramatik & Stilistik Fehler.

Antworten

Empfohlene Artikel