Think of the screen as a view of state
Imagine a small app listing places to visit at the weekend. There are cards, a search field and save buttons. Tapping a card’s heart changes more than its colour: the saved-places screen and perhaps a counter need to update too. This small interaction is a useful starting point for thinking about UI structure.
In Flutter, widgets describe what should appear for the current data and configuration. When the data changes, the relevant build operations run again; the framework compares the new description with the previous one. Rather than finding individual screen elements and changing them, you answer a question: ‘What should this card look like when the place is saved?’ This is declarative UI.
In our example, a PlaceCard widget could receive the place’s name, image, saved status and an action callback. Its job is to display information and report a tap. It does not need to decide which records to store. That makes it easier to use the same card with different data on discovery and saved-places screens.
Different kinds of state can live in different places
Temporary information that concerns one small part of the interface, such as whether a search field is open, can stay local. Saved places used by several screens need a shared source. The distinction depends on the app’s needs; a variable’s name alone does not tell you which state-management tool to choose.
If a place saved on the discovery screen should appear on another screen, avoid trying to update two independent copies of the same list. Read from one source and make changes through it. Keeping that list after the app closes is a separate decision: sharing state in memory does not automatically persist it to disk or a server.
- Identify which screens read the information.
- Make clear who can change it and through which actions.
- Plan separately for information that must survive an app restart.
Rebuilding is normal; understand its cost
Rebuilding a widget does not mean repainting every pixel on the screen. Eliminating all rebuilds is therefore an unhelpful goal. Start by separating the parts that change often: saving a card should not need to restart expensive calculations in unrelated parts of the page.
Using const for widgets with constant configurations where appropriate helps reuse the same instance. It does not freeze the interface or guarantee smoothness on its own. Splitting a large build method into clear widgets and keeping changing information close to where it is used makes the code easier to follow and profiling results easier to interpret.
Design the waiting moments too
If the discovery list comes from a remote service, think about four separate scenes: loading, content available, no results and something went wrong. A blank screen does not explain which one is happening. A short explanation, an appropriate retry button and a useful empty state help people understand the situation.
If saving requires a network request, also decide what happens when someone taps repeatedly. Giving feedback while the operation is in progress and returning to a consistent state after an error can make a more visible difference than speeding up an animation alone. Sketching this example’s flow can help reveal missing states before implementation.
Measure the same scenario on a real device
When evaluating Android and iOS UI performance, use profile mode on a physical device. Extra debug-mode checks and differences in emulator hardware can make them unrepresentative of a release build. The Performance view in Flutter DevTools helps you inspect where time is spent within frames.
Write down a short measurement scenario: open the list, scroll a few screens, save a place and switch to saved places. Compare results on the same device with similar data. Check whether the change improves that particular flow. Record the device model, app version and amount of data alongside the result. That makes it easier to reproduce the conditions for the next change and share findings with the team. You can then support the impression that something feels faster with a concrete observation you can revisit.
Sources and further reading
Want to dig a little deeper? Here are the official docs behind this article.