2009-02-03 8 views
11

Ich erstelle eine Java-Anwendung, die eine gewisse Verarbeitung durchführt und dann eine Nachricht anzeigen muss, um dem Benutzer Feedback zu geben.Schnellste Möglichkeit zum Erstellen eines Java-Nachrichtendialogs (swing/awt/other)?

Allerdings scheint es unglaublich langsam zu sein - dauert über zwei Sekunden, um zurückzukehren.

ich die Quelle nach unten auf die scheinbaren Täter beraubt, und hier ist der Code verwendet:

package SwingPlay; 

import javax.swing.JFrame; 

public class Dialog 
{ 

    public static void main(String[] args) 
    { 
     JFrame frame = new JFrame("DialogDemo"); 
    } 

} 

ich dies von der Kommandozeile mit der Ausführung:

java -classpath . SwingPlay.Dialog 

Wie Sie sehen können - Ich mache nichts anderes, als einen JFrame zu erstellen und ihn nicht einmal anzuzeigen.

Falls es relevant, hier ist mein java -version Ausgabe:

java version "1.6.0_11" 
Java(TM) SE Runtime Environment (build 1.6.0_11-b03) 
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing) 

Und das ist (derzeit) läuft gegen Win XP SP2.

Also, erste Frage: Warum ist es so langsam?

Noch wichtiger, ich möchte nur eine einfache Nachricht (GUI, nicht Cmdline) ohne Verzögerung angezeigt werden - kann jemand einige Code zur Verfügung stellen, um dies zu tun?


Update:

Ein bisschen Hintergrund nützlich sein könnte:
ich eine Anwendung bin zu schaffen, die viele ‚Köpfe‘ (dh unterschiedliche Benutzeroberflächen alle mit den gleichen Kern-Klassen haben zu tun die komplexen Teile).
Ich habe derzeit einen reinen Befehlszeilenkopf, der gut funktioniert - reagiert sofort.
Ich habe auch eine Standardanwendung mit einem regulären Punkt & klicken Sie auf GUI, und sehen Sie keine Probleme mit diesem Bit.
Woran ich gerade arbeite, ist eine Mischung aus diesen beiden - es wird von einer Run-Box (oder einem ähnlichen Launcher) gestartet, möglicherweise mit Argumenten, und muss nur effektiv mit einer Statusmeldung antworten, die abgewiesen werden kann mit einem Tastendruck.

In letzterem ist die Frage konzentriert.

Während ich nicht dagegen bin, meine vorhandene Kommandozeilenversion mit Shellskripten zu verwenden (obwohl ich nicht dachte, dass es notwendig wäre!), Scheinen die vorhandenen Antworten darauf hinzudeuten, dass die Dinge für mich nicht so schnell laufen für andere - ein Beispiel dauert 1460ms für mich, gegenüber 70ms - ein signifikanter Unterschied.

Antwort

0

Was Sie wahrscheinlich suchen, ist die new SplashScreen functionality in Java 6. Anstatt auf das Laden der JVM zu warten (es kostet immer eine VM), wird vorher ein Bildschirm geladen.

+0

Ich bin nicht auf der Suche nach einem statischen Bild, sondern ein dynamisches Stück Text. Um es anders auszudrücken, ich möchte Stdout zu einer GUI-Message-Box umleiten. Wenn ich tatsächlich System.out verwende.println es kommt schnell genug zurück, aber offensichtlich nicht im richtigen Format. –

2

Auch wäre es viel schneller, eine AWT Window (oder vielleicht eine Frame) anstelle einer JFrame zu erstellen, weil letztere eine Ziege von zusätzlichen Klassen-Dateien ziehen muss.

+0

Während java.awt.Frame schneller ist, ist es immer noch über eine Sekunde Verzögerung. :( –

+0

Ja, leider ist es nicht wirklich schnell. Wenn Sie alles in einem einzigen Programm haben, erstellen Sie den Rahmen, bevor Sie die eigentliche Aktion ausführen und dann zeigen Sie es einfach, wenn Sie fertig sind. Es wird nicht insgesamt schneller aber es wird sicherlich so aussehen .. – Bombe

+0

Die eigentliche Handlung passiert in einem Blinzeln, so werde ich leider nicht einmal diese Illusion gewinnen ... –

1

Oh, und wenn Sie nicht brauchen, um den Dialog von Java anzuzeigen, könnten Sie in Verwendung (oder es ist GNOME-Gegenstück) oder etwas ähnliches.

+0

Der Kern der Anwendung muss Java sein, aber wenn die Verwendung sogar eine grundlegende Schnittstelle zu langsam ist, dann ich kann mit der Verwendung von Shell-Skripts, um die Antwort aus dem Programm anzuzeigen –

+0

Ja, die erste Instanziierung von etwas GUI-bezogenen in Java wird immer langsam (er), gibt es keine Möglichkeit, das zu verhindern, kurz vor nativen gehen (entweder über JNI oder mit Runtime.exec()). – Bombe

4

Ich würde eine JOptionPane verwenden, um die Nachricht anzuzeigen. Hier ist ein einfaches Beispiel:

import javax.swing.*; 

public class OptionDemo { 
    public static void main(String[] args) throws Exception { 
     JOptionPane.showMessageDialog(null, "Hello World"); 
    } 
} 

Ich fürchte, ich kann die Verzögerung, die Sie erleben, nicht erklären. Auf meinem System wird Ihr Code-Snippet in 500 Millisekunden ausgeführt.

+0

Das scheint in etwa die gleiche Geschwindigkeit wie das AWT-Beispiel, das ich versuchte (über eine Sekunde, vielleicht 1,5 Sekunden), was eine Verbesserung ist, aber immer noch nervend langsam könnte es zu 500ms bringen, die akzeptabel sein könnten. –

1

könnten Sie verwenden die JOptionDialog

JOptionPane.showMessageDialog([parent frame], [message], [title], JOptionPane.MESSAGE_TYPE); 
3

Java das falsche Werkzeug dafür ist. Das Einrichten der JVM beinhaltet eine Menge Dinge, die im Hintergrund passieren, bevor die erste Zeile des Java-Codes ausgeführt werden kann, und es gibt wirklich keine Möglichkeit, sie zu umgehen.

+0

Wenn die JVM die Ursache ist, warum ist es nicht langsam bei der Ausgabe an die Konsole, über System.out.println ('Text')? –

+3

@Peter: Weil die JVM das AWT-Subsystem nicht initialisiert, wenn es nicht benötigt wird. Es ist sehr wahrscheinlich, dass dies die Verzögerung in diesem Fall verursacht. –

10

Der Grund für die Verzögerung, weil Java ist eine interpretierte Sprache und es braucht Zeit, eine neue JVM (der Dolmetscher)

Eigentlich Schaffung des Rahmens zu starten dauert weniger als ein paar ms (etwa 70 ms in meinem Rechner).

Wenn dies in einer Java-App verwendet wird, müssen Sie sich keine Gedanken darüber machen. Es wird fast sofort sein (Sie sollten JDialog oder JOptionPane dafür verwenden)

Wenn dies nicht innerhalb einer Java-App verwendet wird, und 2 Sekunden es zu viel (und ich denke, es ist zu viel) sollten Sie überlegen ein anderes Werkzeug für den Job.

Hier ist, wie ich die Zeit in Ihrem Code messen:

import javax.swing.JFrame; 

public class Dialog { 

    public static void main(String[] args) { 
     long start = System.currentTimeMillis(); 
     JFrame frame = new JFrame("DialogDemo"); 
     System.out.println("Took: " + ( System.currentTimeMillis() - start )); 
    } 

} 
+0

Hmmm, mit Ihrem Code dauert hier durchschnittlich 1460 ms - das ist viel langsamer als Ihre 70ms - also muss etwas mit meinem Setup nicht stimmen? Dieses spezielle Bit Code könnte ein Shell-Skript verwenden, aber ich möchte immer noch herausfinden, warum ich eine so schlechte Leistung im Vergleich zu Ihnen/anderen bekomme. –

+0

dauert etwa 400 bis 500 ms auf meinem Rechner (4 Jahre alten Pentium 3 M mit 1,8 GHz). – Bombe

+0

Die 70 ms vergehen zwischen dem "langen Start ..." bis zur System.out ... (genau wie vom Test ausgedruckt). Von der Konsole aus dauert es ca. 1,5 Sekunden. Aber das ist das JVM-Startup. In einer Java-App erhalten Sie diese 1.5 nicht extra. – OscarRyz

0

Haben Sie versucht, es durch einen Profiler wie NetBeans läuft? Wenn es einen Engpass tief in der Standardbibliothek gibt, ist das ein guter Weg, um es zu finden.

2

Müssen Sie Java verwenden, um das Meldungsfeld anzuzeigen? Wenn die Box von außerhalb Ihrer Anwendung kommt, möchten Sie möglicherweise etwas anderes verwenden, um einen Dialog zu erstellen.

Um eine native Windows-Anwendung, die nur ein Meldungsfeld von einer Befehlszeile String zeigt, würde nur ein paar Stunden dauern. Die meisten gängigen Skriptsprachen sollten auch Möglichkeiten haben, dies zu tun. hier ist ein Beispiel von einem Typ durch Javascript über die Kommandozeile:

http://www.snee.com/bobdc.blog/2009/01/displaying-a-message-box-from.html

1

Da Sie dies bei der Beschleunigung interessiert sind, und die meisten der Overhead seit Start der JVM-Overhead zu sein scheinen Besuche Nailgun, die darauf abzielt, Adressieren Sie den langsamen JVM-Start, indem Sie eine JVM immer im Hintergrund laufen lassen. In Ihrem Fall wird nach einem Durchlauf auch die Swing-Bibliothek zwischengespeichert (und hoffentlich nach ein paar weiteren Läufen auch JITed), was den Overhead weiter reduziert.

Dieser Ansatz führt jedoch aufgrund der Hintergrund-JVM zu einer erhöhten Speichernutzung und verursacht auch andere Probleme, da es nicht einfach ist, festzustellen, wann er heruntergefahren werden muss.

+0

Siehe auch Tropf https://github.com/flatland/drip – rogerdpack

Verwandte Themen