unsettledCount property
How many of those steps were captured with the app still animating after
a policy that waited for it to stop — settled: false with
waited: true, the settle giving up with frames still scheduled.
A capture parked on purpose is not one of these. Settle.none,
Settle.frames and Settle.elapse stop on a count or on the clock, so
a frame still scheduled when they return is what the author asked to
photograph — counting those makes the number a measure of how much
mid-flight the suite captures rather than of anything to look at.
Not a failure and not usually a surprise: a spinner does it, and the
default policy exists to survive one. It is here because nothing at a
call site distinguishes a verb that settled from one that gave up, so
a suite acquires them silently and a reader has to open steps one at a
time to find out. Reported by a consumer who swept a 397-call
pumpAndSettle cleanup through 125 scenarios: the deletions that broke
the suite were all at places the settle had already stopped short of,
and this number is the one that would have said so before the sweep.
Carried beside unchangedCount for the same reason it is: the summary
is the copy a reader gets.
Implementation
final int unsettledCount;