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:

Zitat von Rollo62 (Beitrag 1471057)

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:

Zitat von braunbaer (Beitrag 1471254)

.. 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:

Zitat von Rollo62 (Beitrag 1471255)

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.

Delphi-Quellcode:

{$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:

Zitat von KodeZwerg (Beitrag 1471275)

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.

Delphi-Quellcode:

{$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.

[TurboMagic]

1. I glaube es ging hier um iOS? Dann wären Android 10 Änderungen unwichtig.

2. Am SQLite support von FireDAC hat sich in 10.4 ein bischen was getan von wegen
statisch und dynamisch einbinden oder so. Keine Ahnung ob das hier einen Einfluss
hat. Wäre aber wohl zu prüfen.

Grüße

TurboMagic

[Rollo62]

Ja, hatte ich ganz aus den Augen verloren :oops:

Das hier ist auch wieder Android, könnte aber auch auf iOS Auswirkungen haben.

Delphi-Quellcode:

  , FireDAC.Phys.SQLiteWrapper.Stat //23.06.20 added to prevent Rx1040 link error
  // https://stackoverflow.com/questions/62086198/cannot-load-sqlite-libraries-in-android-with-delphi-10-4

[braunbaer]

Zitat:

Zitat von Rollo62 (Beitrag 1471283)

Delphi-Quellcode:

  , FireDAC.Phys.SQLiteWrapper.Stat //23.06.20 added to prevent Rx1040 link error
  // https://stackoverflow.com/questions/62086198/cannot-load-sqlite-libraries-in-android-with-delphi-10-4

Das hatte ich schon integriert.

[braunbaer]

Hallo Zusammen,

ich rolle das Thema nochmals auf, da ich mir nicht vorstellen kann, dass nur ich diese Probleme habe.
Es geht nur um iOS! Bei Android und Windows ist alle korrekt!!

Mit dem IFMXApplicationEventService frage ich den Zustand der App ab.
Das Ereignis: BecameActive kommt da teilweise bis zu 5 Sekunden verzögert.
Danach wird dann weitergemacht und der Synchornisierungsthread mit meinem Cloudserver gestartet.
Dies kann dann bis zu 30 Sekunden dauern, bis dieser anläuft.
Danach läuft alles wieder wie gewohnt.
Normal dauert dies alles nur ein paar Millisekunden!
Auch ein weiteres BecameActive kann dann problemlos sein, das übernächste aber vielleicht schon wieder nicht.

Natürlich habe ich zu Testzwecken eine Jungfräuliche einfache App gebaut und auch dort passiert es genau idient.
Nur die Verzögerungen sind etwas kürzer.

Weiter oben im Thread habe ich von SQLite-Problemen geschrieben. Bin jetzt aber ziemlich sicher, dass es nicht mit der DB zusammenhängt. Habe extra mal in der Test-App IB-ToGo umgebaut und da war das Problem idient!

Die App bleibt in dieser Zeit eingefroren und der User geht von einem Absturz der App aus - das kommt nicht gut an!

Ich habe 3 Apps bei meinen Kunden im Einsatz.
Das Problem trat bei allen Apps auf, nachdem ich diese mit Delphi 10.4 kompiliert habe.
Ich weiss mir leider keinen Rat mehr - Hat mir jemand einen Tipp...

[Rollo62]

Also ich habe festgestellt das eine App im Development(DEBUG) viel zäher, langsamer und deutlich unterschiedlicher sein kann
als die entsprechende AppStore (RELEASE) Version.
Testest Du mit DEBUG oder RELEASE ?

Trotzdem bleibt es auch im DEBUG nicht unbedingt hängen, das ist schon ungewöhnlich.

Legst Du Teile der App schlafen (Timer, Threads, etc.) bei WillBecomeBackground, und
startest sie wieder bei WillBecomeForground/BecameActive ?
Vielleicht läuft da etwas schief.

Ich schalte im Background möglichst Alles ab, es kann eh nicht benutzt werden.

[braunbaer]

Zitat:

Zitat von Rollo62 (Beitrag 1480531)

Also ich habe festgestellt das eine App im Development(DEBUG) viel zäher, langsamer und deutlich unterschiedlicher sein kann
als die entsprechende AppStore (RELEASE) Version.
Testest Du mit DEBUG oder RELEASE ?

Trotzdem bleibt es auch im DEBUG nicht unbedingt hängen, das ist schon ungewöhnlich.

Legst Du Teile der App schlafen (Timer, Threads, etc.) bei WillBecomeBackground, und
startest sie wieder bei WillBecomeForground/BecameActive ?
Vielleicht läuft da etwas schief.

Ich schalte im Background möglichst Alles ab, es kann eh nicht benutzt werden.

Es geht leider um die Apps im Release :(

Und ja, ich beende alles was zu beenden ist (Timer, Threads) und schliesse die FDConnection.
Dies mache ich im FormSaveState. Das ändert auch nichts, wenn ich es im WillBecomeBackground mache.

Immer dasselbe Ergebnis.

[Rollo62]

Dann hilft wohl nur Logging mit Zeitstempel, um rauszufinden wo genau es hakt,
und/oder Alles auseinander zu rupfen, und Stück für Stück neu zusammenzubauen.

[braunbaer]

Zitat:

Zitat von Rollo62 (Beitrag 1480549)

Dann hilft wohl nur Logging mit Zeitstempel, um rauszufinden wo genau es hakt,
und/oder Alles auseinander zu rupfen, und Stück für Stück neu zusammenzubauen.

das mit dem Logging und Zeitstempel habe ich eh gemacht.
Hier sehe ich dann genau, dass die App öffnet aber das BecameActive erst nach ein paar Sekunden kommt - und genau das ist das, was mich so stutzig macht.
Und das eben nicht immer, sondern nur ab und zu, aber viel zu oft!!

[Rollo62]

Ich habe in solchen Fälllen Allles immer sehr modular gehalten,
damit ich es leicht Stück-für-Stück rückbauen kann.
Oder manchmal hilft es auch das Projekt-DPROJ nochmal komplett neu anzulegen,
weil irgendwelche .DPOJ Settings verschoben sind.
Ich hatte schonmal tagelang nach Fehlern gesucht warum es nicht mehr geht,
einmal neu anlegen, und neu Konfigurieren, dann gings.
Frag mich nicht woran es lag ...