[ANR] Reduced AndroidTransactionProfiler lock

[stefanosiano]

📜 Description

Removed lock from AndroidTransactionProfiler

💡 Motivation and Context

Trying to reduce ANRs. There are reports of ANRs happening when getting the lock on transaction start/end

resolves #4792

💚 How did you test it?

📝 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

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	351.00 ms	486.74 ms	135.74 ms
Size	1.58 MiB	2.12 MiB	549.09 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
d364ace	382.77 ms	443.21 ms	60.44 ms
3998a95	415.94 ms	478.54 ms	62.60 ms
806307f	357.85 ms	424.64 ms	66.79 ms
ee747ae	357.79 ms	421.84 ms	64.05 ms
d217708	355.34 ms	381.39 ms	26.05 ms
ee747ae	396.82 ms	441.67 ms	44.86 ms
604a261	380.65 ms	451.27 ms	70.62 ms
3699cd5	423.60 ms	495.52 ms	71.92 ms
b3d8889	371.84 ms	447.49 ms	75.65 ms
d5a29b6	298.62 ms	391.78 ms	93.16 ms

App size

Revision	Plain	With Sentry	Diff
d364ace	1.58 MiB	2.11 MiB	539.75 KiB
3998a95	1.58 MiB	2.10 MiB	532.96 KiB
806307f	1.58 MiB	2.10 MiB	533.42 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
d217708	1.58 MiB	2.10 MiB	532.97 KiB
ee747ae	1.58 MiB	2.10 MiB	530.95 KiB
604a261	1.58 MiB	2.10 MiB	533.42 KiB
3699cd5	1.58 MiB	2.10 MiB	533.45 KiB
b3d8889	1.58 MiB	2.10 MiB	535.07 KiB
d5a29b6	1.58 MiB	2.12 MiB	549.37 KiB

Previous results on branch: stefanosiano/enh/remove-profiling-lock

Startup times

Revision	Plain	With Sentry	Diff
54a0e3d	313.70 ms	369.06 ms	55.36 ms
6329f7d	302.88 ms	357.80 ms	54.92 ms
7bf9f04	329.80 ms	401.20 ms	71.41 ms

App size

Revision	Plain	With Sentry	Diff
54a0e3d	1.58 MiB	2.12 MiB	549.09 KiB
6329f7d	1.58 MiB	2.11 MiB	539.66 KiB
7bf9f04	1.58 MiB	2.12 MiB	548.08 KiB

[romtsn]

should this be volatile?

[stefanosiano]

we access it only inside the lock, except in close() where we only read it to stop the profiler copying it into another variable
i guess it's fine to keep it as-is? wdyt?

[romtsn]

I guess we still need to wrap profiler instantiation into a synchronized lock? And also where we're checking if (profiler == null) ?

[stefanosiano]

profiler instantiation is guarded by if (!isRunning.getAndSet(true)) {. Do you think it's not enough?
all other occurrences just read the variable, so volatile should be enough imho
mostly because we never nullify it, not even in close()