Czy istnieje sposób na kompilowanie/ładowanie plików fxml szybciej i tylko jeden raz, a nie przy każdym ponownym uruchomieniu aplikacji?

Question

Mam program, który ładuje wiele plików fxml po uruchomieniu. Aplikacja zostanie zakończona w krótkim czasie, a załadowanie aplikacji zajmuje zbyt długo.

Istnieje wiele plików fxml (20+) i wszystkie te pliki fxml są załadowane kodem Java. Będzie punkt, że aplikacja jest gotowa do użycia, ale wszystkie pliki będą ładowane przy każdym wykonaniu programu. Czy pliki fxml można skompilować tylko raz, ponieważ nie zostaną zmienione po zakończeniu?

Kod java zostanie oczywiście skompilowany raz, to tylko pliki fxml. Uruchomienie aplikacji trwa teraz 25 sekund, a 14 sekund zajmuje załadowanie pliku fxml.

Czy istnieje sposób, aby uczynić to wszystko szybszym?

EDIT # 1:

Czy istnieją jakieś narzędzia, które są dostarczane za darmo i które sprawiają, że wykonanie aplikacji (Java) dużo szybciej? Czy czas wykonania jest jedynie zależny od sposobu napisania programu?

Które wzorce projektowe mogą pomóc w skróceniu czasu realizacji aplikacji?

EDIT # 2:

Poniższy kod będzie wyjaśnić mój problem w skrócie:

package main; 

....... 
....... 

public class MainClass { 

    .... 
    .... 

    List<InformationController> controllerList; 

    public mainClass(List<InformationControllers> controllerList) { 
     this.controllerList = otherClass.getControllerList(); 
     loadFXMLFiles(); 
    } 

    public void loadFXMLFiles() { 
     for(InformationController controller : controllerList) { 
      controller.loadFXML(); 
     } 
     doOtherStuff(); 
    } 

    .... 

} 

Wszystkie te InformationControllers mieć ich załadunek innych fxml pliki zbyt, więc jest to rzeczywiście drzewo załadowane pliki fxml. Jest on ładowany na każdym starcie aplikacji, więc czy istnieje sposób, aby zrobić to ładowanie tylko raz?

Answer 1

Na Jak przyspieszyć FXML wydajność

Zrobię tę odpowiedź Wiki, jeśli ktoś inny ma dalsze pomysły, proszę go edytować i dodać je.

1. nie należy używać statycznego FXMLLoader.load() ale powinno zamiast create an instance of FXMLLoader i ponowne tamten używając instancji loader.load() metody. Powodem jest to, że pamięci podręczne FXML-Loader, np. wyszukiwanie klas, a tym samym przyspieszenie ładowania kolejnego pliku FXML.
2. Użyj narzędzia do kompilacji FXML do Java, na przykład Tom Schindl's FXML compiler lub NetBeans FXML to Java converter.
3. Nie ładuj więcej FXML niż potrzebujesz w danym momencie, np. jeśli nie zamierzasz wyświetlać go teraz, nie ładuj go.
4. Załaduj FXML w wątku tła (nie działa dla niektórych typów kontrolek, np. Etykietka narzędzi, w języku Java 8).
5. Załaduj najpierw login lub splash screen, a następnie załaduj resztę FXML, gdy wyświetlany jest ekran powitalny lub logowania. Ładuję FXML w niektórych aplikacjach po potwierdzeniu danych logowania na ekranie logowania.
6. Zredukuj złożoność interfejsu użytkownika aplikacji, usuwając niepotrzebne węzły.
7. Upewnij się, że nie wykonujesz niepotrzebnej pracy (np. Czytając bazę danych) w wątku interfejsu JavaFX w metodach inicjowania kontrolerów.
8. Dokumentacja FXMLLoader.load() w JavaFX 8 zawiera odniesienie do szablonów FXML, ale nie sądzę, że kiedykolwiek została zaimplementowana, więc może to ci nie pomoże.
9. Słyszałem, że nawiązanie do static methods from FXML jest powolne.
10. Użyj latest development version of JavaFX.
11. Po wczytaniu hierarchii węzłów z FXML, użyj hierarchii później, zamiast wyrzucać ją i ładować nową (np. Jeśli masz okno dialogowe z treścią skonstruowaną przy użyciu FXML, kiedy użytkownik zamyka okno dialogowe, po prostu ukryj i kiedy trzeba ponownie wyświetlić podobny dialog, po prostu pokaż ukryte okno dialogowe zamiast tworzyć całkowicie nowe okno dialogowe i wykres sceny).

Odbicie dlatego FXML jest powolny

Myślę, że głównym powodem wdrożenia FXML Java 8 jest powolny jest to, że opiera się tak mocno na refleksji i reflection is slow jak opisano w reflection tutorial:

Ponieważ odbicie obejmuje typy, które są dynamicznie rozdzielane, niektóre optymalizacje maszyny wirtualnej Java nie mogą zostać wykonane. W związku z tym operacje odbijające mają mniejszą wydajność niż ich nieodblaskowe odpowiedniki i należy ich unikać w sekcjach kodu, które często są wywoływane w aplikacjach wrażliwych na wydajność.