Cache resolved custom fonts on iOS Fabric

[hryhoriiK97]

Summary:

RCTFontWithFontProperties (ReactCommon/react/renderer/textlayoutmanager/platform/ios/.../RCTFontUtils.mm) resolves the UIFont for every text fragment when a paragraph's NSAttributedString is built. The system font is cached, but a custom fontFamily is not.

Current behavior. For a custom family, every call enumerates the font database with +[UIFont fontNamesForFamilyName:], then instantiates every face in the family and reads its traits and weight to pick the closest one. That runs once per fragment per attributed-string build, so a list of 1000 labels in a custom font resolves the same font 1000 times on the layout thread, and again on the main thread whenever the attributed-string cache (256 entries) has evicted the paragraph before it is drawn.

With this change. The resolved font is cached per family, effective size, weight and style, in an NSCache (thread-safe, so the layout and main threads share it) that is cleared on kCTFontManagerRegisteredFontsChangedNotification, so a font registered at runtime does not stay cached as unknown. The lookup is an extra else if arm ahead of the existing resolution code, which is unchanged; a miss runs it and stores the result, including the fallback to the system font for an unknown family. Font variants and variation settings are applied after the lookup, as before, so they are not part of the key. The legacy React/Views/RCTFont.mm caches its lookups the same way.

Why. Custom fonts are the common case in production apps, and this cost scales with the number of text fragments on screen rather than with the number of distinct fonts, which is usually a handful.

Changelog:

[IOS] [CHANGED] - Cache custom font family resolution for Fabric text, so a font family is resolved once per family, size, weight and style instead of once per text fragment

Test Plan:

• node scripts/clang-format.js --check on the changed file passes.
• RNTester built with xcodebuild in Release for a physical iPhone 15 Pro; the Text examples render as before.
• Screenshots of a 1000-label list and of a set of edge cases (right-aligned text with an inline view, centered multi-line text, empty text with an explicit size, truncation across nested colours, RTL with an inline view, clipped fixed height, two-line tail ellipsis) are byte-identical with and without this change.
• Measurement. RNTester Playground mounting 1000 unique single-line and wrapping labels in one commit, timed from Fabric's transaction telemetry (TransactionTelemetry), a timer around the attributed-string conversion inside measurement (where fonts are resolved), a run-loop observer after the CoreAnimation commit (mount end to display) and a timer around -[RCTParagraphTextView drawRect:]. Two builds of the same tree differing only in this file. The button presses were driven by Argent on the physical iPhone, so both builds ran the identical sequence (5 mounts and unmounts per font). iPhone 15 Pro, Release, medians of 5 mounts:

1000 labels, fontFamily: 'Avenir', fontWeight: '500'	before	this PR	change
layout (shadow thread, incl. text measurement)	54.1 ms	35.5 ms	−34%
text measurement alone	49.4 ms	31.4 ms	−36%
of which attributed-string conversion (where fonts are resolved)	25.9 ms	7.6 ms	−71%
drawRect total (main thread)	57.1 ms	45.5 ms	−20%
mount end to display (main thread)	115.2 ms	96.8 ms	−16%

The same scenario with the system font is unchanged within noise (47.6 ms and 45.7 ms layout), as expected since the system font was already cached. The draw-side gain comes from paragraphs whose attributed string had been evicted from the 256-entry cache before drawing; a list with fewer than 256 distinct strings would see only the layout-side gain.

🤖 Generated with Claude Code