App bleibt beim Re-Start lange eingefroren

[braunbaer]

Hallo Zusammen!
Kennt jemand das Problem, dass seit Delphi Sydney eine App, wenn sie länger im Hintergrund war, bis zu 30 Sekunden braucht bis sie wieder reagiert?
Der Screen bleibt einfach eingefroren. Danach läuft es normal weiter.
So wie ich das beobachtet habe wird das "BecameActive" viel zu spät getriggert.
Das Problem habe ich bei iOS. Android verhält sich normal.

Ich werde jetzt noch eine einfache neue Test-App bauen. Bin gespannt, ob das da auch so ist...

Schon mal Danke für jedes Feedback!

Gebhard

[Rollo62]

Nein, eigentlich nicht.
Vielleicht machst Du etwas beim Aktivwerden (WillBecomeActive), um den Status wiederherzustellen.

Das verschiebe ich immer nachdem BecameActive gefeuert wurde, und die App sichtbar ist.

[braunbaer]

Die Statuseinstellungen der App werden im "BecameActive" gemacht.
hat bis Dato auch einwandfrei funktioniert.
Ich analysiere weiter...

[Rollo62]

Versuch doch mal das einfach 300ms später auszuführen,
dann ist die App gestartet, und es sieht nicht so lange blockierend aus.

[braunbaer]

Zitat von Rollo62:

Versuch doch mal das einfach 300ms später auszuführen,
dann ist die App gestartet, und es sieht nicht so lange blockierend aus.

Hallo Rollo62,
danke für deinen Input.

Ich habe inzwischen den Punkt gefunden, wo alles einfriert.
Das mit TTasks und Threads habe ich schon im Griff, allerdings habe ich die Datenbankzugirffe auf die SQLite im Hauptthread.
Es läuft auch alles sauber und rund, da die notwendigen Datenbankzugriffe in wenigen Millisekunden erledigt sind.

zum Problem:
wenn die App (Zeiterfasssung) etwas Länger im Hintergrund ist, braucht der erste Zugriff auf die SQLite-DB extrem lange (10 - 30 Sekunden).
Danach läufts wieder.
Die SQLite-Datei liegt im LibraryPath. Eventuell ist das das Problem. Ich werde diese in den Documentspath verschieben...

Bin für weitere Tipps immer dankbar.

[Rollo62]

Zitat von braunbaer:

.. im Hintergrund ist, braucht der erste Zugriff auf die SQLite-DB extrem lange (10 - 30 Sekunden).

Erster Zugriff heisst was genau, das erste Öffnen oder das erste SELECT ?
Vielleicht ist es aufschlussreich mal mit TStopWatch die Zeiten in den Before/After Routinen echt zu messen, um zu sehen wo genau es hängt.

[braunbaer]

Zitat von Rollo62:

Erster Zugriff heisst was genau, das erste Öffnen oder das erste SELECT ?

Es ist das erste Öffnen der DB mit dem ersten Select.
ich prüfe das noch, ob öffnen oder Select...

Da dies die letzten 5 oder mehr Jahre immer funktioniert hat und auch auf Android perfekt funktioniert und auch mit Rio perfekt funktioniert hat, denke ich eher, dass es mit Sydney irgend eine Änderung gab.
Leider konnte ich nichts in diese Richtung finden.

Das verschieben der DB in den DocumentsPath hat nichts geändert (wäre auch komisch)

[Rollo62]

Es hat sich ab Android-10 mal wieder Einiges geändert, auch am Filezugriff,
ich suche selber noch nach Ursachen und Lösungen.
Das könnte aber auch das Sqlite-File betreffen

https://developer.android.com/traini...rage/use-cases

Vielleicht hat es was damit zu tun.

[KodeZwerg]

Nicht Cross-Plattform, bei/für Windows setze ich oftmals PE-Flags um das File im Speicher zu halten. Ein Grund könnte ein entladen im Hintergrund sein.
{$SetPEFlags ...FLAGS....}
Hier sind die verschiedenen Flags beschrieben.
IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP und IMAGE_FILE_NET_RUN_FROM_SWAP sind die Flaggen die ich meine.

[braunbaer]

Zitat von KodeZwerg:

Nicht Cross-Plattform, bei/für Windows setze ich oftmals PE-Flags um das File im Speicher zu halten. Ein Grund könnte ein entladen im Hintergrund sein.
{$SetPEFlags ...FLAGS....}
Hier sind die verschiedenen Flags beschrieben.
IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP und IMAGE_FILE_NET_RUN_FROM_SWAP sind die Flaggen die ich meine.

das Problem ist nur bei iOS...
Windows und Android laufen problemlos.