feat(web): optimization via lazy preprocessing of keyboard touch-layout info ⏩

[jahorton]

Follows #11264, addressing part of #11166.

How can we go "further beyond" with OSK loading speed than not building all of its layers initially? Why, by not even pre-processing all of its layers initially! This PR extends the just-in-time (JIT) behavior from the prior PR by only preprocessing layer-specifications as they're needed.

So, revisiting that gff_amharic stress-test from #11263, performed on a SM-T350 / Galaxy Tab A...

Loading time "before": between 3.5 to 4 seconds.

Loading time "after": 1.2 seconds, with half of that being keyboard-script load.

To be clear, underneath the visible buildLayer and getLayer stackframes in the second ("after") image, the visible s...e is sanitize, with the sliver to its right being polyfill. This is due to the newly-introduced JIT pattern - both are executing for a single layer, and only once it is needed.

Actual time spent preprocessing & building the OSK element hierarchy: just 120ms. Remember, "before", this section cost us 2.66 seconds! Of course, we'll have to pay that 2.66 seconds over time as we visit every layer... assuming we actually do visit every layer.

Clearly, the easiest way to optimize sanitize is to just... not do it until we have to. One layer isn't that expensive, even on older devices. 42 of them? Now that... that starts to add up. Of course, this does mean that each swap to a previously-unused layer will be a bit slower than before.

---

Other keyboards:

• sil_euro_latin now loads in approximately 764ms, down from 1.1 second as seen in https://github.com/keymanapp/keyman/pull/11140#issuecomment-2036287502.
  • sil_euro_latin automatically swaps to shift with a new context, which was the case for this test. So, it built an extra layer "out of the gate" compared to the other two below.
  • This is also swapping out of gff_amharic, which featured an active lexical model.
• sil_cameroon_azerty - 629 ms.
• khmer_angkor - 689 ms.

So, we're going somewhere around 50% faster (or better!) for keyboard loading with more "conventional" keyboards than we were with #11140, which was already a marked improvement on what came before.

User Testing

TEST_ANDROID_USE: Test the Keyman for Android app using `sil_euro_latin``.

• Forcibly kill and restart the app at least three times during this test.
• Be sure to use a key from every layer during this test.
• Use at least one longpress, one downflick, and one layer-swapping multitap.

TEST_IOS_USE: Test the Keyman for iPhone and iPad app using sil_euro_latin.

• Forcibly kill and restart the app at least three times during this test.
• Be sure to use a key from every layer during this test.
• Use at least one longpress, one downflick, and one layer-swapping multitap.

[keymanapp-test-bot[bot]]

User Test Results

Test specification and instructions

• ⬜ TEST_ANDROID_USE (OPEN)
• ⬜ TEST_IOS_USE (OPEN)

Results Template

``` # Test Results * **TEST_ANDROID_USE (OPEN):** notes * **TEST_IOS_USE (OPEN):** notes ```

Test Artifacts

• Android
  • Keyman for Android apk
  • FirstVoices for Android 16.0 apk
  • FirstVoices Keyboards for Android apk
  • KeyboardHarness apk - build failure
  • Keyman for Android 16.0 apk
  • KMSample1 apk - build failure
  • KMSample2 apk - build failure
• Developer
  • Keyman Developer - build failure
  • Compiler Regression Tests - build failure
  • kmcomp.zip - build failure
• iOS
  • Keyman for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image)
  • TestFlight internal PR build version - 18.0.21 (0.11265.10805)
• Keyboards
  • Test Keyboards - build failure
• Web
  • KeymanWeb Test Home - build failure
• Windows
  • Keyman for Windows - build failure
  • FirstVoices Keyboards for Windows - build failure
  • Text Editor (32 bit) - build failure
  • Text Editor (64 bit) - build failure