Come progettare MVC in JavaFX rispetto alle prestazioni dell'attività non-GUI

Question

Come progettare MVC in JavaFX rispetto alle prestazioni dell'attività non-GUI

#1 da (1 voti)

0

Sto lavorando su un'enorme applicazione e abbiamo avuto alcuni problemi seri riguardo alle prestazioni del software. Non voglio disturbarti con troppi dettagli, quindi in breve:

in una JVM viene eseguita la GUI (JavaFX)
in un'altra JVM esegue la logica
le due JVM comunicano tra loro tramite socket (per trasmissioni veloci) e http

La logica-jvm esegue periodicamente (1/10) alcune analisi dei dati e crea una struttura contenente alcuni numeri e immagini (rgb, 640 * 480). Il gui deve visualizzare questi dati alla stessa velocità e visualizzare le immagini. Attualmente la GUI richiede 10 volte al secondo questi dati dalla logica jvm su http, mentre i dati stessi vengono inviati tramite una connessione socket. Questa circostanza è nata dall'idea di poter collegare più GUI a una logica. Ma come ha mostrato il tempo, non lo faremo. Inoltre, le prestazioni sono davvero pessime, non appena i dati (principalmente a causa di più immagini) diventano più grandi (250 MB). Sembra che il collo di bottiglia è, dove mettiamo i dati dell'immagine nel bytebuffer e l'invio. Come detto prima, probabilmente non avremo mai più gui - quindi perché non usare solo un jvm.

Che cosa parla della soluzione attuale:

Possiamo impostare la priorità delle applicazioni in Windows. la logica deve davvero funzionare senza intoppi e viene data un'alta priorità. L'applicazione GUI dovrebbe anche funzionare senza problemi, ma a nessuno importa se salta un frame o due.

Inoltre la GUI ha alcune viste, in cui le proprietà (per semplicità SimpleObjectProperty) nella logica dovrebbero essere modificate. Cioè un campo di testo JavaFx deve essere associato bidirezionale a una proprietà SimpleString nella parte logica. Quindi aggiornare la stringa all'interno della logica modificherà il campo di testo e viceversa.

gui

TextField tf = new TextField();
tf.textProperty().bindBidirectional(observableOfLogic);

Spero che tu provi qualcosa per la situazione.

Ora finalmente desidero esprimere la mia domanda:

Qual è il miglior design per un simile problema?

Grazie mille in anticipo.

object-oriented-design mvc javafx

posta blaster 16.04.2016 - 01:29

fonte

1 risposta

Leggi altre domande sui tag object-oriented-design mvc javafx

Fabbriche astratte Nesting e DI - È accettabile? Passaggio di un'istanza della porta seriale

score 1 · Answer 1

Non posso fornirti l'approccio "migliore" per ciò che stai cercando di realizzare, ma posso fare del mio meglio per aiutarti a prendere decisioni a livello di sistema e migliorare la tua applicazione.

1) Ridurre la complessità è utile per aumentare le prestazioni. Sembra che tu sia giunto alla conclusione che non hai bisogno di una GUI remota. Ottimo, tienilo nella stessa VM. Si prega di essere consapevoli della concorrenza nell'applicazione risultante, tuttavia. Guarda le risorse qui per le buone pratiche sulla concorrenza e JavaFX.

2) Pensa al tuo problema come a un problema video. Nel mondo dei video, è normale gestire rapidamente un flusso visivo da più immagini. Ci sono molte soluzioni qui e alcune potrebbero adattarsi alle tue esigenze. Uno a cui guardare è FFMPEG. FFMPEG è una soluzione multipiattaforma per creare, convertire e / o riprodurre video e audio. Spostare il problema nello spazio video ha inoltre il vantaggio di fornire prontamente soluzioni per lo streaming remoto nel caso in cui dovessi decidere di aver bisogno di una guida remota o multipla. Un esempio di conversione da immagine a video per FFMPEG è qui . Informazioni su un wrapper Java per FFMPEG possono essere trovate qui .

3) Se l'utilizzo del video non funziona per la tua situazione e la pressione della memoria sta causando il collo di bottiglia, tieni solo 2-3 immagini in giro per volta. Ad esempio, l'immagine attualmente sottoposta a rendering alla GUI, l'ultima immagine completata dalla logica e l'immagine attualmente generata dalla logica. Le interazioni a multithread sono un problema qui. Dal momento che i thread logici hanno la priorità assicurano di non dover mai attendere un blocco per elaborare. Assicurati che qualsiasi cosa accolga la GUI prenda il colpo quando si rende necessario attendere il completamento dell'immagine. Infine, cerca di utilizzare i buffer piuttosto che creare costantemente nuovi oggetti ogni volta. Ciò eviterà l'esecuzione del garbage collector per smaltire migliaia di immagini. Guarda qui per vedere le informazioni sulla scrittura in modo performato delle immagini sulla tela.

4) Non vedo un tremendo colpo alle prestazioni dalla proprietà del campo di testo bidirezionale rispetto alle quantità mostruose di dati generati sul lato dell'immagine. Basta pensare alla concorrenza e agli effetti del blocco e di altri meccanismi interattivi. Vedi # 1.