perf(android): Avoid exception-driven control flow in getResourceId

[runningcode]

Resolves JAVA-586

📜 Description

ViewUtils.getResourceId used exception-driven control flow: it threw Resources.NotFoundException for views with View.NO_ID or a generated id, and every caller caught and discarded it. This ran per view during view-hierarchy snapshots and gesture target resolution, so in Compose-heavy apps — where most views have generated ids — the SDK constructed an exception (and a native fillInStackTrace stack walk) for nearly every view, on the main thread.

This adds a non-throwing ViewUtils.resolveResourceId(View) that returns null for unresolved ids, and routes the hot callers (ViewHierarchyEventProcessor.viewToNode, AndroidViewGestureTargetLocator.createUiElement, getResourceIdWithFallback) through it. The public getResourceId(...) throws Resources.NotFoundException stays as a thin wrapper for backward compatibility. Emitted identifiers and fallbacks are unchanged.

💡 Motivation and Context

Found while analyzing a customer-provided Perfetto trace: in a single view-hierarchy snapshot, 24 of 72 getResourceId calls threw Resources.NotFoundException on the main thread — pure overhead with no functional result.

💚 How did you test it?

• Unit tests in ViewUtilsTest cover the new resolveResourceId (generated id, NO_ID, resource-not-found, and success) plus the existing getResourceId/fallback behavior; ViewHierarchyEventProcessorTest and AndroidViewGestureTargetLocatorTest pass unchanged.

• On-device A/B on a Pixel 3 (Android 12) via ART method tracing, analyzed in Perfetto trace_processor, over 2048 calls on NO_ID views:

  	old (getResourceId)	new (resolveResourceId)
  Resources$NotFoundException.<init>	2048	0
  Throwable.fillInStackTrace	2048	0
  total methods executed	30,757	12,324
  inclusive time / call (traced)	30,470 ns	6,467 ns

  Exactly one exception (+ native stack fill) per unresolved view is removed; ~60% fewer executed methods and ~4.7× cheaper per unresolved view (the absolute ns is inflated by tracing; the call counts and ratio are the reliable signal).

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Follow-ups identified in the same trace but intentionally out of scope here: per-touch LinkedList→ArrayDeque in ViewUtils.findTarget, and background JSON serialization cost.

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.45.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[linear-code]

JAVA-586