Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
as...@google.com <as...@google.com> #2
I proposed this which I think it is better than the actual behavior, and could let the developers work with more room to be creative.
https://code.google.com/p/android/issues/detail?id=58318
br...@monzo.com <br...@monzo.com> #3
The presentation link doesn't work.
as...@google.com <as...@google.com> #4
In Custom Notification Layouts section of the Notification API Guides, it states: "The height available for a custom notification layout depends on the notification view. Normal view layouts are limited to 64 dp, and expanded view layouts are limited to 256 dp". I guess it means the width is 512 dp and the height is 256 dp (if following the 2:1 aspect ratio)?
http://developer.android.com/guide/topics/ui/notifiers/notifications.html#CustomNotification
br...@monzo.com <br...@monzo.com> #7
Any update on this?
na...@google.com <na...@google.com> #8
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with the bug report here https://goo.gl/TbMiIO and reference this bug for context.
Description
Jetpack Compose version: I've tested on 1.3.0-alpha01 and 1.2.0-beta03
Jetpack Compose component(s) used: LazyColumn
Android Studio Build: 221.3427.89.2211.8689873
Kotlin version: 1.7.10
Steps to Reproduce or Code Sample to Reproduce:
Context:
We have a rather large (10k+ items) LazyColumn where scrolling (eventually) leads to the application grinding to a halt, constantly trying to free memory. It can't, we just keep getting lots of these:
Background concurrent copying GC freed 51964(1414KB) AllocSpace objects, 6(120KB) LOS objects, 0% free, 190MB/192MB, paused 101us total 1.483s
I took at heap dump at this point and basically all of the heap is used up by instances of
SnapshotMutableStateImpl$StateStateRecord
.Replace LazyColumn with a RecyclerView (with each item being a ComposeView) and the memory leak is gone. App performance is night and day better.
I've been trying for hours to reproduce this in a trivial sample project and haven't had any luck yet. Raising this anyway just in case you have any ideas about what might be causing it. Obviously this makes LazyColumn completely unusable for us, so we'll stick to RecyclerView for now!