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 for the iPhone 16 Pro simulator (Debug) and for a physical iPhone 15 Pro (Release); 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) and a timer around -[RCTParagraphTextView drawRect:]. iPhone 16 Pro simulator, Debug. Layout and measurement are medians of 5 runs; the draw column is the median of the runs whose display pass was captured (2 before, 5 after):

1000 labels, fontFamily: 'Avenir', fontWeight: '500'	before	this PR	change
layout (shadow thread, incl. text measurement)	67.5 ms	53.8 ms	−20%
text measurement alone	47.8 ms	34.3 ms	−28%
drawRect total (main thread)	58.9 ms	49.8 ms	−15%

Two further runs of the "this PR" arm on other days gave 52.2 ms and 60.6 ms of layout for the Avenir case, so run-to-run spread is several milliseconds; the medians above are from the run interleaved with the baseline. The same scenario with the system font is unchanged within that noise (61.3 ms before; 60.4 to 66.0 ms across three later runs), 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