Slow startup time of app initialization and logic

Short description

If i take a long time not using the keyboard (~30min) and if I tried to write something the smart bar will appear and after 3 seconds or so the elemnts of keyboard will apear(letters). Also, when I click the emoji button it lags for 3 or 4 seconds also. Note: This often happened but when I used ignoring battery optimization and helped reduce how often this happens

Steps to reproduce

1. Do not use the keyboard for some time
2. Try to use the keyboard
3. See the bug

Environment information

• FlorisBoard Version: 0.3.14-rc01
• Install Source: F-Droid
• Device: Condor P6 pro
• Android: 7.0 ``

[patrickgold]

Well, the logcat message is now gone and, though I hope this is not placebo (I think it’s not), I can see the app starting up faster and being responsive right away. Nice job! It seems to me that performance got a little boost in general. I’m interested to hear what others will notice too after the next beta release.

That’s true, this is something I didn’t even notice until you said it. I think it could be because with #1860 I introduced Proguard optimizations, which strips unused code. Maybe the error comes from one part of the JC library which I don’t use and thus the source of this issue is now gone.

As for performance increase at startup: The beta and release builds I tested seem a bit more responsive and with #1870 there’s a slight improvement again for the startup time. It will be really interesting how the general feedback for this performance improvement is in the next beta release.

Still, the startup time is far from perfect and while testing earlier today I also know why: For every cold start of the app/keyboard, I do very heavy disk read operations (indexing of extensions, mapping layouts, loading extension meta data), only after all that is done the layout manager can read the active subtype’s layout file, parse it and pass it to the UI layer for drawing. The Smartbar does not have to do this, thus the Smartbar appears way quicker than the actual keyboard. This means I have to go full into debugging and improving the way extension indexing works.

Ah hell, so it does have some performance issues. Well, at least the burden is not on you, but on the team working on it, and since it’s a big project, I suppose they work on it intensively.

That’s for the general startup time, yeah. But as mentioned above, I also have to do some fixing, not every ms delayed is caused by JC 😃

What made me some impression while at it, was that it seems fairly easy to run into bad performance through wrong practices (i watched a video by Google with some examples). Or perhaps that’s software in general, so nothing special

Oh yeah, that’s soo true! However that’s absolutely not specific to Android development, but software in general 😃

[tsiflimagas]

Well, the logcat message is now gone and, though I hope this is not placebo (I think it’s not), I can see the app starting up faster and being responsive right away. Nice job! It seems to me that performance got a little boost in general. I’m interested to hear what others will notice too after the next beta release.

Generally though the JC library is (sadly) known for having a not so great startup time even for empty hello world projects, so the library may be parts of the slow startup time.

Ah hell, so it does have some performance issues. Well, at least the burden is not on you, but on the team working on it, and since it’s a big project, I suppose they work on it intensively.

Thanks for bringing this topic up, this is something new to me! I looked up the baseline profiles and there seems to be a real performance increase possible when generating the baseline profile correctly.

Oh, good to see that it can be useful! I bumped into it while searching about JC and performance. What made me some impression while at it, was that it seems fairly easy to run into bad performance through wrong practices (i watched a video by Google with some examples). Or perhaps that’s software in general, so nothing special 😄