In many UI frameworks, you create custom components by inheriting from a base class and overriding its methods. Flutter takes a different path. Instead of inheritance, it champions composition. Think of it like building with LEGOs. You don't create a new type of brick by melting down an old one; you combine existing bricks—a Row, an Icon, a Text widget—to create a more complex structure.

This shift from "is a" (inheritance) to "has a" (composition) is fundamental. For a bill-scanning app, you wouldn't create a CameraScannerScreen that inherits from a generic Screen. Instead, your screen widget would be composed of a Stack that holds a camera preview widget and an overlay widget for the detected bill outline. This makes the UI flexible and easier to reason about.

Every StatefulWidget in Flutter has a lifecycle, a series of stages it goes through from creation to destruction. Understanding this is key to building performant apps, especially ones that handle real-time data like a camera feed.

When a StatefulWidget is first inserted into the widget tree, the framework calls initState(). This is your one chance to do setup work: subscribe to streams, initialize animation controllers, or set up listeners. It's called only once for the lifetime of the state object.

After initialization, the build() method is called. This is where the magic happens. The build() method's job is to return a widget that describes a part of the user interface. Crucially, Flutter can call this method every single frame—up to 60 times a second. If your build() method is doing heavy lifting, your app's performance will suffer.

Finally, when the widget is permanently removed from the tree, the framework calls dispose(). This is your chance to clean up. Unsubscribe from streams, cancel timers, and release any resources to prevent memory leaks. Forgetting to do this is a common source of bugs.

Since the build() method can run frequently, we need strategies to avoid unnecessary work. The simplest optimization is using the const keyword. If you create a widget with a const constructor, you're telling Flutter that this widget and its entire subtree are immutable. Flutter can then cache this widget and skip rebuilding it entirely, even if its parent rebuilds. Use it for any widget that never changes, like static text, icons, or padding.

For more dynamic situations, there's a more powerful tool: RepaintBoundary. Imagine our bill scanner. The camera preview is updating 30 times a second, but the 'Cancel' button at the bottom of the screen is static. Without optimization, every new camera frame could trigger a rebuild of the entire screen, including the button.

By wrapping the camera preview in a RepaintBoundary, you tell Flutter to isolate it. The camera feed can update as much as it wants, but it won't trigger rebuilds for anything outside its boundary. The rest of the UI remains perfectly still and efficient.

One last crucial concept is Keys. Imagine you have a list of scanned bill items. If you delete an item from the middle of the list, how does Flutter know which widget to remove from the screen? By default, it looks at the widget's type and its position in the tree. This can lead to problems when the list changes.

Keys solve this by giving each widget a unique identity. When you build a list of widgets, you can assign each one a Key, typically based on some unique data associated with it, like an item's ID.

Now, when you remove an item, Flutter uses the keys to match the old widgets with the new ones. It sees that the widget with Key('item-2') is gone and removes it correctly, preserving the state of all the other widgets. This prevents bizarre visual bugs and ensures your app's state remains consistent.

Time to test your knowledge.

By combining composition, a clear understanding of the widget lifecycle, and smart performance optimizations, you can build complex, high-performance UIs that feel fluid and responsive.