Isolate batched input scheduling logic.
Having whether something is currently scheduled get modified in the actual processing logic and away from the scheduling logic makes it unnecessarily more difficult to reason about. In this case, we were only checking whether the Choreographer-aligned runnable was actually scheduled before we'd consume input. When trying to unbuffer dispatches so that things were no longer Choreographer-aligned, however, we'd unschedule the that runnable just before we tried to consume input and hence just before the check . This meant we never actually consumed the batches until the next one came in where we would then consume them immediately. Worse, if another one never came in then we'd never actually consume the batch. By removing the scheduling logic from the processing logic we avoid this situation. Now only the schedule, unschedule, and actual runnable logic touch their own scheduled state, so that we don't have to consider the two pieces of logic together except in isolated places. Bug: 158540186 Bug: 159239700 Test: manual, using app that injects unbuffered dispatch requests either at ACTION_DOWN or first ACTION_MOVE Change-Id: I7521a5a16ed52afc41261f501128b5498ea0602c
Loading
Please register or sign in to comment