What is Flutter tree shaking and how does it reduce app size?

WHAT THIS TESTS: Your knowledge of the Dart-to-native compilation pipeline and whether you understand the difference between dead code elimination, minification, and obfuscation. Interviewers want to see that you know tree shaking is a compile-time optimization that relies on static analysis, and that you can write code that does not accidentally defeat it.

A GOOD ANSWER COVERS: First, define tree shaking as dead code elimination performed by the Dart compiler during AOT builds. The compiler builds a reachability graph from the entry point and removes unreachable functions, classes, and constants. Second, connect size reduction to the removal of unused library code, especially when importing large packages. Connect performance gains to smaller binaries fitting better in CPU instruction caches and faster startup because less code is parsed and mapped into memory. Third, list concrete practices: avoid dart:mirrors and dynamic invocation because they hide call targets from static analysis; prefer const constructors so the compiler can canonicalize and drop unused instances; avoid importing entire files when only a single function is needed; and warn against packages that use side-effect imports solely to force registration, since the compiler may see no direct usage and strip them. Fourth, mention that Flutter's release build automatically enables tree shaking, but that web builds with dart2js or dart2wasm also use it, though with different constraints.

COMMON WRONG ANSWERS: Calling tree shaking a runtime optimization or confusing it with code minification that only renames variables. Claiming that dynamic language features like reflection still work with tree shaking. Suggesting that manual deletion of files is the same as compiler-level tree shaking. Saying that tree shaking reduces memory usage at runtime by removing widgets from the widget tree, which confuses build-time dead code elimination with runtime UI state management.

LIKELY FOLLOW-UPS: How does tree shaking interact with Flutter web builds compared to mobile AOT? What happens if a package uses dart:mirrors or conditional imports? How would you verify that tree shaking is actually reducing your binary size? Can tree shaking remove unused font or icon assets, and how does that differ from code tree shaking?

ONE CONCRETE EXAMPLE: If you import the entire material icons font but only use ten icons, tree shaking can strip the unused glyph data when combined with the appropriate compiler flags, but only if you reference icons through const IconData and avoid dynamic string lookups. On the code side, importing a large utility library and using only one helper will cause the compiler to discard every unused helper, whereas a single call to a dynamic method on that library could force the compiler to retain everything because it cannot prove what is reachable.