You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the mobile app (Android) starts, it freezes for 2-3 seconds. It seems to be during the starting process in the background because sometimes it freezes, then display the list of note, or display the list of notes then freezes.
It would be good to benchmark the boot process and see what may be taking time. As a first step it could be done using the "perfTimer" from @joplin/utils - various sections of the code would be wrapped in timerPush/timerPop and that should tell us, by looking at the log on device, what parts are slow.
The text was updated successfully, but these errors were encountered:
It seems to be during the starting process in the background because sometimes it freezes, then display the list of note, or display the list of notes then freezes.
If this is being observed with a particular installation of the Android app,
Certain large plugins can cause the app to freeze on startup, when the plugin tar file is extracted.
If this is the case, the timestamps on the logs near PluginService: Loading plugin from... may provide information about the issue.
If only observed during dev mode, this could be related to the startup tests.
It's observed on the live app on my phone. I'm going to check for the plugin startup but I assume that's not it as it's been doing this for a long time.
Edit: Just to be sure I tried disabling all my plugins and that didn't make a difference. The startup time of the plugins doesn't seem excessive although it's not printed exactly how long it takes.
When the mobile app (Android) starts, it freezes for 2-3 seconds. It seems to be during the starting process in the background because sometimes it freezes, then display the list of note, or display the list of notes then freezes.
It would be good to benchmark the boot process and see what may be taking time. As a first step it could be done using the "perfTimer" from
@joplin/utils
- various sections of the code would be wrapped intimerPush/timerPop
and that should tell us, by looking at the log on device, what parts are slow.The text was updated successfully, but these errors were encountered: