perf(android): Move start-reason binder off main thread (JAVA-616) - #5866
Closed
runningcode wants to merge 2 commits into
Closed
perf(android): Move start-reason binder off main thread (JAVA-616)#5866runningcode wants to merge 2 commits into
runningcode wants to merge 2 commits into
Conversation
📲 Install BuildsAndroid
|
Contributor
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| d15471f | 369.38 ms | 459.08 ms | 89.70 ms |
| bbc35bb | 324.88 ms | 425.73 ms | 100.85 ms |
| b193867 | 319.59 ms | 403.09 ms | 83.50 ms |
| 62b579c | 299.75 ms | 364.84 ms | 65.09 ms |
| 382d6c1 | 306.85 ms | 368.70 ms | 61.85 ms |
| 48277cd | 320.38 ms | 379.90 ms | 59.52 ms |
| 5b1a06b | 315.40 ms | 353.33 ms | 37.94 ms |
| ee747ae | 415.92 ms | 470.15 ms | 54.23 ms |
| 37ec571 | 366.04 ms | 424.28 ms | 58.23 ms |
| 462dea2 | 277.68 ms | 359.83 ms | 82.15 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| d15471f | 1.58 MiB | 2.13 MiB | 559.54 KiB |
| bbc35bb | 1.58 MiB | 2.12 MiB | 553.01 KiB |
| b193867 | 1.58 MiB | 2.19 MiB | 620.00 KiB |
| 62b579c | 0 B | 0 B | 0 B |
| 382d6c1 | 1.58 MiB | 2.29 MiB | 719.85 KiB |
| 48277cd | 0 B | 0 B | 0 B |
| 5b1a06b | 0 B | 0 B | 0 B |
| ee747ae | 1.58 MiB | 2.10 MiB | 530.95 KiB |
| 37ec571 | 0 B | 0 B | 0 B |
| 462dea2 | 0 B | 0 B | 0 B |
markushi
reviewed
Jul 30, 2026
| private volatile @Nullable ApplicationStartInfo cachedStartInfo; | ||
| // Runs the getHistoricalProcessStartReasons binder call off the main thread. The Sentry executor | ||
| // does not exist this early (ContentProvider time), so a plain daemon thread is used by default. | ||
| private @NotNull Executor startInfoExecutor = |
Member
There was a problem hiding this comment.
We could have the executor as a local variable and immediately call shut down after enqueuing like here, to avoid any dangling executors.
| private @Nullable ApplicationStartInfo cachedStartInfo; | ||
| // Volatile: written from the background lookup thread, read from the main thread. Null until the | ||
| // deferred getHistoricalProcessStartReasons lookup resolves. | ||
| private volatile @Nullable ApplicationStartInfo cachedStartInfo; |
Member
There was a problem hiding this comment.
How about turning this into a LazyEvaluator<ApplicationStartInfo> cachedStartInfo? Then the executor can simple call get(), to trigger evaluation off the main thread.
getHistoricalProcessStartReasons is an API 35+ binder round-trip to system_server that ran synchronously on the main thread at ContentProvider time, stalling the coldest part of app start. Run it on a background thread instead. The result is consumed best-effort: cold/warm falls back to the pre-API-35 heuristic and app.start.reason is null if the lookup has not resolved by the first activity.
runningcode
force-pushed
the
no/java-616-defer-start-reasons-off-main
branch
from
August 4, 2026 15:58
89ad41e to
b988cb3
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| ### Performance | ||
|
|
||
| - Defer the API 35+ `getHistoricalProcessStartReasons` binder call to a background thread so it no longer blocks the main thread during app start ([#5866](https://github.com/getsentry/sentry-java/pull/5866)) |
Contributor
There was a problem hiding this comment.
- 🚫 The changelog entry seems to be part of an already released section
## 8.51.0.
Consider moving the entry to the## Unreleasedsection, please.
Contributor
Author
|
@markushi thanks for the feedback on this, with the changes to main that created merge conflicts and the fact that this can cause a timing issue on startup I will close this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Description
On API 35+,
AppStartMetrics.registerLifecycleCallbacksperformed anActivityManager.getHistoricalProcessStartReasons(1)binder call synchronously on the main thread. Under auto-init this runs atContentProvidertime (SentryPerformanceProvider.onAppLaunched), blocking the main thread on asystem_serverround-trip during the coldest part of app start.This moves the lookup onto a short-lived background daemon thread. The Sentry executor doesn't exist this early (ContentProvider time), so a plain thread is used.
cachedStartInfois nowvolatileand consumed best-effort:onActivityCreated: it prefers the resolvedApplicationStartInfoand falls back to the existing pre-API-35 heuristic if the lookup hasn't resolved yet.COLD.getAppStartReason()returnsnullif the lookup hasn't resolved by the time it is read.No public API change (
apiDumpclean).💡 Motivation and Context
#5702. Fixes #5702.
The binder call stalled the main thread at the most latency-sensitive moment of startup. Measured on a Pixel 10 (API 36) across cold starts, the synchronous call cost ~0.5–2.2 ms of main-thread time (median ~0.7 ms, mean ~0.9 ms). Deferring it reclaims that time from the main thread.
💚 How did you test it?
AppStartMetricsTestApi35unit tests updated to inject a synchronous executor and driveonActivityCreated; all pass.cachedStartInfowas ready before the first activity in every observed cold start — even with the sample's artificial start-padding removed — so cold/warm andapp.start.reasonare preserved in practice.📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps