perf: screen reader queries#3674
Merged
Merged
Conversation
szuperaz
approved these changes
Jun 22, 2026
Contributor
SDK Size
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎯 Goal
useScreenReaderEnabledused to attach its ownAccessibilityInfolistener and fire its ownisScreenReaderEnabled()native query on every mount. It runs in everyMessagerow (twice, viauseMessageActionHandlers) plus the composer, so the app requeried the OS and resubscribed on every row mount/remount - work that grows with message count and scrolling.This PR introduces a single app-wide
ScreenReaderContext: one provider performs one query + one listener, and every consumer reads the value from context.useScreenReaderEnabledcollapses to a context read; its public signature and theenabled/forceScreenReaderModegating are unchanged.On-device perf-testing tooling (initial pass WIP)
In addition to all of this, the PR also introduces a bootstrapping on device perf testing setup we'll keep iterating on. It's in its early conception still, but so far it's been able to run its own iteration over our
SampleApp(on Android) and add performance related probes so as to measure this particular change. The result was ~300 microseconds less work for each message to render (asynchronous, of course, non blocking for the UI, but still). This work is of course hugely negligible and will never matter in the grand scheme of things (especially for something gated behind a flag like a11y), but it's still very interesting that it is able to find this out on a fresh agent, with almost no interaction from my side (after many, many iterations :D ). It comes with its own "verbs" (rudimentary for now) related to app actions and only works with ADB. Later own we'll extend this further and potentially add iOS support as well.Features so far:
perf/scenario-lib.sh— reusable adb/uiautomator device-driving verbs (wait-on-testID, tap, retry tap, scroll, count).perf/scenario-template.sh+perf/drive-channel-scenario.sh- template + first scenario.perf-benchmarkingskill capturing the methodology and pitfalls, containing some instructions on how to actually do actionable things in the appA more proper technical document for this will be included later.
🛠 Implementation details
🎨 UI Changes
iOS
Android
🧪 Testing
☑️ Checklist
developbranch