Anwendungs-Startup -- Konzepte?!

**s.h.a.r.k**

Guten Abend zusammen,

ich stehe gerade vor dem Problem, wie genau man eine Anwendung hochfahren lassen kann und welche Punkte dies denn alles betrifft. Im allgemeinen frage ich hier nach Ideen von euch und will auch über eine Idee von mir diskutieren. Ziel des Ganzen soll es dann irgendwann mal sein, ein einheitliches Framework zu basteln, welches für nachzu alle Anwendungstypen (VCl-Anwendung, Konsolenanwendung, Service etc.) anwendbar ist -- in so fern das überhaupt möglich ist.

Zu klären wäre zuvor noch der Zustand "vollständig gestartet": ich stelle mir bei einer normalen VCL-Anwendung den Zustand vor, in dem der Benutzer das Hauptformular sieht, d.h. bezogen auf z.B. die Delphi IDE, eben das IDE-Fenster, oder bei Microsoft Word auch das Eingabe-Fenster mit der Ribbonleiste. Ebenso kann man dies auf Konsolenanwendungen und Dienste übertragen: der Zustand, bei dem die erste Eingabe möglich ist bzw. die erste Aufgabe, für die die Anwendung erstellt wurde, abgearbeitet wird. Natürlich kann man das hier noch sehr weit fassen, aber ich denke, dass nun in etwa klar ist, um was es geht. Solltet ihr hierzu Anmerkungen haben, so lasst es mich gerne wissen.

Welche Sachen fallen nun an, bis sich die Anwendung im "vollständig gestarteten Zustand" befindet? Bitte vervollständigt diese Liste, wenn euch dazu noch etwas einfällt!

SplashScreen ein- und ausblenden: Hierzu hat sakura einen Thread geliefert, der sehr interessant ist. Ich hatte das bisher immer so gelöst, dass ich im Hauptthread den SplashScreen angezeigt und in weiteren Threads den Startup gehandelt habe.
Log-Komponente einrichten
Allgemeine Konfigurationen laden (Registriy, INI, DB, XML etc.): Ich lagere die Konfiguration in eine separate Klasse, die als Datenhalter agiert und von Factories und sonstigen Klassen abgefragt werden kann.
DB-Verbindung aufbauen: Hier versuche ich eine Verbindung zur Datenbank aufzubauen, scheitert dies versuche ich dies mit Hilfe des Users zu fixen, z.B. falsch eingegebene Zugangsdaten, oder bringe eine entsprechende Fehlermeldung.
Basis-Daten aus der DB laden: Hierunter ist zu verstehen, dass ich quasi bei der Anzeige des SplashScreens schon mal das aufwendige Laden von Daten abhandeln will, sonst muss ich dem Nutzer nochmals einen Ladebildschirm zumuten.
DLLs/Plugins laden

Diese Sachen tauchen bei meinen Anwendungen jedenfalls andauernd auf. Daraus leite ich ab, dass ich teilweise aufeinandere aufbauende Teile laden muss. Daraus entstand dann die Idee, dass ich einen allgemeinen

CommandProcessor baue, der beim Start lediglich

Commands ausführt. Jedes Modul bekommt dann, in so fern es für den Start relevant ist, eine Command-Klasse "zugewiesen". Ein Beispiel:

SplashScreenShowCommand
LoadConfigurationCommand
ConnectToDatabaseCommand
LoadDataFromDataBaseCommand
CloseSplashScreenCommand

Ich habe schon bewusst auf die Reihenfolge geachtet, allerdings nicht auf mögliche Parallelität. Und zwar müssen die Commands ja in einer sinnvollen Reihenfolge ausgeführt werden, da die DB-Verbindung ja Einstellungen benötigen könnte, die vom Konfigurationsobjekt kommen, ebenso kann ich den SplashScreen erst nach erfolgreicher Beendigung des letzten Commands ausführen. Auf der anderen Seite können aber auch manche Module parallel geladen werden -- leider fällt mir hierzu gerade kein Beispiel ein

Daraus resultiert jedenfalls, dass ich zwischen den Commands Abhängigkeiten einbauen muss, sodass der CommandProcessor das entsprechend beachten und automatisch parallel ablaufende Commands erzeugen kann. Hierzu fällt mir nur ein, dass jede Command-Klasse eine ID und eine "required Commands"-Eigenschaft erhält -- Eventuell kann man dies auch über Klassen-Attribute erledigen. Über diese Eigenschaften steuert der CommandProcessor dann alles.

Nun, wie aber läuft das mit der Registrierung der Command-Klassen/-Instanzen beim Processor ab? Hier brachte mich

Stefan Glienke auf die ganz nette Idee, das ganze vollautomatisch über Klassen-Attribute laufen zu lassen und so via RTTI alle Klassen und deren Attribute auszulesen. Ist eine Klasse von einem speziellen Typ (z.B. TStartupCommand) abgeleitet oder wird ein gewisses Interface (z.B. IStartupCommand) implementiert und wird ein spezielles Attribute verwendet, so ist dies eine Command-Klasse, welche beim Start instanziiert und ausgeführt werden muss -- das einzige, was der Entwickler hier noch machen muss, ist die "Execute"-Methode der Command-Klasse zu implementieren. Über die Attribute sollen sich dann auch noch diverse Einstellungen der Commands steuern lassen -- Beispiel: Ein Command-Klasse muss zwei mal instanziiert werden, mit jeweils unterschiedlichen Einstellungen.

Ich hoffe, dass ihr nun ein Bild davon habt, was ich mir unter einem Start einer Anwendung so vorstelle. Natürlich ist das Konzept darauf ausgelegt, komplexe Starts sinnvoll zu managen, weshalb dieses für kleinere Projekte eher flach fällt, aber auch genutzt werden können soll -- daher so viel (beinflussbarer) Automatismus wie möglich.

So, spätestens an dieser Stelle würde mich interessieren, wie ihr dieses Konzept findet UND wie ihr eure Starts organisiert? Habt ihr Verbesserungsideen? Oder gibt es einen Punkt, den ich gar nicht beachtet habe und der das Konzept schon im Kern scheitern lässt?

**Mavarik**

hmm

Ich sehe die Notwendigkeit nicht...

SplashScreen... mag nicht schlecht sein, falls die Programm Initialisierung länger dauert...

Die meißte Zeit wir mit Sicherheit in den Init-Teilen der Units "verbraten"... Also ist das auch bei jedem Programm anders...

Mavarik

Also ein einheitliches Startverhalten ist schon eine feine Sache, zumal die einzelnen Operationen voneinander abhängen. Aber wozu denn Threads?

Meine Anwendungen bestehen eigentlich immer aus einem Datenmodul und einem Hauptbild (klar, und 10000 Dialogen). Das Datenmodul wird im Konstruktor des Hauptbildes instantiiert. Die Dialoge erst, wenn ich sie benötige.

Wenn ich unbedingt einen Splash brauche, dann nehme ich ihn und lasse jedes einzelne Modul, das meint, beim Hochfahren etwas melden zu müssen, meinem Splash mitteilen 'Nächster Schritt: Foobar'. Wenn ich die Anwendung das erste mal durchlaufen habe, weiss ich auch, wie viele Schritte es waren und kann dann beim nächsten Mal einen Fortschrittsbalken anzeigen. Das geht automatisch. Animierte Splash-Screens mache ich erst, wenn ich mehr als 10 Kopien meiner Anwendung verkaufen sollte.

Das Datenmodul wird zuerst einen Logger instantiieren und Konfigdaten einlesen. Danach wird dann ggfs die Datenbank angesprochen oder eine Datei eingelesen oder sonstwas.

Wenn das DM fertig mit initialisieren ist, kann das Hauptbild weitermachen (das DM wurde ja im Konstruktor des Hauptbildes aufgerufen).

Im OnShow des Hauptschirms starte ich einen Timer, der das Splash nach 500ms schließt. Sieht schicker aus.

**neo4a**

Ich fürchte, dass Du Dir mit einem Command-Processor nur eine zusätzliche Abstraktionsschicht einfängst, ohne das eigentliche Problem (lange Ladezeit des Programms) zu lösen.

Vielleicht ist es ein pragmatischerer Weg, erst einmal zu modularisieren, indem man alle Funktionsbausteine per Dependency Injection verwaltet. Du weißt ja, dass dabei sich die Klassen zuerst einmal nur beim DI-Container registrieren und erst bei Bedarf/Anforderung instanziiert werden. Je nach Aufbau der App kann das schon einmal zu einer Verteilung der Initialisierungszeiten führen.

Ist die App erst einmal so modularisiert, kann man sich jeden einzelnen Baustein einzeln "vornehmen" und schauen, inwieweit sich dessen Initialisierung mit halbwegs vertretbaren Aufwand auslagern lässt.

**jaenicke**

Meine Lösung für den Anwendungsstart sieht so aus, dass ich die einzelnen Module ebenfalls aufteile und parallelisiert laden lasse. Dabei gibt es definierte Abhängigkeiten ähnlich denen von Windows Diensten. Diese werden geprüft und ggf. auf deren Ladeende gewartet. Sobald ein Modul angefordert wird, wird dessen Priorität in der Warteschlange erhöht. Dabei werden solche Module bevorzugt, die als für eine Reaktion der GUI notwendig markiert wurden.

Auf die Weise kann ich das Hauptformular bereits anzeigen bevor alle Module fertig geladen sind. Wird dann eine noch nicht geladene Funktion angefordert, wird deren Start priorisiert, aber in der Regel laden die Module einfach im Hintergrund weiter während der Benutzer die Basisanwendung bereits bedient.

So konnte ich bei einer Anwendung, die vorher 3 Minuten zum Start brauchte, die Startzeit bis der Nutzer im Hauptfenster ist auf ca. 2 Sekunden verringern. Bis alles fertig geladen ist dauert es nun rund 4 Minuten, weil die Organisation der Module usw. etwas Zeit kostet. Die Anwendung lässt sich aber auch direkt nach dem Start bereits ohne größere Verzögerungen bedienen.

**s.h.a.r.k**

Danke schon mal für eure Antworten! Ja, ich mag einen animierten SplashScreen, daher arbeite ich auch mit verschiedenen Threads. Parallelität aber auch daher, da es einen Geschwindigkeitsvorteil bringen kann. Und warum sollte ich meinem CommandProcessor keine Threads beibringen, wenn Dinge parallel laufen könnten? Wenn ich eine so allgemein Lösung implementieren kann, dass sie auf fast beliebige Szenarios anwendbar ist, ist das doch nur ein Vorteil? Klar, ich handle mir hier etwas Komplexität ein, aber ich komme schon fast nicht mehr ohne Threads aus.

@jaenicke: Die Idee, die du da verfolgst ist doch relativ interessant. Ich habe bisher allerdings noch keine so lange Initialisierungsphase(n) zu bewältigen

Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?

**jaenicke**

Zitat von s.h.a.r.k:

Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?

Die Abhängigkeiten werden in einem zentralen Verwaltungsobjekt über eine Klassenmethode registriert.

Derzeit ist das Konzept stark in dem Programm verwurzelt. Und hat auch ein paar unschöne Stellen. Wenn, dann würde es sich lohnen das zumindest teilweise neu zu schreiben. Bisher war das bei mir aber auch das einzige Programm, das das brauchte. Ich hatte aber schon vor in der Richtung weiter zu forschen. (In den Stunden zwischen 24:00 Uhr und 0:00 Uhr oder so vielleicht...

hab einfach keine Zeit...)

**Iwo Asnet**

Das einzige mal, als bei mir eine Anwendung 2-5 Minuten zum Hochfahren brauchte, war eine Adressdatenbank mit ca. 100.000 Einträgen im Spiel, welche eine Livesuche ("while you type") ermöglichte. Das Laden der 20MB und die Query selbst dauern nun mal.

Aber anstatt irgendetwas zu parallelisieren, habe ich die Ladezeit einfach verringert, und zwar auf 20 Sekunden: Einfach die Query optimiert und ADO etwas umgebogen. Das Laden wurde in einen Dienst ausgelagert. Der liest die Daten zum Programmstart ein und hält eine lokale Kopie (natürlich up-to-date) im Speicher. Die eigentliche Anwendung ist nunmehr in 1-2 Sekunden vollständig lauffähig, ohne das im Hintergrund noch etwas werkelt.

Ich kann mir keinen Fall vorstellen, bei dem eine Anwendung mehrere Minuten zum Initialisieren benötigt und wo man nicht durch scharfes Hinsehen (ohne Threads) ansetzen könnte. Was dann als notwendiges Übel übrig bleibt, kann von mir aus in einen Thread (oder in mehrere).

Weiterhin verstehe ich nicht, das man eine Anwendung schon bedienen kann, aber die notwendige(?) Initialisierung trotzdem 4 Minuten dauert, oder schaufelst Du präventiv alle eventuell notwendigen Daten in den Speicher?

Ich meine, ich kann mir auch parallel von 20 Anbietern jeweils 10 Tonnen Lebensmittel bestellen, obwohl ich ja eigentlich nur ab und an ein belegtes Brot essen will.

Ich will hier nix gegen Threads zum Programmstart sagen, denn schaden tut sowas ja nicht. Auch der Ansatz von Jaenicke ist vollkommen OK: Er vermeidet beim 'on demand fetching' meist das erstmalige Warten, da dies i.A. schon im Hintergrund erledigt wurde: Schick.

Aber bevor man zu irgendwelchen Tricks greift, um etwas schneller zu machen (Threads sind hier 'Tricks'), sollte man mal prüfen, ob das nicht eleganter geht. Ebenso wie Neo4a bin ich der Ansicht, das eine schlechte Performance zuforderst mit einer guten Struktur bekämpft werden kann.

**Mavarik**

Die meisten Anwendungsprogramme werden doch einmal gestartet und laufen dann den ganzen Tag...

Dann dauert das jeben mal ein bischen...

Ist ne gute Möglichkeit um den Kunden mal wieder nen schnelleren Rechner zu verkaufen...

In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...

Mavarik

**MGC**

Also für mich hört sich das eher nach einem Konzept für Programme an, welche durch ein PlugIn-System beständig erweitert werden kann und man dennoch keine Performance-Einbußen im Startvorgang hinnehmen muss.
Für mich hört sich dieses Konzept sehr interessant an, da ich selbst Programme am Laufen habe, die aufgrund neuer benötigter Funktionalität mal eben nebenher erweitert werden müssen, ohne zum einen die Start-Performance durch neue PlugIns zu stören und zum anderen eben die Möglichkeit zu nutzen das Grundprogramm schnell an neue Labor-Situationen oder Updates unseres kommerziell erworbenen LIMS-Systems anzupassen und entsrepchend reagieren zu können ohne jedesmal das Hauptprogramm neu stricken zu müssen.
Dabei ist zu beachten das in vielen Betrieben sogar noch Single-Core-Prozessoren im Einsatz sein können.