[hryhoriiK97]

Summary:

PreparedLayoutTextView collects the ClickableSpans of its text every time its prepared layout changes, which is every time the text is updated: it walks the text with nextSpanTransition, calls getSpans for each segment and copies the results into a list. The list itself is never read. Touch handling only checks whether it is empty before hit testing a tap, and focus handling only checks it before clearing the selection.

With this change, touch handling checks whether the text has a ClickableSpan on its first touch after a layout change, with a single getSpans, and keeps the answer until the next layout change. Losing focus clears the selection when there is one, which is the state it resets, instead of looking at the spans. Texts that are never touched no longer pay for the scan.

This is the main thread work done for every update of a Text whose spannable has spans, so it adds up on screens where many texts change often (lists of messages, prices, scores, counters).

Changelog:

[ANDROID] [CHANGED] - Find the clickable spans of a Text only when it is touched, instead of on every text update

Test Plan:

• New PreparedLayoutTextViewClickableSpanTest: tapping a ClickableSpan clicks it; after the text is replaced by one without clickable spans a tap no longer clicks; after the text is replaced by one with a clickable span a tap clicks it. ./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest --tests 'com.facebook.react.views.text.*' passes (104 tests).
• yarn format-check-kotlin reports no changes.
• On a device. Two RNTester release APKs built from the same local checkout (with local benchmark screens, and PreparedLayoutTextView.kt identical to main at 9bc1a28), without and with this change, installed alternately on a moto g57 power (Android 16). Each install first opens a screen with a static text containing a nested <Text onPress> link and taps the link: onPress fired once on every install of both builds (10 installs). Then a Playground screen of 200 rich text rows (bold, colored, italic and a link per row) where every row changes every 100 ms runs for 30 s, and the main and JS thread CPU time is read from /proc:

	before	this PR	change
Main thread, 30 s	4.88 / 5.01 s	4.61 / 4.64 s	−6.5%
JS thread, 30 s	15.00 / 14.66 s	14.67 / 14.69 s	no change

Three earlier rounds, with a build that differed only in the focus check (which this screen never runs), gave the same result: main thread 4.97 / 5.15 / 4.93 s before and 4.68 / 4.65 / 4.70 s after (−6.8%).

In a simpleperf profile of the same screen before this change, collecting the spans (nextSpanTransition, getSpans and the list copies in the preparedLayout setter, called from PreparedLayoutTextViewManager.updateExtraData) was about 5% of the main thread.

• Not covered by a unit test: the focus change path, which now checks selection != null (the selection is private).

🤖 Generated with Claude Code

[github-actions]

Visual regression

No visual differences at 4cd2d06bdab8.

ios: no capture

[meta-codesync]

@andrewdacenko has imported this pull request. If you are a Meta employee, you can view this in D128363239.

[christophpurrer]

Review automatically exported from Phabricator review in Meta.

[andrewdacenko]

The old code explicitly cleared clickableSpans = emptyList() here. Consider adding hasClickableSpansCache = null for defensive consistency — if a recycled view ever receives a touch before a new preparedLayout is set, the cache would still hold the stale value from the previous text.

[hryhoriiK97]

@andrewdacenko done in e5873ce: recycleView() now clears hasClickableSpansCache too, and I added a test for it. Thanks!