fix memory leak in CompositeWithOpaqueBackground #4150
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
charlag
approved these changes
Dec 7, 2023
Tak
approved these changes
Dec 7, 2023
nikclayton
added a commit
to nikclayton/pachli-android
that referenced
this pull request
Dec 9, 2023
Quoting @connyduck in tuskyapp/Tusky#4150: """ The transformation ends up in Glide's memory cache and leaks whole Activities through the view -> context reference. This fixes the problem by removing the background detection logic (so the view reference is no longer needed) and setting the background directly instead. Looks exactly as before. """
nikclayton
added a commit
to pachli/pachli-android
that referenced
this pull request
Dec 9, 2023
Quoting @connyduck in tuskyapp/Tusky#4150: """ The transformation ends up in Glide's memory cache and leaks whole Activities through the view -> context reference. This fixes the problem by removing the background detection logic (so the view reference is no longer needed) and setting the background directly instead. Looks exactly as before. """ Co-authored-by: Konrad Pozniak <[email protected]>
connyduck
added a commit
that referenced
this pull request
Dec 10, 2023
…eton (#4153) Another fix for a memory leak. This one is not as big as #4150, but still worth fixing for memory constrained devices imo. The `DrawerImageLoader` implementation (a global singleton) references a member of the `MainActivity`, causing the whole activity to leak. This weird construct was introduced in #1989 to fix a crash, but I think since we migrated to coroutines it is no longer necessary because all calls get correctly cancelled. I tried reproducing the crash but could not, so I'm pretty sure it is fine. I would appreciate it if someone else could try it as well though. (The crash could be reproduced on slow internet, when `onFetchUserInfoSuccess` was called while the activity was being destroyed, causing Glide to crash the app because it can't use destroyed activities. `onFetchUserInfoSuccess` is now no longer called in this case because it is inside a `lifecycleScope.launch` block.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Found with Leak canary: The transformation ends up in Glide's memory cache and leaks whole Activities through the view -> context reference.
This fixes the problem by removing the background detection logic (so the view reference is no longer needed) and setting the background directly instead. Looks exactly as before.