Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
as...@google.com <as...@google.com> #2
After creating the issue I've noticed that I mixed up a few terms, sorry about that. JobService should be JobScheduler. When referring to jobs in the description, those are classes extending Worker.
br...@monzo.com <br...@monzo.com> #3
We have a large set of users seeing this same issue... I can confirm that it seems to only effect users using Android OS 4.4 - 5.1. We are also using WorkManager 2.0.0
as...@google.com <as...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes: b/129226383
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
https://android-review.googlesource.com/933140
https://goto.google.com/android-sha1/098c163581a360c32baa6e4c215227f0efd10889
Branch: androidx-master-dev
commit 098c163581a360c32baa6e4c215227f0efd10889
Author: Rahul Ravikumar <rahulrav@google.com>
Date: Mon Mar 25 14:05:34 2019
Reset WorkConstraintsTracker when cleaning up in DelayMetCommandHandler.
* DelayMetCommandHandler would previously not cleanup correctly and WorkConstraintsTracker
would trigger callbacks without going through the SystemAlarmDispatcher lifecycle
of processing a command.
Fixes:
Test: Added a unit test.
Change-Id: Id2aaf0cce7c4a1a4526a25a211f3fe0551dbe557
M work/workmanager/src/androidTest/java/androidx/work/impl/background/systemalarm/SystemAlarmDispatcherTest.java
M work/workmanager/src/main/java/androidx/work/impl/background/systemalarm/DelayMetCommandHandler.java
br...@monzo.com <br...@monzo.com> #5
Great to see such a quick fix. Do you have any estimate when a new version that includes this change will be released?
ap...@google.com <ap...@google.com> #6
It should be available in the next 2.x.x version.
br...@monzo.com <br...@monzo.com> #7
ETA?
na...@google.com <na...@google.com> #8
Hi, we have implemented a new big feature using WorkManager and got the same issue. We have been considering third party alternatives because we need to deliver this ASAP. But if you confirm that we will have that version within next few days we can wait for it.
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!