Anonymized engineering case study

Memory · Fragments · RxJava

Stopping a retained map screen and repeated recreation

Repeated navigation between a map fragment and a detail fragment produced retained work, unnecessary map recreation, and eventually inconsistent loading behavior.

Scope note

This case is anonymized and describes a specific engineering situation. It is not a guarantee that another app will have the same cause, effort, or outcome.

Context

Leak analysis identified retained objects while visual profiling showed the map and custom layers being rebuilt on return. The problem was not visible from a single happy-path navigation.

Investigation

Heap evidence, subscription ownership, fragment and view lifecycles, and navigation behavior were reviewed together. Particular attention was given to RxJava disposal scopes attached to both the view and ViewModel.

Root cause

The subscription lifetime did not match the UI work it controlled. Combining scopes allowed work to survive or be disposed at unexpected points relative to view recreation.

Resolution

The conflicting scope was removed and UI-bound work was attached to a single lifecycle owner appropriate to the screen. Additional loading logs were retained to expose incomplete paths rather than masking them.

Validation

The test repeatedly entered the detail screen and returned to the map while observing retained instances, map initialization, pin rendering, and loading completion.

Engineering takeaway

The practical result was a simpler ownership model and a reproducible validation loop. The case also exposed a second loading-state issue that became easier to diagnose once the leak behavior was removed.

Is a similar Android issue consuming roadmap time?

Share the symptoms and available evidence. You will receive a fit decision before any paid commitment.

Request a fit assessment