[Potential Issue] High memory usage

[totchi-lagawi]

Kvaesitso uses around 200 Mb of memory.

As of the small size of the app and its natively-coded natures (no heavy VM like electron), I'm not sure wether it's normal or not. Other apps aren't using that much memory (except the system itself or the interface of course).

That may be completely normal, but it looks like a bit strange, and I couldn't find any issue reporting it.

[gaabster]

Sadly I have to confirm that the memory usage is quite high. Just look at the image below.

Details

This screenshot was taken right after restarting my phone. Also I don't know if it's related but the app drawer is a bit laggy when scrolling.
I should add that it doesn't matter if there are widgets on the screen or not. The memory usage is almost the same.

Edit. Used wrong image.

[totchi-lagawi]

Does anyone have any idea about why it is using so much memory?

[derei]

Yep, is a bit extreme.

[totchi-lagawi]

I do not really know that concept, but could it be a memory leak?
I'm not a developer at all, hence I may not fully understand that kind of thing, and I could be completely wrong.

[gaabster]

It seems to have settled at around ~500MB. Is it normal for a launcher setup with two widgets to use this much memory?

[exstntlmsnthrp]

I don't think that 500mb or less is that much. That being said, it's never that high for me. I've got 5 active widgets and it's usually less than 200mb for me.

Does it have something more to do with the Android version or device?

[derei]

@exstntlmsnthrp Half a GB is not much? I've got very few programs on my workstation PC that need so much RAM, and they are mostly specialized software. This is supposed to be a launcher on a phone. And phones come in all configurations. For some, 500MB is half of the available RAM.

[exstntlmsnthrp]

Yes, I understand phones come in more configurations than is imaginable. Whilst it doesn't mean they don't exist, I've not seen any phones in the past 5 years with 1gb of RAM.

And I'm not sure what you do with your PC. On my desktop PC, the web browser alone uses 1.5gb of memory when it's idle, not even during active use.

As you can see in my screenshot above, the app never uses that much for me. The maximum I've seen kvaesitso use on my device is 198mb, which I personally feel is acceptable given that location is enabled, weather is enabled, and I have 5 active widgets. But that's the high for me, not average.

Please consider this may be device related and not necessarily app related. I acknowledge, there might be a memory leak, but until @MM2-0 responds, we are only guessing as to whether or not they have already done testing for memory leaks.

[derei]

@exstntlmsnthrp Yes, around 150-200 MB I'd also consider acceptable. I wonder what takes so much on mine, though. I've got 6 widgets, if you count the clock and Favorites.

My device is Pixel 7Pro, running GrapheneOS. Perhaps we need to collect data from users, to see if there is a pattern, if certain devices or ROMs are more susceptible... 🤔

P.S. I left browsers out from my example, because now is common knowledge that browsers chug RAM. And is mostly for running each tab as separate process. But other than browsers, I'm running CAD, 3D modelling, Graphics and Photo editing software. And those are the only ones memory hungry. Everything else is under 300MB.

[totchi-lagawi]

I'm using a Sony Xperia 10 IV, with stock android 14 (65.2.A.2.137).

For now, I only use the weather, the playing and the duolingo widget.

[MM2-0]

I think the biggest part is icons. I don't quite understand why the returned icons have a size of 378x378, but that's about 378 * 378px * 4 bytes/px = 500 kB per icon which adds up quite a lot. That's definitely something I need to look into some day.

If you want to do your own investigations, you can create a memory dump from Settings > Debug and analyze it in Android Studio (but please don't share the dump, it potentially contains very sensitive data).

Anyway, RAM is so cheap these day, it's rarely worth it to optimize for it.

[exstntlmsnthrp]

@derei Interesting, I'm using the same phone. Granted, I'm no longer using Graphene, I had to switch back to stock, because of work.

This is only anecdotal, but based on other comments here on GitHub, I'd suspect there may be something related to how Graphene "optimizes" apps and limits what apps can do.

Although, as I write this, that doesn't explain why other users on stock also seem to be having a similar issues to you. It's a little confusing.

Though what @MM2-0 suggested does make a lot of sense to me.

[OmegaSunkey]

Does anyone have any idea about why it is using so much memory?

Notification Listeners add an extra memory usage. You can try it with most launchers and you'll see they start to use more memory than expected.

If you disable it, you'll see that Kvaesitso goes into the background as a cache process with lower memory usage.

[totchi-lagawi]

About 110Mb. Why is a notification listener using so much memory?

Idk how the app works under the hood, but maybe it could only cache one type of icons, depending of the device's dpi, if not already implemented, to lower the memory usage.

[gaabster]

I feel like this fits here, but maybe I should open a new issue?

OK so Kvaesitso was using more and more memory and this morning it eventually just crashed.
Yesterday it was at around ~600MB. Before the crash I changed cards shape from cut to rounded, I also played with icon size and number of columns andthe memory usage went up to ~800MB. Reverting the settings back didn't help. The app drawer was impacted the most. It was just a slide show, and some actions would take several seconds to complete. Other than that it seemed to work OK.
Just before the crash the usage went up to around ~1GB and it went OOM:) See images below.

Memory usage.

Strack trace

java.lang.OutOfMemoryError: Failed to allocate a 780 byte allocation with 815016 free bytes and 795KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC.
	at java.lang.Object.internalClone(Native Method)
	at java.lang.Object.clone(Object.java:280)
	at android.icu.impl.coll.CollationSettings.clone(CollationSettings.java:102)
	at android.icu.impl.coll.CollationSettings.clone(CollationSettings.java:26)
	at android.icu.impl.coll.SharedObject$Reference.copyOnWrite(SharedObject.java:140)
	at android.icu.text.RuleBasedCollator.getOwnedSettings(RuleBasedCollator.java:351)
	at android.icu.text.RuleBasedCollator.setStrength(RuleBasedCollator.java:692)
	at java.text.Collator.setStrength(Collator.java:349)
	at de.mm20.launcher2.search.SavableSearchable$DefaultImpls.compareTo(SavableSearchable.kt:31)
	at de.mm20.launcher2.applications.LauncherApp.compareTo(LauncherApp.kt:2)
	at de.mm20.launcher2.applications.LauncherApp.compareTo(LauncherApp.kt:3)
	at kotlin.comparisons.ComparisonsKt___ComparisonsJvmKt.compareValues(_ComparisonsJvm.kt:13)
	at de.mm20.launcher2.ui.launcher.search.SearchVM$search$1$1$1$resultsList$1$invokeSuspend$$inlined$sortedBy$1.compare(Comparisons.kt:21)
	at java.util.TimSort.countRunAndMakeAscending(TimSort.java:360)
[9 lines truncated]

Device info

APP.VERSION : 1.30.4
APP.VERSIONCODE : 2024051000
APP.SIGNATURE : rx1fSnL7r5/OMoFC0e1KPqTndXQ=
LAUNCHER.APP : de.mm20.launcher2.release
TIMEZONE : Europe/Warsaw
VERSION.RELEASE : 14
VERSION.INCREMENTAL : eng.nobody.20240512.170248
VERSION.SDK.NUMBER : 34
BOARD : msm8998
BOOTLOADER : unknown
BRAND : Xiaomi
CPU_ABI : arm64-v8a
CPU_ABI2 :
DISPLAY : AP1A.240505.005 release-keys
FINGERPRINT : Xiaomi/chiron/chiron:8.0.0/OPR1.170623.027/V9.5.4.0.ODEMIFA:user/release-keys
HARDWARE : qcom
HOST : android-build
ID : AP1A.240505.005
MANUFACTURER : Xiaomi
MODEL : Mi MIX 2
PRODUCT : lineage_chiron
TAGS : release-keys
TIME : 1715526167000
TYPE : user

[derei]

@MM2-0 , what @gaabster is reporting looks a lot like a memory leak. Perhaps it should be investigated?

[gaabster]

And I had another OOM crash.

Strack trace

java.lang.OutOfMemoryError: Failed to allocate a 40 byte allocation with 1130048 free bytes and 1103KB until OOM, target footprint 201326592, growth limit 201326592; giving up on allocation because <1% of heap free after GC.
	at android.view.InsetsState$1.createFromParcel(InsetsState.java:812)
	at android.view.InsetsState$1.createFromParcel(InsetsState.java:809)
	at android.os.Parcel.readTypedObject(Parcel.java:4162)
	at android.view.IWindow$Stub.onTransact(IWindow.java:267)
	at android.os.Binder.execTransactInternal(Binder.java:1501)
	at android.os.Binder.execTransact(Binder.java:1440)