Cache custom font family resolution 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. Two caches, both NSCache (thread-safe, so the layout and main threads share them) and both cleared on kCTFontManagerRegisteredFontsChangedNotification, so a font registered at runtime does not stay cached as unknown:

• the face list per family, replacing the direct fontNamesForFamilyName: calls;
• the resolved font per family, effective size, weight and style, wrapping the whole custom-family branch, including the fallback to the system font for an unknown family.

Font variants and variation settings are applied after the cached lookup, as before, so they are not part of the key. The legacy React/Views/RCTFont.mm already has both caches with the same invalidation; this brings the Fabric path in line. The existing system-font cache keeps its key and drops a mutex that NSCache makes redundant; its lazy initialization moves to dispatch_once.

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, 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.9 ms	−34%
text measurement alone	49.4 ms	31.5 ms	−36%
of which attributed-string conversion (where fonts are resolved)	25.9 ms	7.7 ms	−70%
drawRect total (main thread)	57.1 ms	45.8 ms	−20%
mount end to display (main thread)	115.2 ms	98.4 ms	−15%

The same scenario with the system font is unchanged (47.6 ms layout in both builds), 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