WAI
Status Update
No update yet.
Comments
si...@google.com
Also spent a good chunk of time debugging memory leaks in our apps and discovered the same thing. Upgraded all the way to `compose:1.3.0-alpha03` and `activity-compose:1.6.0-beta01` with the same leaks.
lp...@google.com
This is a significant issue. Every app that integrates compose with an Activity will leak that Activity.
We automated a test to switch back and forth to an Activity for about 15 minutes. Attached screenshots of our results.
170 Leaks for referencing compose `setContentView` inside an Activity.
We automated a test to switch back and forth to an Activity for about 15 minutes. Attached screenshots of our results.
170 Leaks for referencing compose `setContentView` inside an Activity.
so...@google.com
To workaround, we switched to Compose Navigation, which uses a single Activity. - https://developer.android.com/jetpack/compose/navigation
We ran the same automated test switch back and forth between screens for about 15 mins. Attached screenshots of our results.
0 Leaks.
We ran the same automated test switch back and forth between screens for about 15 mins. Attached screenshots of our results.
0 Leaks.
si...@google.com
Are there any updates on this issue?
Our app relies on a lot of interop with ComposeView, and this leak has been causing issues and slowing down our integration with Compose.
Any help is much appreciated!
ni...@google.com
This is a huge bug and the memory keeps growing
ma...@google.com
Do we know if this is fixed in Compose 1.3.0 or 1.3.1 ?
Has anyone (or OP) tried repro-ing with those versions yet?
Thanks
si...@google.com
FWIW, just tried to repro the leaks with Compose + Compose Compiler 1.3.1 and the leaks seem to have stopped.
Would love confirmation about this being fixed in 1.3.1 just to be sure.
si...@google.com
I'm use the latest BOM and the leak still happen. I believe the BOM uses Compose Compiler 1.3.1.
lp...@google.com
so...@google.com
I'm still seeing a similar issue when using the 2022.12.00 BOM.
Our case:
- Single activity navigating to multiple fragments using a replace transaction
- Each fragment creates a single ComposeView, calling `setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)`
- After navigating back from a fragment (so a fragment is fully destroyed) then leakcanary highlights this leak.
Have also tried manually calling ComposeView.disposeComposition when the view is destroyed but leak still occurs.
Our case:
- Single activity navigating to multiple fragments using a replace transaction
- Each fragment creates a single ComposeView, calling `setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)`
- After navigating back from a fragment (so a fragment is fully destroyed) then leakcanary highlights this leak.
Have also tried manually calling ComposeView.disposeComposition when the view is destroyed but leak still occurs.
ap...@google.com
I also spend many time in profile view try to see my activities are relased by Garbage Collector , and force it to garbage , but they always there. never released. So in a big aplication with many activities this a high price to pay, and even you can crash the hole aplication if you decide to migrate standar xml layouts to compose views.Until we have a solution for this problem
ma...@google.com
Im not sure but perhaps the problem is a composable can have lambda functions, and in some cases this could leak the activity if the expression mamipulates members data, because it holds a reference to it
See this link
https://stackoverflow.com/questions/42271208/kotlin-safe-lambdas-no-memory-leak
See this link
Description
Currently higher level components like
FilledTextFieldoffer aplaceholderslot, but foundation's TextField does not. Would we consider adding this?