Add memory leak examples for Android documentation#920
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive set of code snippets demonstrating common memory leak patterns in Android and Compose, such as retained UI callbacks, improper lifecycle management for Flow collection, and uncleared view bindings. Feedback includes a recommendation to use repeatOnLifecycle for Flow collection in the Activity example to ensure efficiency and consistency with best practices. Additionally, it was suggested to re-categorize the fragment view binding example under Pattern 1 for improved documentation accuracy.
* Add Pattern 1: UI Objects Retained Beyond Lifecycle examples * Add Pattern 2: Background Work Outlives the UI examples * Add Pattern 3: Unreleased External Registrations examples * Include Compose and Fragment-specific memory management best practices * Ensure snippets are idiomatic and comply with Spotless formatting These examples illustrate common architectural pitfalls and their corresponding lifecycle-aware resolutions using Coroutines, Flows, and DisposableEffect.
sudeshim3
force-pushed
the
feature/memory-leak-snippets
branch
from
671a754 to
8e3a6cc
Compare
* Refactor Repository examples to use actual ViewModel implementations instead of commented-out pseudo-code. * Split the recommended Repository callback snippet into pt1 and pt2. * Add explanatory comments to delay() calls clarifying their purpose to emulate network/processing.
AliceYuan
left a comment
AliceYuan
left a comment
There was a problem hiding this comment.
There's still an open question about removing the last view binding example but approving
* Align snippet structure and names with original document's retention chains. * Rename ImageLoader examples to ImagePickerRecommended and ImageCacheRecommended for clarity. * Replace delay() in delayed work examples with api.getUser() for realism. * Add missing Pattern 3 comment in Compose snippets file. * Use repeatOnLifecycle in Activity flow collection.
sudeshim3
force-pushed
the
feature/memory-leak-snippets
branch
from
ffe85be to
535b120
Compare
* Replace AppCompatActivity with ComponentActivity in MainActivityWithLeak and MainActivityRecommended to make the snippets more Compose-friendly. * Update copyright year in snippet files.
| // [START android_compose_performance_memory_leak_location_recommended] | ||
| @Composable | ||
| fun LocationScreenRecommended(locationManager: LocationManager) { | ||
| var locationText by remember { mutableStateOf("Locating...") } |
There was a problem hiding this comment.
It is recommended to use rememberUpdatedState for long-live operations.
There was a problem hiding this comment.
Sticking to the base remember keeps the example easy to read while still being technically correct. My goal was just to show the setup/teardown mechanism without getting bogged down in advanced Compose state mechanics. It will shift the the readers focus from 'how to clean up resources' to 'how Compose handles stale closures in lambdas'
| var locationText by remember { mutableStateOf("Locating...") } | ||
|
|
||
| // DisposableEffect provides an onDispose block for mandatory cleanup | ||
| DisposableEffect(locationManager) { |
There was a problem hiding this comment.
Also, please check LifecycleStartEffect
It shows a location manager example only.
There was a problem hiding this comment.
There are many platform-specific lifecycle handlers that developers should adopt based on their exact requirements. the primary focus of this document is on general memory leak patterns and bringing an understanding of how failing to clean up a UI component causes a leak. Introducing specific lifecycle APIs brings the focus to the example(Location Based app) instead of communicating the concept.
For example: LifecycleStartEffect aggressively tears down on onStop (when the app goes to the background), whereas DisposableEffect keeps a connection alive as long as the component is still in the UI tree. Whether you do it when the app goes to the background, or when your component is getting destroyed, is left for the developer to explore based on their exact needs.
5 participants
These examples illustrate common architectural pitfalls and their corresponding lifecycle-aware resolutions using Coroutines, Flows, and DisposableEffect.