Chatted with @HansMuller about this the other day.

Currently, Flutter only estimates the maximum scroll offset one way, but taking the average size of the visible children and multiplying it by the number of children:

This can be a bit unfortunate when the user has a list of dynamically sized items in which the max scroll extent changes as they scroll.

There seem to be some opportunities for improvement here. Things we might consider:

• Adding more strategies for estimating the max scroll offset for different situations
  • optionally could let the user decide which estimation method they would like used
  • One should be that we cache the metrics as we go, rather than disposing of extent info of children we have scrolled past already
• Better expose an option for users to provide their own estimate
  • could just involve a good example or two showing how to override estimateMaxScrollOffset for any SliverChildDelegate, but if there are more approachable options we should explore further

Related to #25652