Compare AnimatedBuilder and Transition widgets for explicit animations

WHAT THIS TESTS: This question tests whether you understand Flutter's widget rebuild mechanics and how to minimize unnecessary work during 60fps animations. The interviewer wants to see that you know where rebuild boundaries sit and why AnimatedBuilder exists as a performance primitive rather than just a convenience wrapper.

A GOOD ANSWER COVERS: Four things in order. First, the widget tree impact: AnimatedBuilder accepts a builder closure that creates a subtree, meaning only the widgets returned by that builder rebuild when the animation value changes; ancestors and siblings outside the builder are unaffected. Second, pre-built Transition widgets such as SlideTransition or FadeTransition are themselves AnimatedBuilders under the hood, but they wrap a single child widget and rebuild that child on every tick; if that child is a complex subtree, the entire subtree rebuilds. Third, performance implications: because Flutter's element tree diffing is fast but not free, localizing rebuilds with AnimatedBuilder avoids walking large parts of the tree and reconstructing widget objects every 16 milliseconds. Fourth, when to choose which: use a Transition widget for standard effects and simple children, but drop down to AnimatedBuilder when the child is expensive or when you need to animate multiple properties without nesting many transitions.

COMMON WRONG ANSWERS: Saying there is no difference in widget tree impact is the biggest red flag; it signals you have not profiled or thought about rebuild boundaries. Another mistake is claiming that AnimatedBuilder avoids rebuilding entirely; it still rebuilds its builder output, it just limits the scope. Some candidates also confuse this with ImplicitlyAnimatedWidget or TweenAnimationBuilder, which are higher-level APIs that manage their own controllers and are not the focus of the question.

LIKELY FOLLOW-UPS: The interviewer might ask how you would animate a complex ListView item without jank, or why you would use AnimatedBuilder instead of calling setState in a ticker callback. They may also probe whether RepaintBoundary helps here, which is related but solves paint-time issues rather than build-time issues, or ask you to explain how the child parameter in AnimatedBuilder can be used to cache a large subtree.

ONE CONCRETE EXAMPLE: Imagine a screen with a header, a footer, and a centered card that slides in. If you animate the card with SlideTransition and the card contains a Column with twenty Text widgets, all twenty texts rebuild every frame. If you instead use AnimatedBuilder and return only the Transform widget wrapping the Column, the header and footer are stable, and you can further optimize by caching the Column in a final variable passed as child so even the Column's children do not rebuild.