OutOfMemory (OOM) Crash

This issue is a collection for all OOM (OutOfMemory) related crashes, as the number of duplicates regarding this topic is getting out-of-hand. Further crash reports with a stacktracte similar to the one attached below will be marked as duplicate and linked to this issue.

In general, these are the known areas in v0.3.10 which are most likely the sources of OOM crashes and which need fixing for v0.3.11 and beyond:

• Suggestions (Primary target for v0.3.12 development): The suggestions code’s memory management is not great and will be replaced soon by other, more efficient methods. It is planned that the new implementation is written in C++, which avoids unnecessary overhead of the JVM and thus the memory usage should be much lower.
• GlideTyping (Partially fixed since v0.3.11): The most relevant memory leak (and really big resource hog) has already been fixed in #625, smaller memory leaks of event listeners will be fixed later.
• Clipboard manager/history: Currently unknown severity, but it seems also here are some memory leaks.
• LayoutManager (Fixed since v0.3.11): The layout manager does a pretty good job at caching and preventing memory leaks, though the loading of layout json files can be improved to lower the stress on the CPU and to avoid potential garbage. See PR #734 for details.
• Re-initialization when rotating the screen (Partially fixed since v0.3.11): The re-initialization of the service class when rotating the screen has some pretty nasty memory leaks and thus over the time a lot of garbage accumulates which also leads to OOM errors.
• Settings UI: Even though this is a small memory leak and definitely not relevant considering the garbage the above areas accumulate, the Settings UI has some small memory leaks as well which should be fixed.

To help keep this thread clean, please do not post your OOM stacktrace in here or as a new issue. OOM stacktraces can be relevant but the app may crash in any place as soon as it has run out of RAM and by now I am aware of the biggest resource hogs in FlorisBoard. Should you have crash reports not involving a OOM stacktrace, you can of course submit a new issue!

---

java.lang.OutOfMemoryError: Failed to allocate a 24 byte allocation with 2027432 free bytes and 1979KB until OOM, target footprint 268435456, growth limit 268435456; failed due to fragmentation (largest possible contiguous allocation 24379392 bytes)
	at kotlin.reflect.jvm.internal.KParameterImpl.getType(KParameterImpl.kt:43)
	at kotlin.reflect.jvm.internal.KCallableImpl.callDefaultMethod$kotlin_reflection(KCallableImpl.kt:137)
	at kotlin.reflect.jvm.internal.KCallableImpl.callBy(KCallableImpl.kt:112)
	at com.squareup.moshi.kotlin.reflect.KotlinJsonAdapter.fromJson(KotlinJsonAdapter.kt:111)
	at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
	at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)
	at com.squareup.moshi.CollectionJsonAdapter$2.fromJson(CollectionJsonAdapter.java:55)
	at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
	at com.squareup.moshi.CollectionJsonAdapter.fromJson(CollectionJsonAdapter.java:81)

[Flam3z]

As a long time user of your amazing app I am grateful that you put so much time into the app, listening to the community and squashing bugs like your life depends on it. Tysm

[patrickgold]

I’ve finally reached the stabilization phase of #734, which is a major rework of the layout engine and addresses core memory and performance issues (see https://github.com/florisboard/florisboard/pull/734#issuecomment-828101955 for details what is addressed and what not). If you want to try out the debug build, you can download it here. Be aware that the touch logic is still a bit wonky and that glide typing, gestures and emojis don’t work in the current debug build, which I will fix in the next two days. If you have feedback about the debug build, feel free to comment in #734! I will directly use it to improve the PR’s changes before merging into master.