A screen freezes on first render or during navigation, and Compose UI gets blamed. But sometimes the real culprit is hiding in the dependency graph: an expensive component resolved at the wrong moment, initialization landing on the main thread, or a dependency whose cost only becomes visible when the screen needs it. This talk investigates that failure in two acts. First, the UI crime scene: what actually happens on the main thread during composition, layout, and screen startup, and why apparently harmless dependency access can suddenly become visible as jank or an ANR. Then we follow the trail into DI: ViewModel injection at screen startup, lazy as the usual first fix and why it can simply move the problem, and how scoping, component lifetimes, and module boundaries determine when your application pays the cost of building its dependency graph. Along the way, we'll instrument the boundary between DI and rendering to measure resolution and blocking time instead of guessing. The investigation ends with real production cases: the original symptom, the traces that exposed the culprit, the architectural fix, and the measured before/after impact. The examples are Android-first, but the same dependency-resolution and rendering dynamics apply directly to Kotlin Multiplatform and Compose Multiplatform. By the end of this talk, you'll know how to identify dependencies that threaten screen startup, understand why common fixes sometimes only move the problem around, and prove the improvement with production data. Key takeaways: - Spot when DI work is blocking the UI - Understand when lazy helps and when it only moves the problem - Measure DI impact with instrumentation, not assumptions - Use scoping and architecture to control when dependency costs happen - Apply the same reasoning to Android, KMP, and CMP